b'              Current Internet-Drafts\n\n   This summary sheet provides a short synopsis of each Internet-Draft\navailable within the "internet-drafts" directory at the shadow\nsites directory.  These drafts are listed alphabetically by working\ngroup acronym and start date. Generated 2020-01-28 04:08:20 UTC.\n\n\nIPv6 over Networks of Resource-constrained Nodes (6lo)\n------------------------------------------------------\n\n  "Transmission of IPv6 Packets over Near Field Communication", Younghwan\n  Choi, Yong-Geun Hong, Joo-Sang Youn, Dongkyun Kim, JinHyeock Choi,\n  2019-07-08, <draft-ietf-6lo-nfc-15.txt>\n\n      Near field communication (NFC) is a set of standards for smartphones\n      and portable devices to establish radio communication with each other\n      by touching them together or bringing them into proximity, usually no\n      more than 10 cm apart.  NFC standards cover communications protocols\n      and data exchange formats, and are based on existing radio-frequency\n      identification (RFID) standards including ISO/IEC 14443 and FeliCa.\n      The standards include ISO/IEC 18092 and those defined by the NFC\n      Forum.  The NFC technology has been widely implemented and available\n      in mobile phones, laptop computers, and many other devices.  This\n      document describes how IPv6 is transmitted over NFC using 6LoWPAN\n      techniques.\n\n  "IPv6 Backbone Router", Pascal Thubert, Charles Perkins, Eric\n  Levy-Abegnoli, 2019-09-26, <draft-ietf-6lo-backbone-router-13.txt>\n\n      This document updates RFC 6775 and RFC 8505 in order to enable proxy\n      services for IPv6 Neighbor Discovery by Routing Registrars called\n      Backbone Routers.  Backbone Routers are placed along the wireless\n      edge of a Backbone, and federate multiple wireless links to form a\n      single MultiLink Subnet.\n\n  "IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP", Carles Gomez, Seyed\n  Darroudi, Teemu Savolainen, Michael Spoerk, 2019-12-14,\n  <draft-ietf-6lo-blemesh-07.txt>\n\n      RFC 7668 describes the adaptation of 6LoWPAN techniques to enable\n      IPv6 over Bluetooth low energy networks that follow the star\n      topology.  However, recent Bluetooth specifications allow the\n      formation of extended topologies as well.  This document specifies\n      mechanisms that are needed to enable IPv6 mesh over Bluetooth Low\n      Energy links established by using the Bluetooth Internet Protocol\n      Support Profile.  This document does not specify the routing protocol\n      to be used in an IPv6 mesh over Bluetooth LE links.\n\n  "Address Protected Neighbor Discovery for Low-power and Lossy Networks",\n  Pascal Thubert, Behcet Sarikaya, Mohit Sethi, Rene Struik, 2020-01-06,\n  <draft-ietf-6lo-ap-nd-13.txt>\n\n      This document updates the 6LoWPAN Neighbor Discovery (ND) protocol\n      defined in RFC 6775 and RFC 8505.  The new extension is called\n      Address Protected Neighbor Discovery (AP-ND) and it protects the\n      owner of an address against address theft and impersonation attacks\n      in a low-power and lossy network (LLN).  Nodes supporting this\n      extension compute a cryptographic identifier (Crypto-ID) and use it\n      with one or more of their Registered Addresses.  The Crypto-ID\n      identifies the owner of the Registered Address and can be used to\n      provide proof of ownership of the Registered Addresses.  Once an\n      address is registered with the Crypto-ID and a proof-of-ownership is\n      provided, only the owner of that address can modify the registration\n      information, thereby enforcing Source Address Validation.\n\n  "IPv6 over Constrained Node Networks (6lo) Applicability & Use cases",\n  Yong-Geun Hong, Carles Gomez, Abdur Sangi, Take Aanstoot, Samita\n  Chakrabarti, 2019-11-04, <draft-ietf-6lo-use-cases-08.txt>\n\n      This document describes the applicability of IPv6 over constrained\n      node networks (6lo) and provides practical deployment examples.  In\n      addition to IEEE 802.15.4, various link layer technologies such as\n      ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, and PLC (IEEE\n      1901.2) are used as examples.  The document targets an audience who\n      like to understand and evaluate running end-to-end IPv6 over the\n      constrained node networks connecting devices to each other or to\n      other devices on the Internet (e.g. cloud infrastructure).\n\n  "Packet Delivery Deadline time in 6LoWPAN Routing Header", Lijo Thomas,\n  Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins, 2019-07-08,\n  <draft-ietf-6lo-deadline-time-05.txt>\n\n      This document specifies a new type for the 6LoWPAN routing header\n      containing the deadline time for data packets, designed for use over\n      constrained networks.  The deadline time enables forwarding and\n      scheduling decisions for time critical IoT machine to machine (M2M)\n      applications that operate within time-synchronized networks that\n      agree on the meaning of the time representations used for the\n      deadline time values.\n\n  "6LoWPAN Selective Fragment Recovery", Pascal Thubert, 2019-11-28,\n  <draft-ietf-6lo-fragment-recovery-08.txt>\n\n      This draft updates RFC 4944 with a simple protocol to recover\n      individual fragments across a route-over mesh network, with a minimal\n      flow control to protect the network against bloat.\n\n  "On Forwarding 6LoWPAN Fragments over a Multihop IPv6 Network", Thomas\n  Watteyne, Pascal Thubert, Carsten Bormann, 2019-11-28,\n  <draft-ietf-6lo-minimal-fragment-07.txt>\n\n      This document introduces the capability to forward 6LoWPAN fragments.\n      This method reduces the latency and increases end-to-end reliability\n      in route-over forwarding.  It is the companion to using virtual\n      reassembly buffers which is a pure implementation technique.\n\n  "Transmission of IPv6 Packets over PLC Networks", Jianqiang Hou, Bing Liu,\n  Yong-Geun Hong, Xiaojun Tang, Charles Perkins, 2019-11-03,\n  <draft-ietf-6lo-plc-01.txt>\n\n      Power Line Communication (PLC), namely using the electric-power lines\n      for indoor and outdoor communications, has been widely applied to\n      support Advanced Metering Infrastructure (AMI), especially smart\n      meters for electricity.  The inherent advantage of existing\n      electricity infrastructure facilitates the expansion of PLC\n      deployments, and moreover, a wide variety of accessible devices\n      raises the potential demand of IPv6 for future applications.  This\n      document describes how IPv6 packets are transported over constrained\n      PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2.\n\nIPv6 Maintenance (6man)\n-----------------------\n\n  "IPv6 Segment Routing Header (SRH)", Clarence Filsfils, Darren Dukes,\n  Stefano Previdi, John Leddy, Satoru Matsushima, Daniel Voyer, 2019-10-22,\n  <draft-ietf-6man-segment-routing-header-26.txt>\n\n      Segment Routing can be applied to the IPv6 data plane using a new\n      type of Routing Extension Header called the Segment Routing Header.\n      This document describes the Segment Routing Header and how it is used\n      by Segment Routing capable nodes.\n\n  "ICMPv6 errors for discarding packets due to processing limits", Tom\n  Herbert, 2019-09-30, <draft-ietf-6man-icmp-limits-07.txt>\n\n      Network nodes may discard packets if they are unable to process\n      protocol headers of packets due to processing constraints or limits.\n      When such packets are dropped, the sender receives no indication so\n      it cannot take action to address the cause of discarded packets. This\n      specification defines several new ICMPv6 errors that can be sent by a\n      node that discards packets because it is unable to process the\n      protocol headers. A node that receives such an ICMPv6 error may be\n      able to modify what it sends in future packets to avoid subsequent\n      packet discards.\n\n  "Privacy Extensions for Stateless Address Autoconfiguration in IPv6",\n  Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves, 2019-12-10,\n  <draft-ietf-6man-rfc4941bis-05.txt>\n\n      Nodes use IPv6 stateless address autoconfiguration to generate\n      addresses using a combination of locally available information and\n      information advertised by routers.  Addresses are formed by combining\n      network prefixes with an interface identifier.  This document\n      describes an extension that causes nodes to generate global scope\n      addresses with randomized interface identifiers that change over\n      time.  Changing global scope addresses over time makes it more\n      difficult for eavesdroppers and other information collectors to\n      identify when different addresses used in different transactions\n      actually correspond to the same node.  This document formally\n      obsoletes RFC4941.\n\n  "Discovering PREF64 in Router Advertisements", Lorenzo Colitti, Jen\n  Linkova, 2019-12-19, <draft-ietf-6man-ra-pref64-09.txt>\n\n      This document specifies a Neighbor Discovery option to be used in\n      Router Advertisements to communicate NAT64 prefixes to hosts.\n\n  "Operations, Administration, and Maintenance (OAM) in Segment Routing\n  Networks with IPv6 Data plane (SRv6)", Zafar Ali, Clarence Filsfils, Satoru\n  Matsushima, Daniel Voyer, Mach Chen, 2019-12-18,\n  <draft-ietf-6man-spring-srv6-oam-03.txt>\n\n      This document defines building blocks for Operations, Administration,\n      and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane\n      (SRv6).  The document also describes some SRv6 OAM mechanisms.\n\n  "IPv6 Minimum Path MTU Hop-by-Hop Option", Robert Hinden, Gorry Fairhurst,\n  2019-09-13, <draft-ietf-6man-mtu-option-01.txt>\n\n      This document specifies a new Hop-by-Hop IPv6 option that is used to\n      record the minimum Path MTU along the forward path between a source\n      host to a destination host.  This collects a minimum recorded MTU\n      along the path to the destination.  The value can then be\n      communicated back to the source using the return Path MTU field in\n      the option.\n      \n      This Hop-by-Hop option is intended to be used in environments like\n      Data Centers and on paths between Data Centers, to allow them to\n      better take advantage of paths able to support a large Path MTU.\n\n  "Gratuitous Neighbor Discovery: Creating Neighbor Cache Entries on\n  First-Hop Routers", Jen Linkova, 2019-11-26,\n  <draft-linkova-6man-grand-01.txt>\n\n      Neighbor Discovery (RFC4861) is used by IPv6 nodes to determine the\n      link-layer addresses of neighboring nodes as well as to discover and\n      maintain reachability information.  This document updates [RFC4861]\n      to allow routers to proactively create a Neighbor Cache entry when a\n      new IPv6 address is assigned to a host.  It also updates [RFC4862]\n      and recommends hosts to send unsolicited Neighbor Advertisements upon\n      assigning a new IPv6 address.  The proposed change will minimize the\n      delay and packet loss when a host initiate connections to off-link\n      destination from a new IPv6 address.\n\nIPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)\n--------------------------------------------------\n\n  "An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Pascal\n  Thubert, 2019-10-29, <draft-ietf-6tisch-architecture-28.txt>\n\n      This document describes a network architecture that provides low-\n      latency, low-jitter and high-reliability packet delivery.  It\n      combines a high-speed powered backbone and subnetworks using IEEE\n      802.15.4 time-slotted channel hopping (TSCH) to meet the requirements\n      of LowPower wireless deterministic applications.\n\n  "Constrained Join Protocol (CoJP) for 6TiSCH", Malisa Vucinic, Jonathan\n  Simon, Kris Pister, Michael Richardson, 2019-12-10,\n  <draft-ietf-6tisch-minimal-security-15.txt>\n\n      This document describes the minimal framework required for a new\n      device, called "pledge", to securely join a 6TiSCH (IPv6 over the\n      TSCH mode of IEEE 802.15.4e) network.  The framework requires that\n      the pledge and the JRC (join registrar/coordinator, a central\n      entity), share a symmetric key.  How this key is provisioned is out\n      of scope of this document.  Through a single CoAP (Constrained\n      Application Protocol) request-response exchange secured by OSCORE\n      (Object Security for Constrained RESTful Environments), the pledge\n      requests admission into the network and the JRC configures it with\n      link-layer keying material and other parameters.  The JRC may at any\n      time update the parameters through another request-response exchange\n      secured by OSCORE.  This specification defines the Constrained Join\n      Protocol and its CBOR (Concise Binary Object Representation) data\n      structures, and describes how to configure the rest of the 6TiSCH\n      communication stack for this join process to occur in a secure\n      manner.  Additional security mechanisms may be added on top of this\n      minimal framework.\n\n  "IEEE 802.15.4 Information Element encapsulation of 6TiSCH Join and\n  Enrollment Information", Diego Dujovne, Michael Richardson, 2020-01-22,\n  <draft-ietf-6tisch-enrollment-enhanced-beacon-09.txt>\n\n      In TSCH mode of IEEE STD 802.15.4, opportunities for broadcasts are\n      limited to specific times and specific channels.  Nodes in a TSCH\n      network typically frequently send Enhanced Beacon (EB) frames to\n      announce the presence of the network.  This document provides a\n      mechanism by which small details critical for new nodes (pledges) and\n      long sleeping nodes may be carried within the Enhanced Beacon.\n\n  "6TiSCH Minimal Scheduling Function (MSF)", Tengfei Chang, Malisa Vucinic,\n  Xavier Vilajosana, Simon Duquennoy, Diego Dujovne, 2019-12-13,\n  <draft-ietf-6tisch-msf-10.txt>\n\n      This specification defines the 6TiSCH Minimal Scheduling Function\n      (MSF).  This Scheduling Function describes both the behavior of a\n      node when joining the network, and how the communication schedule is\n      managed in a distributed fashion.  MSF is built upon the 6TiSCH\n      Operation Sublayer Protocol (6P) and the Minimal Security Framework\n      for 6TiSCH.\n\nAuthentication and Authorization for Constrained Environments (ace)\n-------------------------------------------------------------------\n\n  "Authentication and Authorization for Constrained Environments (ACE) using\n  the OAuth 2.0 Framework (ACE-OAuth)", Ludwig Seitz, Goeran Selander, Erik\n  Wahlstroem, Samuel Erdtman, Hannes Tschofenig, 2020-01-18,\n  <draft-ietf-ace-oauth-authz-31.txt>\n\n      This specification defines a framework for authentication and\n      authorization in Internet of Things (IoT) environments called ACE-\n      OAuth.  The framework is based on a set of building blocks including\n      OAuth 2.0 and the Constrained Application Protocol (CoAP), thus\n      transforming a well-known and widely used authorization solution into\n      a form suitable for IoT devices.  Existing specifications are used\n      where possible, but extensions are added and profiles are defined to\n      better serve the IoT use cases.\n\n  "Datagram Transport Layer Security (DTLS) Profile for Authentication and\n  Authorization for Constrained Environments (ACE)", Stefanie Gerdes, Olaf\n  Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz, 2019-12-18,\n  <draft-ietf-ace-dtls-authorize-09.txt>\n\n      This specification defines a profile of the ACE framework that allows\n      constrained servers to delegate client authentication and\n      authorization.  The protocol relies on DTLS for communication\n      security between entities in a constrained network using either raw\n      public keys or pre-shared keys.  A resource-constrained server can\n      use this protocol to delegate management of authorization information\n      to a trusted host with less severe limitations regarding processing\n      power and memory.\n\n  "Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)", Michael\n  Jones, Ludwig Seitz, Goeran Selander, Samuel Erdtman, Hannes Tschofenig,\n  2019-10-31, <draft-ietf-ace-cwt-proof-of-possession-11.txt>\n\n      This specification describes how to declare in a CBOR Web Token (CWT)\n      (which is defined by RFC 8392) that the presenter of the CWT\n      possesses a particular proof-of-possession key.  Being able to prove\n      possession of a key is also sometimes described as being the holder-\n      of-key.  This specification provides equivalent functionality to\n      "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC\n      7800) but using Concise Binary Object Representation (CBOR) and CWTs\n      rather than JavaScript Object Notation (JSON) and JSON Web Tokens\n      (JWTs).\n\n  "OSCORE profile of the Authentication and Authorization for Constrained\n  Environments Framework", Francesca Palombini, Ludwig Seitz, Goeran\n  Selander, Martin Gunnarsson, 2019-07-08,\n  <draft-ietf-ace-oscore-profile-08.txt>\n\n      This memo specifies a profile for the Authentication and\n      Authorization for Constrained Environments (ACE) framework.  It\n      utilizes Object Security for Constrained RESTful Environments\n      (OSCORE) to provide communication security, server authentication,\n      and proof-of-possession for a key owned by the client and bound to an\n      OAuth 2.0 access token.\n\n  "EST over secure CoAP (EST-coaps)", Peter van der Stok, Panos Kampanakis,\n  Michael Richardson, Shahid Raza, 2020-01-06,\n  <draft-ietf-ace-coap-est-18.txt>\n\n      Enrollment over Secure Transport (EST) is used as a certificate\n      provisioning protocol over HTTPS.  Low-resource devices often use the\n      lightweight Constrained Application Protocol (CoAP) for message\n      exchanges.  This document defines how to transport EST payloads over\n      secure CoAP (EST-coaps), which allows constrained devices to use\n      existing EST functionality for provisioning certificates.\n\n  "Additional OAuth Parameters for Authorization in Constrained Environments\n  (ACE)", Ludwig Seitz, 2020-01-11, <draft-ietf-ace-oauth-params-11.txt>\n\n      This specification defines new parameters for the OAuth 2.0 token and\n      introspection endpoints when used with the framework for\n      authentication and authorization for constrained environments (ACE).\n      These are used to express the proof-of-possession key the client\n      wishes to use, the proof-of-possession key that the Authorization\n      Server has selected, and the key the Resource Server should use to\n      authenticate to the client.\n\n  "Key Provisioning for Group Communication using ACE", Francesca Palombini,\n  Marco Tiloca, 2020-01-15, <draft-ietf-ace-key-groupcomm-04.txt>\n\n      This document defines message formats and procedures for requesting\n      and distributing group keying material using the ACE framework, to\n      protect communications between group members.\n\n  "Key Management for OSCORE Groups in ACE", Marco Tiloca, Jiye Park,\n  Francesca Palombini, 2020-01-15,\n  <draft-ietf-ace-key-groupcomm-oscore-04.txt>\n\n      This specification defines an application profile of the ACE\n      framework for Authentication and Authorization, to request and\n      provision keying material in group communication scenarios that are\n      based on CoAP and secured with Group Object Security for Constrained\n      RESTful Environments (OSCORE).  This application profile delegates\n      the authentication and authorization of Clients that join an OSCORE\n      group through a Resource Server acting as Group Manager for that\n      group.  This application profile leverages protocol-specific\n      transport profiles of ACE to achieve communication security, server\n      authentication and proof-of-possession for a key owned by the Client\n      and bound to an OAuth 2.0 access token.\n\n  "MQTT-TLS profile of ACE", Cigdem Sengul, Anthony Kirby, Paul Fremantle,\n  2019-12-20, <draft-ietf-ace-mqtt-tls-profile-03.txt>\n\n      This document specifies a profile for the ACE (Authentication and\n      Authorization for Constrained Environments) framework to enable\n      authorization in an MQTT-based publish-subscribe messaging system.\n      Proof-of-possession keys, bound to OAuth2.0 access tokens, are used\n      to authenticate and authorize MQTT Clients.  The protocol relies on\n      TLS for confidentiality and server authentication.\n\n  "Pub-Sub Profile for Authentication and Authorization for Constrained\n  Environments (ACE)", Francesca Palombini, 2020-01-04,\n  <draft-ietf-ace-pubsub-profile-00.txt>\n\n      This specification defines an application profile for authentication\n      and authorization for publishers and subscribers in a pub-sub setting\n      scenario in a constrained environment, using the ACE framework.  This\n      profile relies on transport layer or application layer security to\n      authorize the publisher to the broker.  Moreover, it relies on\n      application layer security for publisher-broker and subscriber-broker\n      communication.\n\nAutomated Certificate Management Environment (acme)\n---------------------------------------------------\n\n  "Support for Short-Term, Automatically-Renewed (STAR) Certificates in\n  Automated Certificate Management Environment (ACME)", Yaron Sheffer, Diego\n  Lopez, Oscar de Dios, Antonio Pastor, Thomas Fossati, 2019-10-24,\n  <draft-ietf-acme-star-11.txt>\n\n      Public-key certificates need to be revoked when they are compromised,\n      that is, when the associated private key is exposed to an\n      unauthorized entity.  However the revocation process is often\n      unreliable.  An alternative to revocation is issuing a sequence of\n      certificates, each with a short validity period, and terminating this\n      sequence upon compromise.  This memo proposes an ACME extension to\n      enable the issuance of short-term and automatically renewed (STAR)\n      X.509 certificates.\n      \n      [RFC Editor: please remove before publication]\n      \n      While the draft is being developed, the editor\'s version can be found\n      at https://github.com/yaronf/I-D/tree/master/STAR.\n\n  "Extensions to Automatic Certificate Management Environment for end user\n  S/MIME certificates", Alexey Melnikov, 2019-11-01,\n  <draft-ietf-acme-email-smime-06.txt>\n\n      This document specifies identifiers and challenges required to enable\n      the Automated Certificate Management Environment (ACME) to issue\n      certificates for use by email users that want to use S/MIME.\n\n  "ACME IP Identifier Validation Extension", Roland Shoemaker, 2019-10-01,\n  <draft-ietf-acme-ip-08.txt>\n\n      This document specifies identifiers and challenges required to enable\n      the Automated Certificate Management Environment (ACME) to issue\n      certificates for IP addresses.\n\n  "ACME TLS ALPN Challenge Extension", Roland Shoemaker, 2019-10-01,\n  <draft-ietf-acme-tls-alpn-07.txt>\n\n      This document specifies a new challenge for the Automated Certificate\n      Management Environment (ACME) protocol that allows for domain control\n      validation using TLS.\n\n  "TNAuthList profile of ACME Authority Token", Chris Wendt, David Hancock,\n  Mary Barnes, Jon Peterson, 2019-11-04,\n  <draft-ietf-acme-authority-token-tnauthlist-05.txt>\n\n      This document defines a profile of the Automated Certificate\n      Management Environment (ACME) Authority Token for the automated and\n      authorized creation of certificates for VoIP Telephone Providers to\n      support Secure Telephony Identity (STI) using the TNAuthList defined\n      by STI certificates.\n\n  "ACME Challenges Using an Authority Token", Jon Peterson, Mary Barnes,\n  David Hancock, Chris Wendt, 2019-11-04,\n  <draft-ietf-acme-authority-token-04.txt>\n\n      Some proposed extensions to the Automated Certificate Management\n      Environment (ACME) rely on proving eligibility for certificates\n      through consulting an external authority that issues a token\n      according to a particular policy.  This document specifies a generic\n      Authority Token challenge for ACME which supports subtype claims for\n      different identifiers or namespaces that can be defined separately\n      for specific applications.\n\n  "An ACME Profile for Generating Delegated STAR Certificates", Yaron\n  Sheffer, Diego Lopez, Antonio Pastor, Thomas Fossati, 2019-08-26,\n  <draft-ietf-acme-star-delegation-01.txt>\n\n      This memo proposes a profile of the ACME protocol that allows the\n      owner of an identifier (e.g., a domain name) to delegate to a third\n      party access to a certificate associated with said identifier.  A\n      primary use case is that of a CDN (the third party) terminating TLS\n      sessions on behalf of a content provider (the owner of a domain\n      name).  The presented mechanism allows the owner of the identifier to\n      retain control over the delegation and revoke it at any time by\n      cancelling the associated STAR certificate renewal with the ACME CA.\n      Another key property of this mechanism is it does not require any\n      modification to the deployed TLS ecosystem.\n\n  "ACME End User Client and Code Signing Certificates", Kathleen Moriarty,\n  2020-01-10, <draft-ietf-acme-client-00.txt>\n\n      Automated Certificate Management Environment (ACME) core protocol\n      addresses the use case of web server certificates for TLS.  This\n      document extends the ACME protocol to support end user client, device\n      client, and code signing certificates.\n\n  "ACME Integrations", Owen Friel, Richard Barnes, Rifaat Shekh-Yusef,\n  Michael Richardson, 2020-01-20, <draft-ietf-acme-integrations-00.txt>\n\n      This document outlines multiple advanced use cases and integrations\n      that ACME facilitates without any modifications or enhancements\n      required to the base ACME specification.  The use cases include ACME\n      integration with EST, BRSKI and TEAP.\n\nApplication-Layer Traffic Optimization (alto)\n---------------------------------------------\n\n  "ALTO Incremental Updates Using Server-Sent Events (SSE)", Wendy Roome, Y.\n  Yang, 2020-01-23, <draft-ietf-alto-incr-update-sse-18.txt>\n\n      The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol\n      provides network related information, called network information\n      resources, to client applications so that clients can make informed\n      decisions in utilizing network resources.  For example, an ALTO\n      server can provide network and cost maps so that an ALTO client can\n      use the maps to determine the costs between network endpoints when\n      choosing communicating endpoints.\n      \n      However, the ALTO protocol does not define a mechanism to allow an\n      ALTO client to obtain updates to the information resources, other\n      than by periodically re-fetching them.  Because some information\n      resources (e.g., the aforementioned maps) may be large (potentially\n      tens of megabytes), and because only parts of the information\n      resources may change frequently (e.g., only some entries in a cost\n      map), complete re-fetching can be extremely inefficient.\n      \n      This document presents a mechanism to allow an ALTO server to push\n      updates to ALTO clients, to achieve two benefits: (1) updates can be\n      immediate, in that the ALTO server can send updates as soon as they\n      are available; and (2) updates can be incremental, in that if only a\n      small section of an information resource changes, the ALTO server can\n      send just the changes.\n\n  "ALTO Cost Calendar", Sabine Randriamasy, Y. Yang, Qin WU, Deng Lingli,\n  Nico Schwan, 2020-01-21, <draft-ietf-alto-cost-calendar-15.txt>\n\n      This document is an extension to the base Application-Layer Traffic\n      Optimization (ALTO) protocol.  It extends the ALTO cost information\n      service so that applications decide not only \'where\' to connect, but\n      also \'when\'.  This is useful for applications that need to perform\n      bulk data transfer and would like to schedule these transfers during\n      an off-peak hour, for example.  This extension introduces ALTO Cost\n      Calendar, with which an ALTO Server exposes ALTO cost values in JSON\n      arrays where each value corresponds to a given time interval.  The\n      time intervals as well as other Calendar attributes, are specified in\n      the Information Resources Directory and ALTO Server responses.\n\n  "ALTO Performance Cost Metrics", Qin WU, Y. Yang, Young Lee, Dhruv Dhody,\n  Sabine Randriamasy, 2019-11-04, <draft-ietf-alto-performance-metrics-08.txt>\n\n      Cost metric is a basic concept in Application-Layer Traffic\n      Optimization (ALTO), and is used in basic services including both the\n      cost map service and the endpoint cost service.\n      \n      Different applications may use different cost metrics, but the ALTO\n      base protocol documents only one single cost metric, i.e., the\n      generic "routingcost" metric; see Sec. 14.2 of ALTO base\n      specification [RFC7285].  Hence, if the resource consumer of an\n      application prefers a resource provider that offers low-delay\n      delivery to the resource consumer, the base protocol does not define\n      the cost metric to be used.\n      \n      ALTO cost metrics can be generic metrics and this document focuses on\n      network performance metrics, including network delay, jitter, packet\n      loss, hop count, and bandwidth.  Additional cost metrics may be\n      documented in other documents.\n      \n      When using an ALTO performance metric, applications need additional\n      information beyond the metric.  In particular, its "cost-source",\n      such as it being an estimation or an SLA, is key to define the\n      meaning of a performance metric.  Hence, each ALTO performance metric\n      should include the "cost-source" of the metric.  To report an\n      estimated value of a performance metric, the ALTO server may derive\n      and aggregate from routing protocols with different granularity and\n      scope, such as BGP-LS, OSPF-TE and ISIS-TE, or from end-to-end\n      traffic management tools.  These metrics may then be exposed by an\n      ALTO Server to allow applications to determine "where" to connect\n      based on network performance criteria.\n\n  "Application Layer Traffic Optimization (ALTO) Cross-Domain Server\n  Discovery", Sebastian Kiesel, Martin Stiemerling, 2019-08-20,\n  <draft-ietf-alto-xdom-disc-06.txt>\n\n      The goal of Application-Layer Traffic Optimization (ALTO) is to\n      provide guidance to applications that have to select one or several\n      hosts from a set of candidates capable of providing a desired\n      resource.  ALTO is realized by a client-server protocol.  Before an\n      ALTO client can ask for guidance it needs to discover one or more\n      ALTO servers that can provide suitable guidance.\n      \n      In some deployment scenarios, in particular if the information about\n      the network topology is partitioned and distributed over several ALTO\n      servers, it may be needed to discover an ALTO server outside of the\n      own network domain, in order to get appropriate guidance.  This\n      document details applicable scenarios, itemizes requirements, and\n      specifies a procedure for ALTO cross-domain server discovery.\n      \n      Technically, the procedure specified in this document takes one\n      IP address or prefix and a U-NAPTR Service Parameter (typically,\n      "ALTO:https") as parameters.  It performs DNS lookups (for NAPTR\n      resource records in the in-addr.arpa. or ip6.arpa. tree) and returns\n      one or more URI(s) of information resources related to that IP\n      address or prefix.\n\n  "ALTO Extension: Path Vector", Kai Gao, Young Lee, Sabine Randriamasy, Y.\n  Yang, J. Zhang, 2019-11-03, <draft-ietf-alto-path-vector-09.txt>\n\n      This document defines an ALTO extension that allows an ALTO\n      information resource to provide not only preferences but also\n      correlations of the paths between different PIDs or endpoints.  The\n      extended information, including aggregations of network components on\n      the paths and their properties, can be used to improve the robustness\n      and performance for applications in some new usage scenarios, such as\n      high-speed data transfers and traffic optimization using in-network\n      storage and computation.\n      \n      This document reuses the mechanisms of the ALTO base protocol and the\n      Unified Property extension, such as Information Resource Directory\n      (IRD) capabilities and entity domains, to negotiate and exchange path\n      correlation information.  Meanwhile, it uses an extended compound\n      message to fully represent the path correlation information, for\n      better server scalability and message modularity.  Specifically, the\n      extension 1) introduces abstract network element (ANE) as an\n      abstraction for an aggregation of network components and encodes a\n      network path as a "path vector", i.e., an array of ANEs traversed\n      from the source to the destination, 2) encodes properties of abstract\n      network elements in a unified property map, and 3) encapsulates the\n      two types of information in a multipart message.\n\n  "Content Delivery Network Interconnection (CDNI) Request Routing: CDNI\n  Footprint and Capabilities Advertisement using ALTO", Jan Seedorf, Y. Yang,\n  Kevin Ma, Jon Peterson, Xiao Lin, Jingxuan Zhang, 2020-01-22,\n  <draft-ietf-alto-cdni-request-routing-alto-09.txt>\n\n      The Content Delivery Networks Interconnection (CDNI) framework\n      [RFC6707] defines a set of protocols to interconnect CDNs, to achieve\n      multiple goals such as extending the reach of a given CDN to areas\n      that are not covered by that particular CDN.  One component that is\n      needed to achieve the goal of CDNI described in [RFC7336] is the CDNI\n      Request Routing Footprint & Capabilities Advertisement interface\n      (FCI).  [RFC8008] defines precisely the semantics of FCI and provides\n      guidelines on the FCI protocol, but the exact protocol is explicitly\n      outside the scope of that document.  In this document, we follow the\n      guidelines to define an FCI protocol using the Application-Layer\n      Traffic Optimization (ALTO) protocol.\n\n  "Unified Properties for the ALTO Protocol", Wendy Roome, Sabine\n  Randriamasy, Y. Yang, J. Zhang, Kai Gao, 2019-11-04,\n  <draft-ietf-alto-unified-props-new-10.txt>\n\n      This document extends the Application-Layer Traffic Optimization\n      (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint\n      properties" to generic types of entities, and by presenting those\n      properties as maps, similar to the network and cost maps in\n      [RFC7285].\n\nAutonomic Networking Integrated Model and Approach (anima)\n----------------------------------------------------------\n\n  "A Generic Autonomic Signaling Protocol (GRASP)", Carsten Bormann, Brian\n  Carpenter, Bing Liu, 2017-07-13, <draft-ietf-anima-grasp-15.txt>\n\n      This document specifies the GeneRic Autonomic Signaling Protocol\n      (GRASP), which enables autonomic nodes and autonomic service agents\n      to dynamically discover peers, to synchronize state with each other,\n      and to negotiate parameter settings with each other.  GRASP depends\n      on an external security environment that is described elsewhere.  The\n      technical objectives and parameters for specific application\n      scenarios are to be described in separate documents.  Appendices\n      briefly discuss requirements for the protocol and existing protocols\n      with comparable features.\n\n  "An Autonomic Control Plane (ACP)", Toerless Eckert, Michael Behringer,\n  Steinthor Bjarnason, 2019-11-03,\n  <draft-ietf-anima-autonomic-control-plane-21.txt>\n\n      Autonomic functions need a control plane to communicate, which\n      depends on some addressing and routing.  This Autonomic Management\n      and Control Plane should ideally be self-managing, and as independent\n      as possible of configuration.  This document defines such a plane and\n      calls it the "Autonomic Control Plane", with the primary use as a\n      control plane for autonomic functions.  It also serves as a "virtual\n      out-of-band channel" for Operations Administration and Management\n      (OAM) communications over a network that provides automatically\n      configured hop-by-hop authenticated and encrypted communications via\n      automatically configured IPv6 even when the network is not\n      configured, or misconfigured.\n\n  "Bootstrapping Remote Secure Key Infrastructures (BRSKI)", Max Pritikin,\n  Michael Richardson, Toerless Eckert, Michael Behringer, Kent Watsen,\n  2020-01-03, <draft-ietf-anima-bootstrapping-keyinfra-34.txt>\n\n      This document specifies automated bootstrapping of an Autonomic\n      Control Plane.  To do this a Secure Key Infrastructure is\n      bootstrapped.  This is done using manufacturer-installed X.509\n      certificates, in combination with a manufacturer\'s authorizing\n      service, both online and offline.  We call this process the\n      Bootstrapping Remote Secure Key Infrastructure (BRSKI) protocol.\n      Bootstrapping a new device can occur using a routable address and a\n      cloud service, or using only link-local connectivity, or on limited/\n      disconnected networks.  Support for deployment models with less\n      stringent security requirements is included.  Bootstrapping is\n      complete when the cryptographic identity of the new key\n      infrastructure is successfully deployed to the device.  The\n      established secure connection can be used to deploy a locally issued\n      certificate to the device as well.\n\n  "A Reference Model for Autonomic Networking", Michael Behringer, Brian\n  Carpenter, Toerless Eckert, Laurent Ciavaglia, Jeferson Nobre, 2018-11-22,\n  <draft-ietf-anima-reference-model-10.txt>\n\n      This document describes a reference model for Autonomic Networking\n      for managed networks.  It defines the behaviour of an autonomic node,\n      how the various elements in an autonomic context work together, and\n      how autonomic services can use the infrastructure.\n\n  "Autonomic IPv6 Edge Prefix Management in Large-scale Networks", Sheng\n  Jiang, Zongpeng Du, Brian Carpenter, Qiong Sun, 2017-12-18,\n  <draft-ietf-anima-prefix-management-07.txt>\n\n      This document defines two autonomic technical objectives for IPv6\n      prefix management at the edge of large-scale ISP networks, with an\n      extension to support IPv4 prefixes.  An important purpose of the\n      document is to use it for validation of the design of various\n      components of the autonomic networking infrastructure.\n\n  "Generic Autonomic Signaling Protocol Application Program Interface (GRASP\n  API)", Brian Carpenter, Bing Liu, Wendong Wang, Xiangyang Gong, 2019-10-06,\n  <draft-ietf-anima-grasp-api-04.txt>\n\n      This document is a conceptual outline of an application programming\n      interface (API) for the Generic Autonomic Signaling Protocol (GRASP).\n      Such an API is needed for Autonomic Service Agents (ASA) calling the\n      GRASP protocol module to exchange autonomic network messages with\n      other ASAs.  Since GRASP is designed to support asynchronous\n      operations, the API will need to be adapted to the support for\n      asynchronicity in various languages and operating systems.\n\n  "Constrained Voucher Artifacts for Bootstrapping Protocols", Michael\n  Richardson, Peter van der Stok, Panos Kampanakis, 2020-01-15,\n  <draft-ietf-anima-constrained-voucher-07.txt>\n\n      This document defines a strategy to securely assign a pledge to an\n      owner, using an artifact signed, directly or indirectly, by the\n      pledge\'s manufacturer.  This artifact is known as a "voucher".\n      \n      This document builds upon the work in [RFC8366], encoding the\n      resulting artifact in CBOR.  Use with two signature technologies are\n      described.\n      \n      Additionally, this document explains how constrained vouchers may be\n      transported as an extension to the [I-D.ietf-ace-coap-est] protocol.\n\nApplications and Real-Time Area (art)\n-------------------------------------\n\n  "Lightweight Directory Access Protocol (LDAP) Registrations for PKCS #9",\n  Sean Leonard, 2017-11-13, <draft-seantek-ldap-pkcs9-08.txt>\n\n      PKCS #9 includes several useful definitions that are not yet\n      reflected in the LDAP IANA registry. This document adds those\n      definitions to the IANA registry.\n\n  "Internationalized Domain Names in Applications (IDNA): Registry\n  Restrictions and Recommendations", John Klensin, Asmus Freytag, 2019-08-29,\n  <draft-klensin-idna-rfc5891bis-05.txt>\n\n      The IDNA specifications for internationalized domain names combine\n      rules that determine the labels that are allowed in the DNS without\n      violating the protocol itself and an assignment of responsibility,\n      consistent with earlier specifications, for determining the labels\n      that are allowed in particular zones.  Conformance to IDNA by\n      registries and other implementations requires both parts.  Experience\n      strongly suggests that the language describing those responsibilities\n      was insufficiently clear to promote safe and interoperable use of the\n      specifications and that more details and discussion of circumstances\n      would have been helpful.  Without making any substantive changes to\n      IDNA, this specification updates two of the core IDNA documents (RFCs\n      5890 and 5891) and the IDNA explanatory document (RFC 5894) to\n      provide that guidance and to correct some technical errors in the\n      descriptions.\n\n  "Resolving Multiple Time Scales in the Internet", Joseph Touch, 2019-11-19,\n  <draft-touch-time-06.txt>\n\n      Internet systems use a variety of time scales, which can complicate\n      time comparisons and calculations. This document explains these\n      various ways of indicating time and explains how they can be used\n      together safely. This document is intended as a companion to\n      Internet time as discussed in RFC 3339.\n\n  "New protocol elements for HTTP Status Code 451", Shivan Sahib, 2018-08-01,\n  <draft-sahib-451-new-protocol-elements-03.txt>\n\n      This document recommends additional protocol elements to Hypertext\n      Transfer Protocol (HTTP) status code 451 (defined by RFC7725).\n      \n      Discussion of this document was conducted on the Human Rights\n      Protocol Considerations Research Group mailing list\n      https://www.irtf.org/mailman/listinfo/hrpc [1], briefly on the\n      HTTPBIS Working Group mailing list ietf-http-wg@w3.org [2] and on\n      https://lists.ghserv.net/mailman/listinfo/statuscode451 [3].\n\n  "IDNA2008 and Unicode 11.0.0", Patrik Faltstrom, 2019-03-11,\n  <draft-faltstrom-unicode11-08.txt>\n\n      This document describes the changes between Unicode 6.3.0 and Unicode\n      11.0.0 in the context of IDNA2008.  Some additions and changes have\n      been made in the Unicode Standard that affect the values produced by\n      the algorithm IDNA2008 specifies.  Although IDNA2008 allows adding\n      exceptions to the algorithm for backward compatibility; however, this\n      document does not add any such exceptions.  This document provides\n      the necessary tables to IANA to make its database consisstent with\n      Unicode 11.0.0.\n      \n      To improve understanding, this document describes systems that are\n      being used as alternatives to those that conform to IDNA2008.\n      \n      TO BE REMOVED AT TIME OF PUBLICATION AS AN RFC:\n      \n      This document is discussed on the i18nrp@ietf.org mailing list of the\n      IETF.\n\n  "The secret-token URI Scheme", Mark Nottingham, 2018-11-06,\n  <draft-nottingham-how-did-that-get-into-the-repo-01.txt>\n\n      This document registers the "secret-token" URI scheme, to aid in the\n      identification of authentication tokens.\n\n  "IDNA2008 and Unicode 12.0.0", Patrik Faltstrom, 2019-03-11,\n  <draft-faltstrom-unicode12-00.txt>\n\n      This document describes the changes between Unicode 6.3.0 and Unicode\n      12.0.0 in the context of IDNA2008.  Some additions and changes have\n      been made in the Unicode Standard that affect the values produced by\n      the algorithm IDNA2008 specifies.  Although IDNA2008 allows adding\n      exceptions to the algorithm for backward compatibility; however, this\n      document does not add any such exceptions.  This document provides\n      the necessary tables to IANA to make its database consisstent with\n      Unicode 12.0.0.\n      \n      To improve understanding, this document describes systems that are\n      being used as alternatives to those that conform to IDNA2008.\n      \n      TO BE REMOVED AT TIME OF PUBLICATION AS AN RFC:\n      \n      This document is discussed on the i18nrp@ietf.org mailing list of the\n      IETF.\n\n  "IDNA Review for New Unicode Versions", John Klensin, Patrik Faltstrom,\n  2019-11-03, <draft-klensin-idna-unicode-review-05.txt>\n\n      The standards for Internationalized Domain Names in Applications\n      (IDNA) require a review of each new version of Unicode to determine\n      whether incompatibilities with prior versions or other issues exist\n      and, where appropriate, to allow the IETF to decide on the trade-offs\n      between compatibility with prior IDNA versions and compatibility with\n      Unicode going forward.  That requirement, and its relationship to\n      tables maintained by IANA, has caused significant confusion in the\n      past.  This document makes adjustments to the review procedure based\n      on experience and updates IDNA, specifically RFC 5892, to reflect\n      those changes and clarify the various relationships involved.  It\n      also makes other minor adjustments to align that document with\n      experience.\n\n  "Zstandard Compression and the application/zstd Media Type", Yann Collet,\n  Murray Kucherawy, 2019-12-20, <draft-kucherawy-rfc8478bis-03.txt>\n\n      Zstandard, or "zstd" (pronounced "zee standard"), is a data\n      compression mechanism.  This document describes the mechanism and\n      registers a media type and content encoding to be used when\n      transporting zstd-compressed content via Multipurpose Internet Mail\n      Extensions (MIME).\n      \n      Despite use of the word "standard" as part of its name, readers are\n      advised that this document is not an Internet Standards Track\n      specification; it is being published for informational purposes only.\n      \n      This document replaces and obsoletes RFC 8478.\n\n  "application/importmap+json MIME Type Registration", Guy Bedford,\n  2019-11-17, <draft-bedford-app-importmap-media-reg-00.txt>\n\n      Media type registration for JSON import map definitions that control\n      the behavior of JavaScript imports.\n\nAudio/Video Transport Core Maintenance (avtcore)\n------------------------------------------------\n\n  "Sending Multiple Types of Media in a Single RTP Session", Magnus\n  Westerlund, Colin Perkins, Jonathan Lennox, 2015-12-18,\n  <draft-ietf-avtcore-multi-media-rtp-session-13.txt>\n\n      This document specifies how an RTP session can contain RTP Streams\n      with media from multiple media types such as audio, video, and text.\n      This has been restricted by the RTP Specification, and thus this\n      document updates RFC 3550 and RFC 3551 to enable this behaviour for\n      applications that satisfy the applicability for using multiple media\n      types in a single RTP session.\n\n  "Guidelines for using the Multiplexing Features of RTP to Support Multiple\n  Media Streams", Magnus Westerlund, Bo Burman, Colin Perkins, Harald\n  Alvestrand, Roni Even, 2019-07-22,\n  <draft-ietf-avtcore-multiplex-guidelines-09.txt>\n\n      The Real-time Transport Protocol (RTP) is a flexible protocol that\n      can be used in a wide range of applications, networks, and system\n      topologies.  That flexibility makes for wide applicability, but can\n      complicate the application design process.  One particular design\n      question that has received much attention is how to support multiple\n      media streams in RTP.  This memo discusses the available options and\n      design trade-offs, and provides guidelines on how to use the\n      multiplexing features of RTP to support multiple media streams.\n\n  "Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP\n  Reception Statistics and Other Feedback", Jonathan Lennox, Magnus\n  Westerlund, Qin WU, Colin Perkins, 2016-03-02,\n  <draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt>\n\n      RTP allows multiple RTP streams to be sent in a single session, but\n      requires each Synchronisation Source (SSRC) to send RTCP reception\n      quality reports for every other SSRC visible in the session.  This\n      causes the number of RTCP reception reports to grow with the number\n      of SSRCs, rather than the number of endpoints.  In many cases most of\n      these RTCP reception reports are unnecessary, since all SSRCs of an\n      endpoint are normally co-located and see the same reception quality.\n      This memo defines a Reporting Group extension to RTCP to reduce the\n      reporting overhead in such scenarios.\n\n  "RTP Payload Format for VP9 Video", Justin Uberti, Stefan Holmer, Magnus\n  Flodman, Danny Hong, Jonathan Lennox, 2020-01-13,\n  <draft-ietf-payload-vp9-09.txt>\n\n      This memo describes an RTP payload format for the VP9 video codec.\n      The payload format has wide applicability, as it supports\n      applications from low bit-rate peer-to-peer usage, to high bit-rate\n      video conferences.  It includes provisions for temporal and spatial\n      scalability.\n\n  "Frame Marking RTP Header Extension", Mo Zanaty, Espen Berger, Suhas\n  Nandakumar, 2019-11-21, <draft-ietf-avtext-framemarking-10.txt>\n\n      This document describes a Frame Marking RTP header extension used to\n      convey information about video frames that is critical for error\n      recovery and packet forwarding in RTP middleboxes or network nodes.\n      It is most useful when media is encrypted, and essential when the\n      middlebox or node has no access to the media decryption keys.  It is\n      also useful for codec-agnostic processing of encrypted or unencrypted\n      media, while it also supports extensions for codec-specific\n      information.\n\n  "RTP Control Protocol (RTCP) Feedback for Congestion Control", Zaheduzzaman\n  Sarker, Colin Perkins, Varun Singh, Michael Ramalho, 2019-11-04,\n  <draft-ietf-avtcore-cc-feedback-message-05.txt>\n\n      This document describes an RTCP feedback message intended to enable\n      congestion control for interactive real-time traffic using RTP.  The\n      feedback message is designed for use with a sender-based congestion\n      control algorithm, in which the receiver of an RTP flow sends RTCP\n      feedback packets to the sender containing the information the sender\n      needs to perform congestion control.\n\n  "RTP Payload Format for TSVCIS Codec", Victor Demjanenko, John Punaro,\n  David Satterlee, 2019-10-25, <draft-ietf-payload-tsvcis-04.txt>\n\n      This document describes the RTP payload format for the Tactical\n      Secure Voice Cryptographic Interoperability Specification (TSVCIS)\n      speech coder.  TSVCIS is a scalable narrowband voice coder supporting\n      varying encoder data rates and fallbacks.  It is implemented as an\n      augmentation to the Mixed Excitation Linear Prediction Enhanced\n      (MELPe) speech coder by conveying additional speech coder parameters\n      for enhancing voice quality.  TSVCIS augmented speech data is\n      processed in conjunction with its temporal matched MELP 2400 speech\n      data.  The RTP packetization of TSVCIS and MELPe speech coder data is\n      described in detail.\n\n  "RTP Payload Format for ISO/IEC 21122 (JPEG XS)", Sebastien Lugan, Gael\n  Rouvroy, Antonin Descampe, Thomas Richter, Alexandre Willeme, 2019-10-09,\n  <draft-ietf-payload-rtp-jpegxs-02.txt>\n\n      This document specifies a Real-Time Transport Protocol (RTP) payload\n      format to be used for transporting JPEG XS (ISO/IEC 21122) encoded\n      video.  JPEG XS is a low-latency, lightweight image coding system.\n      Compared to an uncompressed video use case, it allows higher\n      resolutions and frame rates, while offering visually lossless\n      quality, reduced power consumption, and end-to-end latency confined\n      to a fraction of a frame.\n\n  "RTP Payload for TTML Timed Text", James Sandford, 2019-11-19,\n  <draft-ietf-payload-rtp-ttml-06.txt>\n\n      This memo describes a Real-time Transport Protocol (RTP) payload\n      format for TTML, an XML based timed text format for live and file\n      based workflows from W3C.  This payload format is specifically\n      targeted at live workflows using TTML.\n\nAudio/Video Transport Extensions (avtext)\n-----------------------------------------\n\n  "The Layer Refresh Request (LRR) RTCP Feedback Message", Jonathan Lennox,\n  Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman, 2017-07-02,\n  <draft-ietf-avtext-lrr-07.txt>\n\n      This memo describes the RTCP Payload-Specific Feedback Message "Layer\n      Refresh Request" (LRR), which can be used to request a state refresh\n      of one or more substreams of a layered media stream.  It also defines\n      its use with several RTP payloads for scalable media formats.\n\n  "RTP Stream Identifier Source Description (SDES)", Adam Roach, Suhas\n  Nandakumar, Peter Thatcher, 2016-10-06, <draft-ietf-avtext-rid-09.txt>\n\n      This document defines and registers two new RTCP Stream Identifier\n      Source Description (SDES) items.  One, named RtpStreamId, is used for\n      unique identification of RTP streams.  The other,\n      RepairedRtpStreamId, can be used to identify which stream a\n      redundancy RTP stream is to be used to repair.\n\nBabel routing protocol (babel)\n------------------------------\n\n  "Applicability of the Babel routing protocol", Juliusz Chroboczek,\n  2019-08-17, <draft-ietf-babel-applicability-10.txt>\n\n      Babel is a routing protocol based on the distance-vector algorithm\n      augmented with mechanisms for loop avoidance and starvation\n      avoidance.  This document describes a number of niches where Babel\n      has been found to be useful and that are arguably not adequately\n      served by more mature protocols.\n\n  "The Babel Routing Protocol", Juliusz Chroboczek, David Schinazi,\n  2019-12-30, <draft-ietf-babel-rfc6126bis-16.txt>\n\n      Babel is a loop-avoiding distance-vector routing protocol that is\n      robust and efficient both in ordinary wired networks and in wireless\n      mesh networks.  This document describes the Babel routing protocol,\n      and obsoletes RFCs 6126 and 7557.\n\n  "Babel Information Model", Barbara Stark, Mahesh Jethanandani, 2019-10-09,\n  <draft-ietf-babel-information-model-10.txt>\n\n      This Babel Information Model provides structured data elements for a\n      Babel implementation reporting its current state and may allow\n      limited configuration of some such data elements.  This information\n      model can be used as a basis for creating data models under various\n      data modeling regimes.\n\n  "Source-Specific Routing in Babel", Matthieu Boutier, Juliusz Chroboczek,\n  2019-04-11, <draft-ietf-babel-source-specific-05.txt>\n\n      Source-specific routing (also known as Source-Address Dependent\n      Routing, SADR) is an extension to traditional next-hop routing where\n      packets are forwarded according to both their destination and their\n      source address.  This document describes an extension for source-\n      specific routing to the Babel routing protocol.\n\n  "Babel Routing Protocol over Datagram Transport Layer Security", Antonin\n  Decimo, David Schinazi, Juliusz Chroboczek, 2019-08-13,\n  <draft-ietf-babel-dtls-09.txt>\n\n      The Babel Routing Protocol does not contain any means to authenticate\n      neighbours or provide integrity or confidentiality for messages sent\n      between them.  This document specifies a mechanism to ensure these\n      properties, using Datagram Transport Layer Security (DTLS).\n\n  "MAC authentication for the Babel routing protocol", Clara Do, Weronika\n  Kolodziejak, Juliusz Chroboczek, 2019-08-16, <draft-ietf-babel-hmac-10.txt>\n\n      This document describes a cryptographic authentication mechanism for\n      the Babel routing protocol that has provisions for replay avoidance.\n      This document obsoletes RFC 7298.\n\n  "YANG Data Model for Babel", Mahesh Jethanandani, Barbara Stark,\n  2020-01-07, <draft-ietf-babel-yang-model-05.txt>\n\n      This document defines a data model for the Babel routing protocol.\n      The data model is defined using the YANG data modeling language.\n\nBGP Enabled ServiceS (bess)\n---------------------------\n\n  "BGP based Multi-homing in Virtual Private LAN Service", Bhupesh Kothari,\n  Kireeti Kompella, Wim Henderickx, Florin Balus, Jim Uttaro, 2019-07-26,\n  <draft-ietf-bess-vpls-multihoming-05.txt>\n\n      Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private\n      Network (VPN) that gives its customers the appearance that their\n      sites are connected via a Local Area Network (LAN).  It is often\n      required for the Service Provider (SP) to give the customer redundant\n      connectivity to some sites, often called "multi-homing".  This memo\n      shows how BGP-based multi-homing can be offered in the context of LDP\n      and BGP VPLS solutions.  This document updates RFC 4761 by defining\n      new flags in the Control Flags field of the Layer2 Info Extended\n      Community.\n\n  "Integrated Routing and Bridging in EVPN", Ali Sajassi, Samer Salam, Samir\n  Thoria, John Drake, Jorge Rabadan, 2019-03-05,\n  <draft-ietf-bess-evpn-inter-subnet-forwarding-08.txt>\n\n      EVPN provides an extensible and flexible multi-homing VPN solution\n      over an MPLS/IP network for intra-subnet connectivity among Tenant\n      Systems and End Devices that can be physical or virtual. However,\n      there are scenarios for which there is a need for a dynamic and\n      efficient inter-subnet connectivity among these Tenant Systems and\n      End Devices while maintaining the multi-homing capabilities of EVPN.\n      This document describes an Integrated Routing and Bridging (IRB)\n      solution based on EVPN to address such requirements.\n\n  "Interconnect Solution for EVPN Overlay networks", Jorge Rabadan, Senthil\n  Sathappan, Wim Henderickx, Ali Sajassi, John Drake, 2018-03-02,\n  <draft-ietf-bess-dci-evpn-overlay-10.txt>\n\n      This document describes how Network Virtualization Overlays (NVO) can\n      be connected to a Wide Area Network (WAN) in order to extend the\n      layer-2 connectivity required for some tenants. The solution analyzes\n      the interaction between NVO networks running Ethernet Virtual Private\n      Networks (EVPN) and other L2VPN technologies used in the WAN, such as\n      Virtual Private LAN Services (VPLS), VPLS extensions for Provider\n      Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how\n      the existing technical specifications apply to the Interconnection\n      and extends the EVPN procedures needed in some cases. In particular,\n      this document describes how EVPN routes are processed on Gateways\n      (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well\n      as the Interconnect Ethernet Segment (I-ES) to provide multi-homing,\n      and the use of the Unknown MAC route to avoid MAC scale issues on\n      Data Center Network Virtualization Edge (NVE) devices.\n\n  "IP Prefix Advertisement in EVPN", Jorge Rabadan, Wim Henderickx, John\n  Drake, Wen Lin, Ali Sajassi, 2018-05-18,\n  <draft-ietf-bess-evpn-prefix-advertisement-11.txt>\n\n      The BGP MPLS-based Ethernet VPN (EVPN) [RFC7432] mechanism provides a\n      flexible control plane that allows intra-subnet connectivity in an\n      MPLS and/or NVO (Network Virtualization Overlay) [RFC7365] network.\n      In some networks, there is also a need for a dynamic and efficient\n      inter-subnet connectivity across Tenant Systems and End Devices that\n      can be physical or virtual and do not necessarily participate in\n      dynamic routing protocols. This document defines a new EVPN route\n      type for the advertisement of IP Prefixes and explains some use-case\n      examples where this new route-type is used.\n\n  "Multicast VPN fast upstream failover", Thomas Morin, Robert Kebler,\n  Gregory Mirsky, 2019-08-29, <draft-ietf-bess-mvpn-fast-failover-08.txt>\n\n      This document defines multicast VPN extensions and procedures that\n      allow fast failover for upstream failures, by allowing downstream PEs\n      to take into account the status of Provider-Tunnels (P-tunnels) when\n      selecting the upstream PE for a VPN multicast flow, and extending BGP\n      MVPN routing so that a C-multicast route can be advertised toward a\n      standby upstream PE.\n\n  "Optimized Ingress Replication solution for EVPN", Jorge Rabadan, Senthil\n  Sathappan, Wen Lin, Mukul Katiyar, Ali Sajassi, 2018-10-19,\n  <draft-ietf-bess-evpn-optimized-ir-06.txt>\n\n      Network Virtualization Overlay (NVO) networks using EVPN as control\n      plane may use Ingress Replication (IR) or PIM (Protocol Independent\n      Multicast) based trees to convey the overlay BUM traffic. PIM\n      provides an efficient solution to avoid sending multiple copies of\n      the same packet over the same physical link, however it may not\n      always be deployed in the NVO core network. IR avoids the dependency\n      on PIM in the NVO network core. While IR provides a simple multicast\n      transport, some NVO networks with demanding multicast applications\n      require a more efficient solution without PIM in the core. This\n      document describes a solution to optimize the efficiency of IR in NVO\n      networks.\n\n  "Operational Aspects of Proxy-ARP/ND in EVPN Networks", Jorge Rabadan,\n  Senthil Sathappan, Kiran Nagaraj, Greg Hankins, Thomas King, 2019-07-08,\n  <draft-ietf-bess-evpn-proxy-arp-nd-08.txt>\n\n      The EVPN MAC/IP Advertisement route can optionally carry IPv4 and\n      IPv6 addresses associated with a MAC address. Remote PEs can use this\n      information to reply locally (act as proxy) to IPv4 ARP requests and\n      IPv6 Neighbor Solicitation messages (or \'unicast-forward\' them to the\n      owner of the MAC) and reduce/suppress the flooding produced by the\n      Address Resolution procedure. This EVPN capability is extremely\n      useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with\n      large broadcast domains, where the amount of ARP/ND flooded traffic\n      causes issues on routers and CEs. This document describes how the\n      EVPN Proxy-ARP/ND function may be implemented to help IXPs and other\n      operators deal with the issues derived from Address Resolution in\n      large broadcast domains.\n\n  "Updates on EVPN BUM Procedures", Zhaohui Zhang, Wen Lin, Jorge Rabadan,\n  Keyur Patel, Ali Sajassi, 2019-11-18,\n  <draft-ietf-bess-evpn-bum-procedure-updates-08.txt>\n\n      This document specifies procedure updates for broadcast, unknown\n      unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN),\n      including selective multicast, and provider tunnel segmentation.\n      This document updates RFC 7432.\n\n  "BGP Control Plane for NSH SFC", Adrian Farrel, John Drake, Eric Rosen, Jim\n  Uttaro, Luay Jalil, 2019-12-13,\n  <draft-ietf-bess-nsh-bgp-control-plane-13.txt>\n\n      This document describes the use of BGP as a control plane for\n      networks that support Service Function Chaining (SFC).  The document\n      introduces a new BGP address family called the SFC AFI/SAFI with two\n      route types.  One route type is originated by a node to advertise\n      that it hosts a particular instance of a specified service function.\n      This route type also provides "instructions" on how to send a packet\n      to the hosting node in a way that indicates that the service function\n      has to be applied to the packet.  The other route type is used by a\n      Controller to advertise the paths of "chains" of service functions,\n      and to give a unique designator to each such path so that they can be\n      used in conjunction with the Network Service Header defined in RFC\n      8300.\n      \n      This document adopts the SFC architecture described in RFC 7665.\n\n  "IGMP and MLD Proxy for EVPN", Ali Sajassi, Samir Thoria, Keyur Patel, John\n  Drake, Wen Lin, 2019-09-30, <draft-ietf-bess-evpn-igmp-mld-proxy-04.txt>\n\n      Ethernet Virtual Private Network (EVPN) solution is becoming\n      pervasive in data center (DC) applications for Network Virtualization\n      Overlay (NVO) and DC interconnect (DCI) services, and in service\n      provider (SP) applications for next generation virtual private LAN\n      services.\n      \n      This draft describes how to support efficiently endpoints running\n      IGMP for the above services over an EVPN network by incorporating\n      IGMP proxy procedures on EVPN PEs.\n\n  "Preference-based EVPN DF Election", Jorge Rabadan, Senthil Sathappan, Tony\n  Przygienda, Wen Lin, John Drake, Ali Sajassi, satyamoh@cisco.com,\n  2019-12-17, <draft-ietf-bess-evpn-pref-df-05.txt>\n\n      The Designated Forwarder (DF) in Ethernet Virtual Private Networks\n      (EVPN) is defined as the PE responsible for sending Broadcast,\n      Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/\n      network in the case of an all-active multi-homing Ethernet Segment\n      (ES), or BUM and unicast in the case of single-active multi-homing.\n      \n      The DF is selected out of a candidate list of PEs that advertise the\n      same Ethernet Segment Identifier (ESI) to the EVPN network, according\n      to the Default DF Election algorithm.\n      \n      While the Default Algorithm provides an efficient and automated way\n      of selecting the DF across different Ethernet Tags in the ES, there\n      are some use-cases where a more \'deterministic\' and user-controlled\n      method is required.  At the same time, Service Providers require an\n      easy way to force an on-demand DF switchover in order to carry out\n      some maintenance tasks on the existing DF or control whether a new\n      active PE can preempt the existing DF PE.\n      \n      This document proposes an extension to the Default DF election\n      procedures so that the above requirements can be met.\n\n  "Propagation of ARP/ND Flags in EVPN", Jorge Rabadan, Senthil Sathappan,\n  Kiran Nagaraj, Wen Lin, 2019-07-03, <draft-ietf-bess-evpn-na-flags-04.txt>\n\n      An EVPN MAC/IP Advertisement route can optionally carry an IPv4 or\n      IPv6 addresses associated with a MAC address. Remote PEs can use this\n      information to reply locally (act as proxy) to IPv4 ARP requests and\n      IPv6 Neighbor Solicitation messages and reduce/suppress the flooding\n      produced by the Address Resolution procedure. The information\n      conveyed in the MAC/IP route may not be enough for the remote PE to\n      reply to local ARP or ND requests. For example, if a PE learns an\n      IPv6->MAC ND entry via EVPN, the PE would not know if that particular\n      IPv6->MAC pair belongs to a host, a router or a host with an anycast\n      address, as this information is not carried in the MAC/IP route\n      advertisements. Similarly, other information relevant to the IP->MAC\n      ARP/ND entries may be needed. This document defines an extended\n      community that is advertised along with an EVPN MAC/IP Advertisement\n      route and carries information relevant to the ARP/ND resolution, so\n      that an EVPN PE implementing a proxy-ARP/ND function can reply to ARP\n      Requests or Neighbor Solicitations with the correct information.\n\n  "Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled\n  Domain Interconnection", Adrian Farrel, John Drake, Eric Rosen, Keyur\n  Patel, Luay Jalil, 2019-08-21, <draft-ietf-bess-datacenter-gateway-04.txt>\n\n      Data centers are critical components of the infrastructure used by\n      network operators to provide services to their customers.  Data\n      centers are attached to the Internet or a backbone network by gateway\n      routers.  One data center typically has more than one gateway for\n      commercial, load balancing, and resiliency reasons.\n      \n      Segment Routing is a popular protocol mechanism for use within a data\n      center, but also for steering traffic that flows between two data\n      center sites.  In order that one data center site may load balance\n      the traffic it sends to another data center site, it needs to know\n      the complete set of gateway routers at the remote data center, the\n      points of connection from those gateways to the backbone network, and\n      the connectivity across the backbone network.\n      \n      Segment Routing may also be operated in other domains, such as access\n      networks.  Those domains also need to be connected across backbone\n      networks through gateways.\n      \n      This document defines a mechanism using the BGP Tunnel Encapsulation\n      attribute to allow each gateway router to advertise the routes to the\n      prefixes in the Segment Routing domains to which it provides access,\n      and also to advertise on behalf of each other gateway to the same\n      Segment Routing domain.\n\n  "EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding", Wen Lin, Zhaohui\n  Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi, 2019-10-28,\n  <draft-ietf-bess-evpn-irb-mcast-04.txt>\n\n      Ethernet VPN (EVPN) provides a service that allows a single Local\n      Area Network (LAN), comprising a single IP subnet, to be divided into\n      multiple "segments".  Each segment may be located at a different\n      site, and the segments are interconnected by an IP or MPLS backbone.\n      Intra-subnet traffic (either unicast or multicast) always appears to\n      the endusers to be bridged, even when it is actually carried over the\n      IP or MPLS backbone.  When a single "tenant" owns multiple such LANs,\n      EVPN also allows IP unicast traffic to be routed between those LANs.\n      This document specifies new procedures that allow inter-subnet IP\n      multicast traffic to be routed among the LANs of a given tenant,\n      while still making intra-subnet IP multicast traffic appear to be\n      bridged.  These procedures can provide optimal routing of the inter-\n      subnet multicast traffic, and do not require any such traffic to\n      leave a given router and then reenter that same router.  These\n      procedures also accommodate IP multicast traffic that needs to travel\n      to or from systems that are outside the EVPN domain.\n\n  "MVPN and MSDP SA Interoperation", Zhaohui Zhang, Leonard Giuliano,\n  2019-10-16, <draft-ietf-bess-mvpn-msdp-sa-interoperation-04.txt>\n\n      This document specifies the procedures for interoperation between\n      Multicast Virtual Private Network (MVPN) Source Active routes and\n      customer Multicast Source Discovery Protocol (MSDP) Source Active\n      routes, which is useful for MVPN provider networks offering services\n      to customers with an existing MSDP infrastructure.  Without the\n      procedures described in this document, VPN-specific MSDP sessions are\n      required among the PEs that are customer MSDP peers.  This document\n      updates RFC6514.\n\n  "Per multicast flow Designated Forwarder Election for EVPN", Ali Sajassi,\n  mankamana mishra, Samir Thoria, Jorge Rabadan, John Drake, 2019-11-16,\n  <draft-ietf-bess-evpn-per-mcast-flow-df-election-02.txt>\n\n      [RFC7432] describes mechanism to elect designated forwarder (DF) at\n      the granularity of (ESI, EVI) which is per VLAN (or per group of\n      VLANs in case of VLAN bundle or VLAN-aware bundle service).  However,\n      the current level of granularity of per-VLAN is not adequate for some\n      applications.[I-D.ietf-bess-evpn-df-election-framework] improves base\n      line DF election by introducing HRW DF election.\n      [I-D.ietf-bess-evpn-igmp-mld-proxy] introduces applicability of EVPN\n      to Multicast flows, routes to sync them and a default DF election.\n      This document is an extension to HRW base draft\n      [I-D.ietf-bess-evpn-df-election-framework] and further enhances HRW\n      algorithm for the Multicast flows to do DF election at the\n      granularity of (ESI, VLAN, Mcast flow).\n\n  "Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing", Neeraj\n  Malhotra, Ali Sajassi, Samir Thoria, Jorge Rabadan, John Drake, Avinash\n  Lingala, 2019-11-02, <draft-ietf-bess-evpn-unequal-lb-03.txt>\n\n      In an EVPN-IRB based network overlay, EVPN all-active multi-homing\n      enables multi-homing for a CE device connected to two or more PEs via\n      a LAG bundle, such that bridged and routed traffic from remote PEs\n      can be equally load balanced (ECMPed) across the multi-homing PEs.\n      This document defines extensions to EVPN procedures to optimally\n      handle unequal access bandwidth distribution across a set of multi-\n      homing PEs in order to:\n      \n      o provide greater flexibility, with respect to adding or\n      removing individual PE-CE links within the access LAG\n      \n      o handle PE-CE LAG member link failures that can result in unequal\n      PE-CE access bandwidth across a set of multi-homing PEs\n\n  "MVPN/EVPN Tunnel Aggregation with Common Labels", Zhaohui Zhang, Eric\n  Rosen, Wen Lin, Zhenbin Li, IJsbrand Wijnands, 2019-10-24,\n  <draft-ietf-bess-mvpn-evpn-aggregation-label-03.txt>\n\n      The MVPN specifications allow a single Point-to-Multipoint (P2MP)\n      tunnel to carry traffic of multiple VPNs.  The EVPN specifications\n      allow a single P2MP tunnel to carry traffic of multiple Broadcast\n      Domains (BDs).  These features require the ingress router of the P2MP\n      tunnel to allocate an upstream-assigned MPLS label for each VPN or\n      for each BD.  A packet sent on a P2MP tunnel then carries the label\n      that is mapped to its VPN or BD.  (In some cases, a distinct\n      upstream-assigned is needed for each flow.)  Since each ingress\n      router allocates labels independently, with no coordination among the\n      ingress routers, the egress routers may need to keep track of a large\n      number of labels.  The number of labels may need to be as large (or\n      larger) than the product of the number of ingress routers times the\n      number of VPNs or BDs.  However, the number of labels can be greatly\n      reduced if the association between a label and a VPN or BD is made by\n      provisioning, so that all ingress routers assign the same label to a\n      particular VPN or BD.  New procedures are needed in order to take\n      advantage of such provisioned labels.  These new procedures also\n      apply to Multipoint-to-Multipoint (MP2MP) tunnels.  This document\n      updates RFCs 6514, 7432 and 7582 by specifying the necessary\n      procedures.\n\n  "Yang Data Model for Multicast in MPLS/BGP IP VPNs", Yisong Liu, Feng Guo,\n  Stephane Litkowski, Xufeng Liu, Robert Kebler, Mahesh Sivakumar,\n  2019-12-02, <draft-ietf-bess-mvpn-yang-02.txt>\n\n      This document defines a YANG data model that can be used to\n      configure and manage multicast in MPLS/BGP IP VPNs.\n\n  "EVPN Operations, Administration and Maintenance Requirements and\n  Framework", Samer Salam, Ali Sajassi, Sam Aldrin, John Drake, Donald\n  Eastlake, 2020-01-01, <draft-ietf-bess-evpn-oam-req-frmwk-02.txt>\n\n      This document specifies the requirements and reference framework for\n      Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM).\n      The requirements cover the OAM aspects of EVPN and PBB-EVPN.  The\n      framework defines the layered OAM model encompassing the EVPN service\n      layer, network layer and underlying Packet Switched Network (PSN)\n      transport layer.\n\n  "EVPN Interworking with IPVPN", Jorge Rabadan, Ali Sajassi, 2019-11-28,\n  <draft-ietf-bess-evpn-ipvpn-interworking-02.txt>\n\n      EVPN is used as a unified control plane for tenant network intra and\n      inter-subnet forwarding. When a tenant network spans not only EVPN\n      domains but also domains where IPVPN provides inter-subnet\n      forwarding, there is a need to specify the interworking aspects\n      between both EVPN and IPVPN domains, so that the end to end tenant\n      connectivity can be accomplished. This document specifies how EVPN\n      should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families\n      for inter-subnet forwarding.\n\n  "Extended Mobility Procedures for EVPN-IRB", Neeraj Malhotra, Ali Sajassi,\n  Aparna Pattekar, Avinash Lingala, Jorge Rabadan, John Drake, 2019-11-02,\n  <draft-ietf-bess-evpn-irb-extended-mobility-02.txt>\n\n      Procedure to handle host mobility in a layer 2 Network with EVPN\n      control plane is defined as part of RFC 7432. EVPN has since evolved\n      to find wider applicability across various IRB use cases that include\n      distributing both MAC and IP reachability via a common EVPN control\n      plane. MAC Mobility procedures defined in RFC 7432 are extensible to\n      IRB use cases if a fixed 1:1 mapping between VM IP and MAC is assumed\n      across VM moves. Generic mobility support for IP and MAC that allows\n      these bindings to change across moves is required to support a\n      broader set of EVPN IRB use cases, and requires further\n      consideration. EVPN all-active multi-homing further introduces\n      scenarios that require additional consideration from mobility\n      perspective. This document enumerates a set of design considerations\n      applicable to mobility across these EVPN IRB use cases and defines\n      generic sequence number assignment procedures to address these IRB\n      use cases.\n\n  "LSP-Ping Mechanisms for EVPN and PBB-EVPN", Parag Jain, Samer Salam, Ali\n  Sajassi, Sami Boutros, Gregory Mirsky, 2020-01-06,\n  <draft-ietf-bess-evpn-lsp-ping-01.txt>\n\n      LSP-Ping is a widely deployed Operation, Administration, and\n      Maintenance (OAM) mechanism in MPLS networks.  This document\n      describes mechanisms for detecting data-plane failures using LSP Ping\n      in MPLS based EVPN and PBB-EVPN networks.\n\n  "EVPN control plane for Geneve", Sami Boutros, Ali Sajassi, John Drake,\n  Jorge Rabadan, Sam Aldrin, 2019-08-07, <draft-ietf-bess-evpn-geneve-00.txt>\n\n      This document describes how Ethernet VPN (EVPN) control plane can be\n      used with Network Virtualization Overlay over Layer 3 (NVO3) Generic\n      Network Virtualization Encapsulation (Geneve) encapsulation for NVO3\n      solutions. EVPN control plane can also be used by a Network\n      Virtualization Endpoints (NVEs) to express Geneve tunnel option\n      TLV(s)supported in transmission and/or reception of Geneve\n      encapsulated data packets.\n\n  "PBB-EVPN ISID-based CMAC-Flush", Jorge Rabadan, Senthil Sathappan, Kiran\n  Nagaraj, Masahiro Miyake, Taku Matsuda, 2019-10-15,\n  <draft-ietf-bess-pbb-evpn-isid-cmacflush-00.txt>\n\n      Provider Backbone Bridging (PBB) can be combined with Ethernet VPN\n      (EVPN) to deploy ELAN services in very large MPLS networks (PBB-\n      EVPN). Single-Active Multi-homing and per-ISID Load-Balancing can be\n      provided to access devices and aggregation networks. In order to\n      speed up the network convergence in case of failures on Single-Active\n      Multi-Homed Ethernet Segments, PBB-EVPN defines a CMAC-Flush\n      mechanism that works for different Ethernet Segment BMAC address\n      allocation models. This document complements those CMAC-Flush\n      procedures for cases in which no PBB-EVPN Ethernet Segments are\n      defined (ESI 0) and an ISID-based CMAC-Flush granularity is desired.\n\n  "SRv6 BGP based Overlay services", Gaurav Dawra, Clarence Filsfils, Robert\n  Raszuk, Bruno Decraene, Shunwan Zhuang, Jorge Rabadan, 2019-11-04,\n  <draft-ietf-bess-srv6-services-01.txt>\n\n      This draft defines procedures and messages for SRv6-based BGP\n      services including L3VPN, EVPN and Internet services.  It builds on\n      RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432\n      "BGP MPLS-Based Ethernet VPN".\n\n  "Seamless Multicast Interoperability between EVPN and MVPN PEs", Ali\n  Sajassi, Kesavan Thiruvenkatasamy, Samir Thoria, Ashutosh Gupta, Luay\n  Jalil, 2019-11-18, <draft-ietf-bess-evpn-mvpn-seamless-interop-00.txt>\n\n      Ethernet Virtual Private Network (EVPN) solution is becoming\n      pervasive for Network Virtualization Overlay (NVO) services in data\n      center (DC) networks and as the next generation VPN services in\n      service provider (SP) networks.\n      \n      As service providers transform their networks in their COs toward\n      next generation data center with Software Defined Networking (SDN)\n      based fabric and Network Function Virtualization (NFV), they want to\n      be able to maintain their offered services including Multicast VPN\n      (MVPN) service between their existing network and their new Service\n      Provider Data Center (SPDC) network seamlessly without the use of\n      gateway devices. They want to have such seamless interoperability\n      between their new SPDCs and their existing networks for a) reducing\n      cost, b) having optimum forwarding, and c) reducing provisioning.\n      This document describes a unified solution based on RFCs 6513 & 6514\n      for seamless interoperability of Multicast VPN between EVPN and MVPN\n      PEs. Furthermore, it describes how the proposed solution can be used\n      as a routed multicast solution in data centers with only EVPN PEs.\n\n  "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next\n  Hop", Stephane Litkowski, Swadesh Agrawal, krishnaswamy ananthamurthy,\n  Keyur Patel, 2020-01-17, <draft-ietf-bess-rfc5549revision-01.txt>\n\n      Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of usable\n      next-hop address families is determined by the Address Family\n      Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).\n      The current AFI/SAFI definitions for the IPv4 address family only\n      have provisions for advertising a Next Hop address that belongs to\n      the IPv4 protocol when advertising IPv4 Network Layer Reachability\n      Information (NLRI) or VPN-IPv4 NLRI.  This document specifies the\n      extensions necessary to allow advertising IPv4 NLRI or VPN-IPv4 NLRI\n      with a Next Hop address that belongs to the IPv6 protocol.  This\n      comprises an extension of the AFI/SAFI definitions to allow the\n      address of the Next Hop for IPv4 NLRI or VPN-IPv4 NLRI to also belong\n      to the IPv6 protocol, the encoding of the Next Hop to determine which\n      of the protocols the address actually belongs to, and a new BGP\n      Capability allowing MP-BGP Peers to dynamically discover whether they\n      can exchange IPv4 NLRI and VPN-IPv4 NLRI with an IPv6 Next Hop.\n\n  "Virtual Hub-and-Spoke in BGP EVPNs", Keyur Patel, Ali Sajassi, John Drake,\n  Zhaohui Zhang, Wim Henderickx, 2020-01-26,\n  <draft-ietf-bess-evpn-virtual-hub-00.txt>\n\n      Ethernet Virtual Private Network (EVPN) solution is becoming\n      pervasive for Network Virtualization Overlay (NVO) services in data\n      center (DC) applications and as the next generation virtual private\n      LAN services in service provider (SP) applications.\n      \n      The use of host IP default route and host unknown MAC route within a\n      DC is well understood in order to ensure that leaf nodes within a DC\n      only learn and store host MAC and IP addresses for that DC. All other\n      host MAC and IP addresses from remote DCs are learned and stored in\n      DC GW nodes thus alleviating leaf nodes from learning host MAC and IP\n      addresses from the remote DCs.\n      \n      This draft further optimizes the MAC and IP address learning at the\n      leaf nodes such that a leaf node within a DC only needs to learn and\n      store MAC and IP addresses associated with the sites directly\n      connected to it. A leaf node does not need to learn and store MAC and\n      IP addresses from any other leaf nodes thus reducing the number of\n      learned MACs and IP addresses per EVI substantially.\n      \n      The modifications provided by this draft updates and extends RFC7024\n      for BGP EVPN Address Family.\n\n  "Controller Based BGP Multicast Signaling", Zhaohui Zhang, Robert Raszuk,\n  Dante Pacella, Arkadiy Gulko, 2020-01-26,\n  <draft-ietf-bess-bgp-multicast-controller-00.txt>\n\n      This document specifies a way that one or more centralized\n      controllers can use BGP to set up a multicast distribution tree in a\n      network.  In the case of labeled tree, the labels are assigned by the\n      controllers either from the controllers\' local label spaces, or from\n      a common Segment Routing Global Block (SRGB), or from each routers\n      Segment Routing Local Block (SRLB) that the controllers learn.  In\n      case of labeled unidirectional tree and label allocation from the\n      common SRGB or from the controllers\' local spaces, a single common\n      label can be used for all routers on the tree to send and receive\n      traffic with.  Since the controllers calculate the trees, they can\n      use sophisticated algorithms and constraints to achieve traffic\n      engineering.\n\n  "BGP Based Multicast", Zhaohui Zhang, Leonard Giuliano, Keyur Patel,\n  IJsbrand Wijnands, mankamana mishra, Arkadiy Gulko, 2020-01-26,\n  <draft-ietf-bess-bgp-multicast-00.txt>\n\n      This document specifies a BGP address family and related procedures\n      that allow BGP to be used for setting up multicast distribution\n      trees.  This document also specifies procedures that enable BGP to be\n      used for multicast source discovery, and for showing interest in\n      receiving particular multicast flows.  Taken together, these\n      procedures allow BGP to be used as a replacement for other multicast\n      routing protocols, such as PIM or mLDP.  The BGP procedures specified\n      here are based on the BGP multicast procedures that were originally\n      designed for use by providers of Multicast Virtual Private Network\n      service.\n\nBinary Floor Control Protocol Bis (bfcpbis)\n-------------------------------------------\n\n  "The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, Keith Drage,\n  Tom Kristensen, Joerg Ott, Charles Eckel, 2015-11-13,\n  <draft-ietf-bfcpbis-rfc4582bis-16.txt>\n\n      Floor control is a means to manage joint or exclusive access to\n      shared resources in a (multiparty) conferencing environment.\n      Thereby, floor control complements other functions -- such as\n      conference and media session setup, conference policy manipulation,\n      and media control -- that are realized by other protocols.\n      \n      This document specifies the Binary Floor Control Protocol (BFCP).\n      BFCP is used between floor participants and floor control servers,\n      and between floor chairs (i.e., moderators) and floor control\n      servers.\n      \n      This document obsoletes RFC 4582.  Changes from RFC 4582 are\n      summarized in Section 16.\n\n  "Session Description Protocol (SDP) Format for Binary Floor Control\n  Protocol (BFCP) Streams", Gonzalo Camarillo, Tom Kristensen, Christer\n  Holmberg, 2018-12-08, <draft-ietf-bfcpbis-rfc4583bis-27.txt>\n\n      This document defines the Session Description Protocol (SDP) offer/\n      answer procedures for negotiating and establishing Binary Floor\n      Control Protocol (BFCP) streams.\n      \n      This document obsoletes RFC 4583.  Changes from RFC 4583 are\n      summarized in Section 14.\n\n  "The WebSocket Protocol as a Transport for the Binary Floor Control\n  Protocol (BFCP)", Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo\n  Salgueiro, Ram R, 2017-02-08, <draft-ietf-bfcpbis-bfcp-websocket-15.txt>\n\n      The WebSocket protocol enables two-way realtime communication between\n      clients and servers.  This document specifies the use of Binary Floor\n      Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a\n      reliable transport mechanism between BFCP entities in new scenarios.\n\nBidirectional Forwarding Detection (bfd)\n----------------------------------------\n\n  "YANG Data Model for Bidirectional Forwarding Detection (BFD)", Reshad\n  Rahman, Lianshu Zheng, Mahesh Jethanandani, Santosh Pallagatti, Gregory\n  Mirsky, 2018-08-02, <draft-ietf-bfd-yang-17.txt>\n\n      This document defines a YANG data model that can be used to configure\n      and manage Bidirectional Forwarding Detection (BFD).\n      \n      The YANG modules in this document conform to the Network Management\n      Datastore Architecture (NMDA).\n\n  "Optimizing BFD Authentication", Mahesh Jethanandani, Ashesh Mishra, Ankur\n  Saxena, Manav Bhatia, 2019-12-09,\n  <draft-ietf-bfd-optimizing-authentication-09.txt>\n\n      This document describes an optimization to BFD Authentication as\n      described in Section 6.7 of BFD RFC5880.\n\n  "BFD Stability", Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Juniper\n  Networks, Mach Chen, Peng Fan, 2019-08-26,\n  <draft-ietf-bfd-stability-04.txt,.pdf>\n\n      This document describes extensions to the Bidirectional Forwarding\n      Detection (BFD) protocol to measure BFD stability.  Specifically, it\n      describes a mechanism for detection of BFD frame loss.\n\n  "Secure BFD Sequence Numbers", Mahesh Jethanandani, Sonal Agarwal, Ashesh\n  Mishra, Ankur Saxena, Alan DeKok, 2019-08-26,\n  <draft-ietf-bfd-secure-sequence-numbers-04.txt>\n\n      This document describes a security enhancements for the BFD packet\'s\n      sequence number.\n\n  "BFD for VXLAN", Juniper Networks, Sudarsan Paragiri, Vengada Govindan,\n  Mallik Mudigonda, Gregory Mirsky, 2020-01-08, <draft-ietf-bfd-vxlan-10.txt>\n\n      This document describes the use of the Bidirectional Forwarding\n      Detection (BFD) protocol in point-to-point Virtual eXtensible Local\n      Area Network (VXLAN) tunnels used to form an overlay network.\n\n  "BFD Encapsulated in Large Packets", Jeffrey Haas, Albert Fu, 2019-11-01,\n  <draft-ietf-bfd-large-packets-02.txt>\n\n      The Bidirectional Forwarding Detection (BFD) protocol is commonly\n      used to verify connectivity between two systems.  BFD packets are\n      typically very small.  It is desirable in some circumstances to know\n      that not only is the path between two systems reachable, but also\n      that it is capable of carrying a payload of a particular size.  This\n      document discusses thoughts on how to implement such a mechanism\n      using BFD in Asynchronous mode.\n\nBit Indexed Explicit Replication (bier)\n---------------------------------------\n\n  "BIER Use Cases", Nagendra Kumar, Rajiv Asati, Mach Chen, Xiaohu Xu, Andrew\n  Dolganow, Tony Przygienda, Arkadiy Gulko, Dom Robinson, Vishal Arya,\n  Caitlin Bestler, 2019-08-04, <draft-ietf-bier-use-cases-10.txt>\n\n      Bit Index Explicit Replication (BIER) is an architecture that\n      provides optimal multicast forwarding through a "BIER domain" without\n      requiring intermediate routers to maintain any multicast related per-\n      flow state.  BIER also does not require any explicit tree-building\n      protocol for its operation.  A multicast data packet enters a BIER\n      domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the\n      BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).\n      The BFIR router adds a BIER header to the packet.  The BIER header\n      contains a bit-string in which each bit represents exactly one BFER\n      to forward the packet to.  The set of BFERs to which the multicast\n      packet needs to be forwarded is expressed by setting the bits that\n      correspond to those routers in the BIER header.\n      \n      This document describes some of the use cases for BIER.\n\n  "BGP Extensions for BIER", Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand\n  Wijnands, Tony Przygienda, 2019-09-06,\n  <draft-ietf-bier-idr-extensions-07.txt>\n\n      Bit Index Explicit Replication (BIER) is a new multicast forwarding\n      architecture which doesn\'t require an explicit tree-building protocol\n      and doesn\'t require intermediate routers to maintain any multicast\n      state.  BIER is applicable in a multi-tenant data center network\n      environment for efficient delivery of Broadcast, Unknown-unicast and\n      Multicast (BUM) traffic while eliminating the need for maintaining a\n      huge amount of multicast state in the underlay.  This document\n      describes BGP extensions for advertising the BIER-specific\n      information.  These extensions are applicable in those multi-tenant\n      data centers where BGP instead of IGP is deployed as an underlay for\n      network reachability advertisement.  These extensions may also be\n      applicable in other scenarios.\n\n  "Operations, Administration and Maintenance (OAM) Requirements for Bit\n  Index Explicit Replication (BIER) Layer", Gregory Mirsky, Erik Nordmark,\n  Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Lianshu Zheng, Mach Chen,\n  Nobo Akiya, Santosh Pallagatti, 2019-08-27,\n  <draft-ietf-bier-oam-requirements-08.txt>\n\n      This document describes a list of functional requirement toward\n      Operations, Administration and Maintenance (OAM) toolset in Bit Index\n      Explicit Replication (BIER) layer of a network.\n\n  "Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit\n  Replication (BIER) Layer", Gregory Mirsky, Tony Przygienda, Andrew\n  Dolganow, 2019-11-26, <draft-ietf-bier-path-mtu-discovery-07.txt>\n\n      This document describes Path Maximum Transmission Unit Discovery\n      (PMTUD) in Bit Indexed Explicit Replication (BIER) layer.\n\n  "Performance Measurement (PM) with Marking Method in Bit Index Explicit\n  Replication (BIER) Layer", Gregory Mirsky, Lianshu Zheng, Mach Chen,\n  Giuseppe Fioccola, 2020-01-03, <draft-ietf-bier-pmmm-oam-07.txt>\n\n      This document describes a hybrid performance measurement method for\n      multicast service through a Bit Index Explicit Replication domain.\n\n  "BIER Ping and Trace", Nagendra Kumar, Carlos Pignataro, Nobo Akiya,\n  Lianshu Zheng, Mach Chen, Gregory Mirsky, 2019-10-31,\n  <draft-ietf-bier-ping-06.txt>\n\n      Bit Index Explicit Replication (BIER) is an architecture that\n      provides optimal multicast forwarding through a "BIER domain" without\n      requiring intermediate routers to maintain any multicast related per-\n      flow state.  BIER also does not require any explicit tree-building\n      protocol for its operation.  A multicast data packet enters a BIER\n      domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the\n      BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).\n      The BFIR router adds a BIER header to the packet.  The BIER header\n      contains a bit-string in which each bit represents exactly one BFER\n      to forward the packet to.  The set of BFERs to which the multicast\n      packet needs to be forwarded is expressed by setting the bits that\n      correspond to those routers in the BIER header.\n      \n      This document describes the mechanism and basic BIER OAM packet\n      format that can be used to perform failure detection and isolation on\n      BIER data plane.\n\n  "BGP Link-State extensions for BIER", Ran Chen, Zheng Zhang, Vengada\n  Govindan, IJsbrand Wijnands, 2019-10-30,\n  <draft-ietf-bier-bgp-ls-bier-ext-06.txt>\n\n      Bit Index Explicit Replication (BIER) is an architecture that\n      provides optimal multicast forwarding through a "BIER domain" without\n      requiring intermediate routers to maintain any multicast related per-\n      flow state.  BIER also does not require any explicit tree-building\n      protocol for its operation.  A multicast data packet enters a BIER\n      domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the\n      BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).\n      The BFIR router adds a BIER header to the packet.  The BIER header\n      contains a bitstring in which each bit represents exactly one BFER to\n      forward the packet to.  The set of BFERs to which the multicast\n      packet needs to be forwarded is expressed by setting the bits that\n      correspond to those routers in the BIER header.\n      \n      This document specifies extensions to the BGP Link-state address-\n      family in order to advertise BIER information.\n\n  "BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery\n  Protocols", Pierre Pfister, IJsbrand Wijnands, Stig Venaas, Cui(Linda)\n  Wang, Zheng Zhang, Markus Stenberg, 2019-11-04, <draft-ietf-bier-mld-03.txt>\n\n      This document specifies the ingress part of a multicast flow overlay\n      for BIER networks.  Using existing multicast listener discovery\n      protocols, it enables multicast membership information sharing from\n      egress routers, acting as listeners, toward ingress routers, acting\n      as queriers.  Ingress routers keep per-egress-router state, used to\n      construct the BIER bit mask associated with IP multicast packets\n      entering the BIER domain.\n\n  "EVPN BUM Using BIER", Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge\n  Rabadan, 2019-11-04, <draft-ietf-bier-evpn-02.txt>\n\n      This document specifies protocols and procedures for forwarding\n      broadcast, unknown unicast and multicast (BUM) traffic of Ethernet\n      VPNs (EVPN) using Bit Index Explicit Replication (BIER).\n\n  "Traffic Engineering for Bit Index Explicit Replication (BIER-TE)",\n  Toerless Eckert, Gregory Cauchie, Michael Menth, 2019-11-01,\n  <draft-ietf-bier-te-arch-05.txt>\n\n      This memo introduces per-packet stateless strict and loose path\n      engineered replication and forwarding for Bit Index Explicit\n      Replication packets ([RFC8279]).  This is called BIER-TE.\n      \n      BIER-TE leverages the BIER architecture ([RFC8279]) and extends it\n      with a new semantic for bits in the bitstring.  BIER-TE can leverage\n      BIER forwarding engines with little or no changes.\n      \n      In BIER, the BitPositions (BP) of the packets bitstring indicate BIER\n      Forwarding Egress Routers (BFER), and hop-by-hop forwarding uses a\n      Routing Underlay such as an IGP.\n      \n      In BIER-TE, BitPositions indicate adjacencies.  The BIFT of each BFR\n      are only populated with BPs that are adjacent to the BFR in the BIER-\n      TE topology.  The BIER-TE topology can consist of layer 2 or remote\n      (route) adjacencies.  The BFR then replicates and forwards BIER\n      packets to those adjacencies.  This results in the aforementioned\n      strict and loose path forwarding.\n      \n      BIER-TE can co-exist with BIER forwarding in the same domain, for\n      example by using separate sub-domains.  In the absence of routed\n      adjacencies, BIER-TE does not require a BIER routing underlay, and\n      can then be operated without requiring an IGP routing protocol.\n      \n      BIER-TE operates without explicit in-network tree-building and\n      carries the multicast distribution tree in the packet header.  It can\n      therefore be a good fit to support multicast path steering in Segment\n      Routing (SR) networks.\n\n  "PIM Signaling Through BIER Core", Hooman Bidgoli, Jayant Kotalwar, Fengman\n  Xu, mankamana mishra, Zhaohui Zhang, Andrew Dolganow, 2019-11-01,\n  <draft-ietf-bier-pim-signaling-08.txt>\n\n      Bit Index Explicit Replication (BIER) is an architecture that\n      provides multicast forwarding through a "BIER domain" without\n      requiring intermediate routers to maintain multicast related per-flow\n      state.  Neither does BIER require an explicit tree-building protocol\n      for its operation.  A multicast data packet enters a BIER domain at a\n      "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at\n      one or more "Bit-Forwarding Egress Routers" (BFERs).  The BFIR router\n      adds a BIER header to the packet.  Such header contains a bit-string\n      in which each bit represents exactly one BFER to forward the packet\n      to.  The set of BFERs to which the multicast packet needs to be\n      forwarded is expressed by the according set of bits switched on in\n      BIER packet header.\n      \n      This document describes the procedure needed for PIM Joins and Prunes\n      to be signaled through a BIER core. Allowing PIM routers to run\n      traditional PIM multicast services through a BIER core.\n\n  "BIER Underlay Path Calculation Algorithm and Constraints", Zhaohui Zhang,\n  Tony Przygienda, Andrew Dolganow, Hooman Bidgoli, IJsbrand Wijnands,\n  Arkadiy Gulko, 2019-11-04, <draft-ietf-bier-bar-ipa-06.txt>\n\n      This document specifies general rules for interaction between the BAR\n      (BIER Algorithm) and IPA (IGP Algorithm) fields defined in ISIS/\n      OSPFv2 Extensions for BIER.  The semantics for the BAR and IPA fields\n      (when both or any of them is non-zero) defined in this document\n      updates the semantics defined in RFC8444/RFC8401.\n\n  "An Optional Encoding of the BIFT-id Field in the non-MPLS BIER\n  Encapsulation", IJsbrand Wijnands, Xiaohu Xu, Hooman Bidgoli, 2019-08-09,\n  <draft-ietf-bier-non-mpls-bift-encoding-02.txt>\n\n      Bit Index Explicit Replication (BIER) is an architecture that\n      provides optimal multicast forwarding through a "multicast domain",\n      without requiring intermediate routers to maintain any per-flow state\n      or to engage in an explicit tree-building protocol.  The Multicast\n      packet is encapsulated using a BIER Header and transported through an\n      MPLS or non-MPLS network.  When MPLS is used as the transport, the\n      Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label.\n      When non-MPLS transport is used, the BIFT is identified by a 20bit\n      value.  This document describes one way of encoding the 20bit value.\n\n  "Use of BIER Entropy for Data Center Clos Networks", Jingrong Xie, Xiaohu\n  Xu, Gang Yan, Mike McBride, 2019-11-03,\n  <draft-ietf-bier-entropy-staged-dc-clos-02.txt>\n\n      Bit Index Explicit Replication (BIER) introduces a new multicast-\n      specific BIER Header.  BIER can be applied to the Multi Protocol\n      Label Switching (MPLS) data plane or Non-MPLS data plane.  Entropy is\n      a technique used in BIER to support load-balancing.  This document\n      examines and describes how BIER Entropy is to be applied to Data\n      Center Clos networks for path selection.\n\n  "BIER Penultimate Hop Popping", Zhaohui Zhang, 2019-10-31,\n  <draft-ietf-bier-php-04.txt>\n\n      Bit Index Explicit Replication (BIER) can be used as provider tunnel\n      for Multicast Virtual Private Network (MVPN) [RFC6514], Global\n      Table Multicast [RFC7716] or Ethernet Virtual Private Network (EVPN)\n      [RFC7432].  It is possible that not all routers in the provider\n      network support BIER and there are various methods to handle BIER\n      incapable transit routers.  However those methods assume the MVPN/\n      EVPN Provider Edges (PEs) are BIER capable.  This document specifies\n      a method to allow BIER incapable routers to act as MVPN/EVPN PEs with\n      BIER as the transport, by having the upstream BIER Forwarding Router\n      (BFR) that is connected directly or indirectly via a tunnel to a BIER\n      incapable PE remove the BIER header and send the payload to the PE.\n\n  "Applicability of BIER Multicast Overlay for Adaptive Streaming Services",\n  Dirk Trossen, Akbar Rahman, Chonggang Wang, Toerless Eckert, 2019-12-04,\n  <draft-ietf-bier-multicast-http-response-02.txt>\n\n      HTTP Level multicast, using BIER, is described as a use case in the\n      BIER Use Cases document.  HTTP Level Multicast is used in today\'s\n      video streaming and delivery services such as HLS, AR/VR etc.,\n      generally realized over IP Multicast as well as other use cases such\n      as software update delivery.  A realization of "HTTP Multicast" over\n      "IP Multicast" is described for the video delivery use case.  IP\n      multicast is commonly used for IPTV services.  DVB and BBF is also\n      developing a reference architecture for IP Multicast service.  A few\n      problems with IP Multicast, such as waste of transmission bandwidth,\n      increase in signaling when there are few users are described.\n      Realization over BIER, through a BIER Multicast Overlay Layer, is\n      described as an alternative.  How BIER Multicast Overlay operation\n      improves over IP Multicast, such as reduction in signaling, dynamic\n      creation of multicast groups to reduce signaling and bandwidth\n      wastage is described.  We conclude with few next steps.\n\n  "OSPFv3 Extensions for BIER", Peter Psenak, Nagendra Kumar, IJsbrand\n  Wijnands, 2019-11-24, <draft-ietf-bier-ospfv3-extensions-01.txt>\n\n      Bit Index Explicit Replication (BIER) is an architecture that\n      provides multicast forwarding through a "BIER domain" without\n      requiring intermediate routers to maintain multicast related per-flow\n      state.  Neither does BIER require an explicit tree-building protocol\n      for its operation.  A multicast data packet enters a BIER domain at a\n      "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at\n      one or more "Bit-Forwarding Egress Routers" (BFERs).  The BFIR router\n      adds a BIER header to the packet.  Such header contains a bit-string\n      in which each bit represents exactly one BFER to forward the packet\n      to.  The set of BFERs to which the multicast packet needs to be\n      forwarded is expressed by the according set of bits set in BIER\n      packet header.\n      \n      This document describes the OSPFv3 [RFC8362] protocol extensions\n      required for BIER with MPLS encapsulation [RFC8296].  Support for\n      other encapsulation types is outside the scope of this document.  The\n      use of multiple encapsulation types is outside the scope of this\n      document.\n\n  "BIER IPv6 Requirements", Mike McBride, Jingrong Xie, Senthil Dhanaraj,\n  Rajiv Asati, Yongqing Zhu, 2020-01-15,\n  <draft-ietf-bier-ipv6-requirements-04.txt>\n\n      The BIER WG includes, in its charter, work on developing mechanisms\n      to transport BIER natively in IPv6.  This document is intended to\n      help the WG with this effort by specifying requirements for\n      transporting packets, with Bit Index Explicit Replication (BIER)\n      headers, in an IPv6 environment.  There will be a need to send IPv6\n      payloads, to multiple IPv6 destinations, using BIER.  There have been\n      several proposed solutions in this area.  But there hasn\'t been a\n      document which describes the problem and lists the requirements.  The\n      goal of this document is to describe the BIER IPv6 requirements,\n      summarize the proposed solutions, and guide the working group in\n      understanding the benefits, and drawbacks, of the various solutions\n      and to help in the development of acceptable solutions.\n\nBenchmarking Methodology (bmwg)\n-------------------------------\n\n  "Benchmarking Methodology for EVPN and PBB-EVPN", sudhin jacob, Kishore\n  Tiruveedhula, 2019-12-18, <draft-ietf-bmwg-evpntest-04.txt>\n\n      This document defines methodologies for benchmarking EVPN and PBB-\n      EVPN performance.EVPN is defined in RFC 7432, and is being deployed\n      in Service Provider networks.Specifically, this document defines\n      the methodologies for benchmarking EVPN/PBB-EVPN convergence, data\n      plane and control plane performance.\n\n  "Benchmarking Methodology for Network Security Device Performance",\n  Balamuhunthan Balarajah, Carsten Rossenhoevel, bmonkman, 2019-11-19,\n  <draft-ietf-bmwg-ngfw-performance-02.txt>\n\n      This document provides benchmarking terminology and methodology for\n      next-generation network security devices including next-generation\n      firewalls (NGFW), intrusion detection and prevention solutions (IDS/\n      IPS) and unified threat management (UTM) implementations.  This\n      document aims to strongly improve the applicability, reproducibility,\n      and transparency of benchmarks and to align the test methodology with\n      today\'s increasingly complex layer 7 application use cases.  The main\n      areas covered in this document are test terminology, traffic profiles\n      and benchmarking methodology for NGFWs to start with.\n\n  "Updates for the Back-to-back Frame Benchmark in RFC 2544", Alfred Morton,\n  2019-11-18, <draft-ietf-bmwg-b2b-frame-01.txt>\n\n      Fundamental Benchmarking Methodologies for Network Interconnect\n      Devices of interest to the IETF are defined in RFC 2544.  This memo\n      updates the procedures of the test to measure the Back-to-back frames\n      Benchmark of RFC 2544, based on further experience.\n      \n      This memo updates Section 26.4 of RFC 2544.\n\nCalendaring Extensions (calext)\n-------------------------------\n\n  "Event Publishing Extensions to iCalendar", Michael Douglass, 2019-10-08,\n  <draft-ietf-calext-eventpub-extensions-15.txt,.pdf>\n\n      This specification updates RFC5545 by introducing a number of new\n      iCalendar properties and components which are of particular use for\n      event publishers and in social networking.\n      \n      This specification also defines a new STRUCTURED-DATA property for\n      iCalendar RFC5545 to allow for data that is directly pertinent to an\n      event or task to be included with the calendar data.\n\n  "JSCalendar: A JSON representation of calendar data", Neil Jenkins, Robert\n  Stepanek, 2019-12-04, <draft-ietf-calext-jscalendar-22.txt>\n\n      This specification defines a data model and JSON representation of\n      calendar data that can be used for storage and data exchange in a\n      calendaring and scheduling environment.  It aims to be an\n      alternative, and over time successor to, the widely deployed\n      iCalendar data format and to be unambiguous, extendable and simple to\n      process.  In contrast to the JSON-based jCal format, it is not a\n      direct mapping from iCalendar and expands semantics where\n      appropriate.\n\n  "Calendar subscription upgrades", Michael Douglass, 2019-11-03,\n  <draft-ietf-calext-subscription-upgrade-01.txt,.pdf>\n\n      This specification introduces an approach to allow subscribers to\n      calendar feeds to upgrade to a more performant protocol.\n      \n      This specification updates [RFC5545] to add the value DELETED to the\n      STATUS property.\n      \n      This specification also updates [RFC7240] to add the subscribe-\n      enhanced-get and limit preferences.\n\n  "VALARM Extensions for iCalendar", Cyrus Daboo, Ken Murchison, 2020-01-17,\n  <draft-ietf-calext-valarm-extensions-01.txt>\n\n      This document defines a set of extensions to the iCalendar VALARM\n      component to enhance use of alarms and improve interoperability\n      between clients and servers.\n\n  "Support for Series in iCalendar", Michael Douglass, 2019-10-30,\n  <draft-ietf-calext-icalendar-series-00.txt,.pdf>\n\n      This specification updates [RFC5545] by defining a new repeating set\n      of events known as a series.  This differs from recurrences in that\n      each instance is a separate entity with a parent relationship to a\n      specified template entity.\n\n  "VPOLL: Consensus Scheduling Component for iCalendar", Eric York, Cyrus\n  Daboo, Michael Douglass, 2019-11-21, <draft-ietf-calext-vpoll-00.txt,.pdf>\n\n      This specification introduces a new iCalendar component which allows\n      for consensus scheduling, that is, voting on a number of alternative\n      meeting or task alternatives.\n\n  "JSContact: A JSON representation of contact data", Robert Stepanek, Mario\n  Loffredo, 2020-01-17, <draft-ietf-calext-jscontact-00.txt>\n\n      This specification defines a data model and JSON representation of\n      contact card information that can be used for data storage and\n      exchange in address book or directory applications.  It aims to be an\n      alternative to the vCard data format and to be unambiguous,\n      extendable and simple to process.  In contrast to the JSON-based\n      jCard format, it is not a direct mapping from the vCard data model\n      and expands semantics where appropriate.\n\nCaptive Portal Interaction (capport)\n------------------------------------\n\n  "CAPPORT Architecture", Kyle Larose, David Dolson, 2019-12-31,\n  <draft-ietf-capport-architecture-05.txt>\n\n      This document aims to document consensus on the CAPPORT architecture.\n      DHCP or Router Advertisements, an optional signaling protocol, and an\n      HTTP API are used to provide the solution.  The role of Provisioning\n      Domains (PvDs) is described.\n\n  "Captive Portal API", Tommy Pauly, Darshak Thakore, 2020-01-02,\n  <draft-ietf-capport-api-04.txt>\n\n      This document describes an HTTP API that allows clients to interact\n      with a Captive Portal system.\n\n  "Captive-Portal Identification in DHCP / RA", Warren Kumari, Erik Kline,\n  2020-01-12, <draft-ietf-capport-rfc7710bis-01.txt>\n\n      In many environments offering short-term or temporary Internet access\n      (such as coffee shops), it is common to start new connections in a\n      captive portal mode.  This highly restricts what the customer can do\n      until the customer has authenticated.\n      \n      This document describes a DHCP option (and a Router Advertisement\n      (RA) extension) to inform clients that they are behind some sort of\n      captive-portal device, and that they will need to authenticate to get\n      Internet access.  It is not a full solution to address all of the\n      issues that clients may have with captive portals; it is designed to\n      be used in larger solutions.  The method of authenticating to, and\n      interacting with the captive portal is out of scope of this document.\n      \n      [ This document is being collaborated on in Github at:\n      https://github.com/wkumari/draft-ekwk-capport-rfc7710bis.  The most\n      recent version of the document, open issues, etc should all be\n      available here.  The authors (gratefully) accept pull requests.  Text\n      in square brackets will be removed before publication. ]\n\nConcise Binary Object Representation Maintenance and Extensions (cbor)\n----------------------------------------------------------------------\n\n  "Concise Binary Object Representation (CBOR)", Carsten Bormann, Paul\n  Hoffman, 2019-12-18, <draft-ietf-cbor-7049bis-12.txt>\n\n      The Concise Binary Object Representation (CBOR) is a data format\n      whose design goals include the possibility of extremely small code\n      size, fairly small message size, and extensibility without the need\n      for version negotiation.  These design goals make it different from\n      earlier binary serializations such as ASN.1 and MessagePack.\n      \n      This document is a revised edition of RFC 7049, with editorial\n      improvements, added detail, and fixed errata.  This revision formally\n      obsoletes RFC 7049, while keeping full compatibility of the\n      interchange format from RFC 7049.  It does not create a new version\n      of the format.\n\n  "Concise Binary Object Representation (CBOR) Tags for Typed Arrays",\n  Carsten Bormann, 2019-10-08, <draft-ietf-cbor-array-tags-08.txt>\n\n      The Concise Binary Object Representation (CBOR, RFC 7049) is a data\n      format whose design goals include the possibility of extremely small\n      code size, fairly small message size, and extensibility without the\n      need for version negotiation.\n      \n      The present document makes use of this extensibility to define a\n      number of CBOR tags for typed arrays of numeric data, as well as two\n      additional tags for multi-dimensional and homogeneous arrays.  It is\n      intended as the reference document for the IANA registration of the\n      CBOR tags defined.\n\n  "Concise Binary Object Representation (CBOR) Sequences", Carsten Bormann,\n  2019-09-25, <draft-ietf-cbor-sequence-02.txt>\n\n      This document describes the Concise Binary Object Representation\n      (CBOR) Sequence format and associated media type "application/cbor-\n      seq".  A CBOR Sequence consists of any number of encoded CBOR data\n      items, simply concatenated in sequence.\n      \n      Structured syntax suffixes for media types allow other media types to\n      build on them and make it explicit that they are built on an existing\n      media type as their foundation.  This specification defines and\n      registers "+cbor-seq" as a structured syntax suffix for CBOR\n      Sequences.\n\nCommon Control and Measurement Plane (ccamp)\n--------------------------------------------\n\n  "Information Model for Wavelength Switched Optical Networks (WSONs) with\n  Impairments Validation", Giovanni Martinelli, Haomian Zheng, Gabriele\n  Galimberti, Young Lee, Fatai Zhang, 2019-09-08,\n  <draft-ietf-ccamp-wson-iv-info-10.txt>\n\n      This document defines an information model to support Impairment-\n      Aware (IA) Routing and Wavelength Assignment (RWA) functionality.\n      This information model extends the information model for impairment-\n      free RWA process in WSON to facilitate computation of paths where\n      optical impairment constraints need to considered.\n\n  "A YANG Data Model for WSON (Wavelength Switched Optical Networks)",\n  Haomian Zheng, Young Lee, Aihua Guo, Victor Lopezalvarez, Daniel King,\n  2019-11-04, <draft-ietf-ccamp-wson-yang-23.txt>\n\n      This document provides a YANG data model for the routing and\n      wavelength assignment (RWA) TE topology in wavelength switched\n      optical networks (WSONs).  The YANG data model defined in this\n      document conforms to the Network Management Datastore Architecture\n      (NMDA).\n\n  "A YANG Data Model for Optical Transport Network Topology", Haomian Zheng,\n  Italo Busi, Xufeng Liu, Sergio Belotti, Oscar de Dios, 2019-11-02,\n  <draft-ietf-ccamp-otn-topo-yang-09.txt>\n\n      This document describes a YANG data model to describe the topologies\n      of an Optical Transport Network (OTN).  It is independent of control\n      plane protocols and captures topological and resource related\n      information pertaining to OTN.  This model enables clients, which\n      interact with a transport domain controller, for OTN topology related\n      operations such as obtaining the relevant topology resource\n      information.\n\n  "OTN Tunnel YANG Model", Haomian Zheng, Italo Busi, Sergio Belotti, Victor\n  Lopezalvarez, Yunbin Xu, 2019-11-02,\n  <draft-ietf-ccamp-otn-tunnel-model-09.txt>\n\n      This document describes the YANG data model for OTN Tunnels.\n\n  "YANG data model for Flexi-Grid Optical Networks", Universidad de Madrid,\n  Daniel Perdices, Victor Lopezalvarez, Daniel King, Young Lee, Haomian\n  Zheng, 2020-01-09, <draft-ietf-ccamp-flexigrid-yang-05.txt>\n\n      This document defines a YANG model for managing flexi-grid optical\n      Networks. The model described in this document defines a flexi-grid\n      traffic engineering database. A complementary module is referenced\n      to detail the flexi-grid media channels.\n      \n      This module is grounded on other defined YANG abstract models.\n\n  "A Yang Data Model for WSON Tunnel", Young Lee, Haomian Zheng, Aihua Guo,\n  Victor Lopezalvarez, Daniel King, Bin-Yeong Yoon, Ricard Vilata,\n  2019-09-11, <draft-ietf-ccamp-wson-tunnel-model-04.txt>\n\n      This document provides a YANG data model for WSON TE tunnel.\n\n  "Transport Northbound Interface Applicability Statement", Italo Busi,\n  Daniel King, Haomian Zheng, Yunbin Xu, 2019-11-19,\n  <draft-ietf-ccamp-transport-nbi-app-statement-10.txt>\n\n      This document provides an analysis of the applicability of the YANG\n      models defined by the IETF (Traffic Engineering Architecture and\n      Signaling (TEAS) moreover, Common Control and Measurement Plane\n      (CCAMP) WGs in particular) to support ODU transit services,\n      Transparent client services and EPL/EVPL Ethernet services over OTN\n      single and multi-domain network scenarios.\n      \n      This document also describes how existing YANG models can be used\n      through a number of worked examples and JSON fragments.\n\n  "A YANG Data Model for L1 Connectivity Service Model (L1CSM)", Young Lee,\n  Kwang-koog Lee, Haomian Zheng, Dhruv Dhody, Oscar de Dios, Daniele\n  Ceccarelli, 2019-09-09, <draft-ietf-ccamp-l1csm-yang-10.txt>\n\n      This document provides a YANG data model for Layer 1 Connectivity\n      Service Model (L1CSM).  The intent of this document is to provide a\n      Layer 1 service model exploiting YANG data model, which can be\n      utilized by a customer network controller to initiate a service\n      request connectivity as well as retrieving service states toward a\n      Layer 1 network controller communicating with its customer network\n      controller.  This YANG model is NMDA-compliant.\n\n  "Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense\n  Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the\n  application code of optical interface parameters in DWDM application",\n  Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze,\n  Dieter Beller, 2019-11-04, <draft-ietf-ccamp-dwdm-if-lmp-01.txt>\n\n      This memo defines extensions to LMP(rfc4209) for managing Optical\n      parameters associated with Wavelength Division Multiplexing (WDM)\n      systems in accordance with the Interface Application Identifier\n      approach defined in ITU-T Recommendation G.694.1.[ITU-T.G694.1] and\n      its extensions.\n\n  "A YANG model to manage the optical interface parameters for an external\n  transponder in a WDM network", Gabriele Galimberti, Ruediger Kunze, Dharini\n  Hiremagalur, Gert Grammel, 2019-11-04,\n  <draft-ietf-ccamp-dwdm-if-param-yang-02.txt>\n\n      This memo defines a Yang model related to the Optical Transceiver\n      parameters characterising coherent 100G and above interfaces.  100G\n      and above Transceivers support coherent modulation, multiple\n      modulation formats, multiple FEC codes including some not yet\n      specified (or by in phase of specification by) ITU-T G.698.2\n      [ITU.G698.2] or any other ITU-T recommendation.  More context about\n      the state of the Coherent transceivers is described in draft-many-\n      coherent-DWDM-if-control.  Use cases are described in RFC7698.\n      \n      The Yang model defined in this memo can be used for Optical\n      Parameters monitoring and/or configuration of the endpoints of a\n      multi-vendor IaDI optical link.  The use of this model does not\n      guarantee interworking of transceivers over a DWDM.  Optical path\n      feasibility and interoperability has to be determined by means\n      outside the scope of this document.  The purpose of this model is to\n      program interface parameters to consistently configure the mode of\n      operation of transceivers.\n\n  "A Yang Data Model for Optical Impairment-aware Topology", Young Lee,\n  Victor Lopezalvarez, Gabriele Galimberti, Luc Auge, Dieter Beller,\n  2019-11-04, <draft-ietf-ccamp-optical-impairment-topology-yang-02.txt>\n\n      In order to provision an optical connection through optical\n      networks, a combination of path continuity, resource availability,\n      and impairment constraints must be met to determine viable and\n      optimal paths through the network. The determination of appropriate\n      paths is known as Impairment-Aware Routing and Wavelength Assignment\n      (IA-RWA) for WSON, while it is known as Impairment-Aware Routing and\n      Spectrum Assigment (IA-RSA) for SSON.\n      \n      This document provides a YANG data model for the impairment-aware TE\n      topology in optical networks.\n\n  "A YANG Data Model for Layer 0 Types", Haomian Zheng, Young Lee, Aihua Guo,\n  Victor Lopezalvarez, Daniel King, 2019-11-28,\n  <draft-ietf-ccamp-layer0-types-03.txt>\n\n      This document defines a collection of common data types and groupings\n      in the YANG data modeling language.  These derived common types and\n      groupings are intended to be imported by modules that model Layer 0\n      optical Traffic Engineering (TE) configuration and state capabilities\n      such as Wavelength Switched Optical Networks (WSONs) and Flexi-grid\n      Dense Wavelength Division Multiplexing (DWDM) Networks.\n\n  "A YANG Data Model for Transport Network Client Signals", Haomian Zheng,\n  Aihua Guo, Italo Busi, Anton Snitser, Francesco Lazzeri, Yunbin Xu, Yang\n  Zhao, Xufeng Liu, Giuseppe Fioccola, 2019-11-03,\n  <draft-ietf-ccamp-client-signal-yang-01.txt>\n\n      A transport network is a server-layer network to provide connectivity\n      services to its client.  The topology and tunnel information in the\n      transport layer has already been defined by generic Traffic-\n      engineered models and technology-specific models (e.g., OTN, WSON).\n      However, how the client signals are accessing to the network has not\n      been described.  These information is necessary to both client and\n      provider.\n      \n      This draft describes how the client signals are carried over\n      transport network and defines YANG data models which are required\n      during configuration procedure.  More specifically, several client\n      signal (of transport network) models including ETH, STM-n, FC and so\n      on, are defined in this draft.\n\n  "A YANG Data Model for Layer 1 Types", Haomian Zheng, Italo Busi,\n  2019-12-05, <draft-ietf-ccamp-layer1-types-04.txt>\n\n      This document defines a collection of common data types and groupings\n      in YANG data modeling language for layer 1 networks.  These derived\n      common types and groupings are intended to be imported by modules\n      that specifies the OTN networks, including the topology, tunnel,\n      client signal adaptation and service.\n\nContent Delivery Networks Interconnection (cdni)\n------------------------------------------------\n\n  "URI Signing for CDN Interconnection (CDNI)", Ray van Brandenburg, Kent\n  Leung, Phil Sorber, 2019-10-08, <draft-ietf-cdni-uri-signing-19.txt>\n\n      This document describes how the concept of URI signing supports the\n      content access control requirements of CDNI and proposes a URI\n      signing method as a JSON Web Token (JWT) profile.\n      \n      The proposed URI signing method specifies the information needed to\n      be included in the URI to transmit the signed JWT, as well as the\n      claims needed by the signed JWT to authorize a UA.  The mechanism\n      described can be used both in CDNI and single CDN scenarios.\n\n  "CDNI Request Routing Extensions", Ori Finkelman, Sanjay Mishra,\n  2019-11-20, <draft-ietf-cdni-request-routing-extensions-08.txt>\n\n      Open Caching architecture is a use case of Content Delivery Networks\n      Interconnection (CDNI) in which the commercial Content Delivery\n      Network (CDN) is the upstream CDN (uCDN) and the ISP caching layer\n      serves as the downstream CDN (dCDN).  The extensions specified in\n      this document to the CDNI Metadata Interface (MI) and the Footprint\n      and Capabilities Interface (FCI) are derived from requirements raised\n      by Open Caching but are also applicable to CDNI use cases in general.\n\n  "CDNI extensions for HTTPS delegation", Frederic Fieau, Stephan Emile,\n  Sanjay Mishra, 2019-11-04,\n  <draft-ietf-cdni-interfaces-https-delegation-02.txt>\n\n      The delivery of content over HTTPS involving multiple CDNs raises\n      credential management issues.  This document proposes extensions in\n      CDNI Control and Metadata interfaces to setup HTTPS delegation from\n      an Upstream CDN (uCDN) to a Downstream CDN (dCDN).\n\n  "CDNI Control Triggers Interface Extensions", Ori Finkelman, Sanjay Mishra,\n  2019-09-24, <draft-ietf-cdni-triggers-extensions-03.txt>\n\n      This document updates RFC 8007 to include generic extensions and more\n      granular content matching options, required by the Open Caching\n      architecture.  The Open Caching working group of the Streaming Video\n      Alliance is focused on the delegation of video delivery request from\n      commercial CDNs to a caching layer at the ISP.  In that aspect, Open\n      Caching is a specific use case of CDNI, where the commercial CDN is\n      the upstream CDN (uCDN) and the ISP caching layer is the downstream\n      CDN (dCDN).  The extensions specified in this document to the CDNI\n      Control Interface / Triggers are derived from requirements of Open\n      Caching but are applicable to CDNI use cases in general.\n\nCodec Encoding for LossLess Archiving and Realtime transmission (cellar)\n------------------------------------------------------------------------\n\n  "Extensible Binary Meta Language", Steve Lhomme, Dave Rice, Moritz Bunkus,\n  2020-01-27, <draft-ietf-cellar-ebml-17.txt>\n\n      This document defines the Extensible Binary Meta Language (EBML)\n      format as a binary container format designed for audio/video storage.\n      EBML is designed as a binary equivalent to XML and uses a storage-\n      efficient approach to build nested Elements with identifiers,\n      lengths, and values.  Similar to how an XML Schema defines the\n      structure and semantics of an XML Document, this document defines how\n      EBML Schemas are created to convey the semantics of an EBML Document.\n\n  "FFV1 Video Coding Format Version 0, 1, and 3", Michael Niedermayer, Dave\n  Rice, Jerome Martinez, 2020-01-27, <draft-ietf-cellar-ffv1-12.txt>\n\n      This document defines FFV1, a lossless intra-frame video encoding\n      format.  FFV1 is designed to efficiently compress video data in a\n      variety of pixel formats.  Compared to uncompressed video, FFV1\n      offers storage compression, frame fixity, and self-description, which\n      makes FFV1 useful as a preservation or intermediate video format.\n\n  "FFV1 Video Coding Format Version 4", Michael Niedermayer, Dave Rice,\n  Jerome Martinez, 2020-01-27, <draft-ietf-cellar-ffv1-v4-09.txt>\n\n      This document defines FFV1, a lossless intra-frame video encoding\n      format.  FFV1 is designed to efficiently compress video data in a\n      variety of pixel formats.  Compared to uncompressed video, FFV1\n      offers storage compression, frame fixity, and self-description, which\n      makes FFV1 useful as a preservation or intermediate video format.\n\n  "Matroska Specifications", Steve Lhomme, Moritz Bunkus, Dave Rice,\n  2019-10-27, <draft-ietf-cellar-matroska-04.txt>\n\n      This document defines the Matroska audiovisual container, including\n      definitions of its structural elements, as well as its terminology,\n      vocabulary, and application.\n\n  "Matroska Codec", Steve Lhomme, Moritz Bunkus, Dave Rice, 2019-10-27,\n  <draft-ietf-cellar-codec-03.txt>\n\n      This document defines the Matroska codec mappings, including the\n      codec ID, layout of data in a "Block Element" and in an optional\n      "CodecPrivate Element".\n\n  "Matroska Tags", Steve Lhomme, Moritz Bunkus, Dave Rice, 2019-10-27,\n  <draft-ietf-cellar-tags-03.txt>\n\n      This document defines the Matroska tags, namely the tag names and\n      their respective semantic meaning.\n\n  "Free Lossless Audio Codec", Josh Coalson, , Andrew Weaver, 2019-07-30,\n  <draft-ietf-cellar-flac-00.txt>\n\n      This document defines FLAC, which stands for Free Lossless Audio\n      Codec, a free, open source codec for lossless audio compression and\n      decompression.\n\nCrypto Forum (cfrg)\n-------------------\n\n  "SPAKE2, a PAKE", Watson Ladd, Benjamin Kaduk, 2019-10-03,\n  <draft-irtf-cfrg-spake2-09.txt>\n\n      This document describes SPAKE2 which is a protocol for two parties\n      that share a password to derive a strong shared key with no risk of\n      disclosing the password.  This method is compatible with any group,\n      is computationally efficient, and SPAKE2 has a security proof.\n\n  "The memory-hard Argon2 password hash and proof-of-work function", Alex\n  Biryukov, Daniel Dinu, Dmitry Khovratovich, Simon Josefsson, 2019-11-21,\n  <draft-irtf-cfrg-argon2-09.txt>\n\n      This document describes the Argon2 memory-hard function for password\n      hashing and proof-of-work applications.  We provide an implementer-\n      oriented description with test vectors.  The purpose is to simplify\n      adoption of Argon2 for Internet protocols.  This document is a\n      product of the Crypto Forum Research Group (CFRG) in the IRTF.\n\n  "The Transition from Classical to Post-Quantum Cryptography", Paul Hoffman,\n  2019-11-25, <draft-hoffman-c2pq-06.txt>\n\n      Quantum computing is the study of computers that use quantum features\n      in calculations.  For over 20 years, it has been known that if very\n      large, specialized quantum computers could be built, they could have\n      a devastating effect on asymmetric classical cryptographic algorithms\n      such as RSA and elliptic curve signatures and key exchange, as well\n      as (but in smaller scale) on symmetric cryptographic algorithms such\n      as block ciphers, MACs, and hash functions.  There has already been a\n      great deal of study on how to create algorithms that will resist\n      large, specialized quantum computers, but so far, the properties of\n      those algorithms make them onerous to adopt before they are needed.\n      \n      Small quantum computers are being built today, but it is still far\n      from clear when large, specialized quantum computers will be built\n      that can recover private or secret keys in classical algorithms at\n      the key sizes commonly used today.  It is important to be able to\n      predict when large, specialized quantum computers usable for\n      cryptanalysis will be possible so that organization can change to\n      post-quantum cryptographic algorithms well before they are needed.\n      \n      This document describes quantum computing, how it might be used to\n      attack classical cryptographic algorithms, and possibly how to\n      predict when large, specialized quantum computers will become\n      feasible.\n\n  "Verifiable Random Functions (VRFs)", Sharon Goldberg, Leonid Reyzin,\n  Dimitrios Papadopoulos, Jan Vcelak, 2019-08-11, <draft-irtf-cfrg-vrf-05.txt>\n\n      A Verifiable Random Function (VRF) is the public-key version of a\n      keyed cryptographic hash.  Only the holder of the private key can\n      compute the hash, but anyone with public key can verify the\n      correctness of the hash.  VRFs are useful for preventing enumeration\n      of hash-based data structures.  This document specifies several VRF\n      constructions that are secure in the cryptographic random oracle\n      model.  One VRF uses RSA and the other VRF uses Eliptic Curves (EC).\n\n  "Randomness Improvements for Security Protocols", Cas Cremers, Luke\n  Garratt, Stanislav Smyshlyaev, Nick Sullivan, Christopher Wood, 2020-01-27,\n  <draft-irtf-cfrg-randomness-improvements-09.txt>\n\n      Randomness is a crucial ingredient for TLS and related security\n      protocols.  Weak or predictable "cryptographically-strong"\n      pseudorandom number generators (CSPRNGs) can be abused or exploited\n      for malicious purposes.  The Dual EC random number backdoor and\n      Debian bugs are relevant examples of this problem.  An initial\n      entropy source that seeds a CSPRNG might be weak or broken as well,\n      which can also lead to critical and systemic security problems.  This\n      document describes a way for security protocol participants to\n      augment their CSPRNGs using long-term private keys.  This improves\n      randomness from broken or otherwise subverted CSPRNGs.\n\n  "Hashing to Elliptic Curves", Armando Faz-Hernandez, Sam Scott, Nick\n  Sullivan, Riad Wahby, Christopher Wood, 2019-11-02,\n  <draft-irtf-cfrg-hash-to-curve-05.txt>\n\n      This document specifies a number of algorithms that may be used to\n      encode or hash an arbitrary string to a point on an elliptic curve.\n\n  "XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305", Scott\n  Arciszewski, 2020-01-10, <draft-irtf-cfrg-xchacha-03.txt>\n\n      The eXtended-nonce ChaCha cipher construction (XChaCha) allows for\n      ChaCha-based ciphersuites to accept a 192-bit nonce with similar\n      guarantees to the original construction, except with a much lower\n      probability of nonce misuse occurring.  This helps for long running\n      TLS connections.  This also enables XChaCha constructions to be\n      stateless, while retaining the same security assumptions as ChaCha.\n      \n      This document defines XChaCha20, which uses HChaCha20 to convert the\n      key and part of the nonce into a subkey, which is in turn used with\n      the remainder of the nonce with ChaCha20 to generate a pseudorandom\n      keystream (e.g. for message encryption).\n      \n      This document also defines AEAD_XChaCha20_Poly1305, a variant of\n      [RFC8439] that utilizes the XChaCha20 construction in place of\n      ChaCha20.\n\n  "Hybrid Public Key Encryption", Richard Barnes, Karthikeyan Bhargavan,\n  2019-11-04, <draft-irtf-cfrg-hpke-02.txt>\n\n      This document describes a scheme for hybrid public-key encryption\n      (HPKE).  This scheme provides authenticated public key encryption of\n      arbitrary-sized plaintexts for a recipient public key.  HPKE works\n      for any combination of an asymmetric key encapsulation mechanism\n      (KEM), key derivation function (KDF), and authenticated encryption\n      with additional data (AEAD) encryption function.  We provide\n      instantiations of the scheme using widely-used and efficient\n      primitives.\n\n  "Oblivious Pseudorandom Functions (OPRFs) using Prime-Order Groups", Alex\n  Davidson, Nick Sullivan, Christopher Wood, 2019-11-04,\n  <draft-irtf-cfrg-voprf-02.txt>\n\n      An Oblivious Pseudorandom Function (OPRF) is a two-party protocol for\n      computing the output of a PRF.  One party (the server) holds the PRF\n      secret key, and the other (the client) holds the PRF input.  The\n      \'obliviousness\' property ensures that the server does not learn\n      anything about the client\'s input during the evaluation.  The client\n      should also not learn anything about the server\'s secret PRF key.\n      Optionally, OPRFs can also satisfy a notion \'verifiability\' (VOPRF).\n      In this setting, the client can verify that the server\'s output is\n      indeed the result of evaluating the underlying PRF with just a public\n      key.  This document specifies OPRF and VOPRF constructions\n      instantiated within prime-order groups, including elliptic curves.\n\n  "KangarooTwelve", Benoit Viguier, David Wong, Giles Van Assche, Quynh Dang,\n  Joan Daemen, 2020-01-24, <draft-irtf-cfrg-kangarootwelve-01.txt>\n\n      This document defines the KangarooTwelve eXtendable Output Function\n      (XOF), a hash function with output of arbitrary length.  It provides\n      an efficient and secure hashing primitive, which is able to exploit\n      the parallelism of the implementation in a scalable way.  It uses\n      tree hashing over a round-reduced version of SHAKE128 as underlying\n      primitive.\n      \n      This document builds up on the definitions of the permutations and of\n      the sponge construction in [FIPS 202], and is meant to serve as a\n      stable reference and an implementation guide.\n\n  "draft-irtf-cfrg-bls-signature-00.txt", Dan Boneh, Riad Wahby, Sergey\n  Gorbunov, Hoeteck Wee, Zhenfei Zhang, 2019-08-12,\n  <draft-irtf-cfrg-bls-signature-00.txt>\n\n      BLS is a digital signature scheme with compression properties.  With\n      a given set of signatures (signature_1, ..., signature_n) anyone can\n      produce a compressed signature signature_compressed.  The same is\n      true for a set of secret keys or public keys, while keeping the\n      connection between sets (i.e., a compressed public key is associated\n      to its compressed secret key).  Furthermore, the BLS signature scheme\n      is deterministic, non-malleable, and efficient.  Its simplicity and\n      cryptographic properties allows it to be useful in a variety of use-\n      cases, specifically when minimal storage space or bandwidth are\n      required.\n\n  "Pairing-Friendly Curves", Yumi Sakemi, Tetsutaro Kobayashi, Tsunekazu\n  Saito, 2019-11-01, <draft-irtf-cfrg-pairing-friendly-curves-00.txt>\n\n      This memo introduces pairing-friendly curves used for constructing\n      pairing-based cryptography.  It describes recommended parameters for\n      each security level and recent implementations of pairing-friendly\n      curves.\n\nControLling mUltiple streams for tElepresence (clue)\n----------------------------------------------------\n\n  "Framework for Telepresence Multi-Streams", Mark Duckworth, Andrew\n  Pepperell, Stephan Wenger, 2016-01-08, <draft-ietf-clue-framework-25.txt>\n\n      This document defines a framework for a protocol to enable devices\n      in a telepresence conference to interoperate.  The protocol enables\n      communication of information about multiple media streams so a\n      sending system and receiving system can make reasonable decisions\n      about transmitting, selecting and rendering the media streams.\n      This protocol is used in addition to SIP signaling and SDP\n      negotiation for setting up a telepresence session.\n\n  "Mapping RTP streams to CLUE Media Captures", Roni Even, Jonathan Lennox,\n  2017-02-27, <draft-ietf-clue-rtp-mapping-14.txt,.pdf>\n\n      This document describes how the Real Time transport Protocol (RTP) is\n      used in the context of the CLUE protocol (ControLling mUltiple\n      streams for tElepresence).  It also describes the mechanisms and\n      recommended practice for mapping RTP media streams defined in Session\n      Description Protocol (SDP) to CLUE Media Captures and defines a new\n      RTP header extension (CaptureId).\n\n  "An XML Schema for the CLUE data model", Roberta Presta, Simon Romano,\n  2016-08-13, <draft-ietf-clue-data-model-schema-17.txt>\n\n      This document provides an XML schema file for the definition of CLUE\n      data model types.  The term "CLUE" stands for "ControLling mUltiple\n      streams for tElepresence" and is the name of the IETF working group\n      in which this document, as well as other companion documents, has\n      been developed.  The document defines a coherent structure for\n      information associated with the description of a telepresence\n      scenario.\n\n  "CLUE Protocol data channel", Christer Holmberg, 2019-04-24,\n  <draft-ietf-clue-datachannel-18.txt>\n\n      This document defines how to use the WebRTC data channel mechanism to\n      realize a data channel, referred to as a CLUE data channel, for\n      transporting CLUE protocol messages between two CLUE entities.\n\n  "Session Signaling for Controlling Multiple Streams for Telepresence\n  (CLUE)", Robert Hansen, Paul Kyzivat, Lennard Xiao, Christian Groves,\n  2019-12-09, <draft-ietf-clue-signaling-15.txt>\n\n      This document specifies how CLUE-specific signaling such as the CLUE\n      protocol and the CLUE data channel are used in conjunction with each\n      other and with existing signaling mechanisms such as SIP and SDP to\n      produce a telepresence call.\n\n  "Protocol for Controlling Multiple Streams for Telepresence (CLUE)",\n  Roberta Presta, Simon Romano, 2019-07-05, <draft-ietf-clue-protocol-19.txt>\n\n      The CLUE protocol is an application protocol conceived for the\n      description and negotiation of a telepresence session.  The design of\n      the CLUE protocol takes into account the requirements and the\n      framework defined within the IETF CLUE working group.  A companion\n      document delves into CLUE signaling details, as well as on the SIP/\n      SDP session establishment phase.  CLUE messages flow over the CLUE\n      data channel, based on reliable and ordered SCTP over DTLS transport.\n      Message details, together with the behavior of CLUE Participants\n      acting as Media Providers and/or Media Consumers, are herein\n      discussed.\n\nConstrained RESTful Environments (core)\n---------------------------------------\n\n  "CoRE Resource Directory", Zach Shelby, Michael Koster, Carsten Bormann,\n  Peter van der Stok, Christian Amsuess, 2019-07-08,\n  <draft-ietf-core-resource-directory-23.txt>\n\n      In many IoT applications, direct discovery of resources is not\n      practical due to sleeping nodes, disperse networks, or networks where\n      multicast traffic is inefficient.  These problems can be solved by\n      employing an entity called a Resource Directory (RD), which contains\n      information about resources held on other servers, allowing lookups\n      to be performed for those resources.  The input to an RD is composed\n      of links and the output is composed of links constructed from the\n      information stored in the RD.  This document specifies the web\n      interfaces that a Resource Directory supports for web servers to\n      discover the RD and to register, maintain, lookup and remove\n      information on resources.  Furthermore, new target attributes useful\n      in conjunction with an RD are defined.\n\n  "CBOR Encoding of Data Modeled with YANG", Michel Veillette, Ivaylo Petrov,\n  Alexander Pelov, 2019-09-11, <draft-ietf-core-yang-cbor-11.txt>\n\n      This document defines encoding rules for serializing configuration\n      data, state data, RPC input and RPC output, Action input, Action\n      output, notifications and yang data template defined within YANG\n      modules using the Concise Binary Object Representation (CBOR)\n      [RFC7049].\n\n  "Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)",\n  Michael Koster, Ari Keranen, Jaime Jimenez, 2019-09-30,\n  <draft-ietf-core-coap-pubsub-09.txt>\n\n      The Constrained Application Protocol (CoAP), and related extensions\n      are intended to support machine-to-machine communication in systems\n      where one or more nodes are resource constrained, in particular for\n      low power wireless sensor networks.  This document defines a publish-\n      subscribe Broker for CoAP that extends the capabilities of CoAP for\n      supporting nodes with long breaks in connectivity and/or up-time.\n      \n      There is work in progress to resolve some of the transfer layer\n      issues by using a more RESTful approach.\n      \n      Please see https://github.com/core-wg/pubsub/blob/master/proposal.txt\n\n  "YANG Schema Item iDentifier (SID)", Michel Veillette, Alexander Pelov,\n  Ivaylo Petrov, 2020-01-23, <draft-ietf-core-sid-09.txt>\n\n      YANG Schema Item iDentifiers (SID) are globally unique 63-bit\n      unsigned integers used to identify YANG items.  This document defines\n      the semantics, the registration, and assignment processes of SIDs.\n      To enable the implementation of these processes, this document also\n      defines a file format used to persist and publish assigned SIDs.\n\n  "CoAP Management Interface", Michel Veillette, Peter van der Stok,\n  Alexander Pelov, Andy Bierman, Ivaylo Petrov, 2019-09-27,\n  <draft-ietf-core-comi-08.txt>\n\n      This document describes a network management interface for\n      constrained devices and networks, called CoAP Management Interface\n      (CoMI).  The Constrained Application Protocol (CoAP) is used to\n      access datastore and data node resources specified in YANG, or SMIv2\n      converted to YANG.  CoMI uses the YANG to CBOR mapping and converts\n      YANG identifier strings to numeric identifiers for payload size\n      reduction.  The complete solution composed of CoMI,\n      [I-D.ietf-core-yang-cbor] and [I-D.ietf-core-sid] is called CORECONF.\n      CORECONF extends the set of YANG based protocols, NETCONF and\n      RESTCONF, with the capability to manage constrained devices and\n      networks.\n\n  "CoAP: Echo, Request-Tag, and Token Processing", Christian Amsuess, John\n  Mattsson, Goeran Selander, 2019-11-04,\n  <draft-ietf-core-echo-request-tag-08.txt>\n\n      This document specifies enhancements to the Constrained Application\n      Protocol (CoAP) that mitigate security issues in particular use\n      cases.  The Echo option enables a CoAP server to verify the freshness\n      of a request or to force a client to demonstrate reachability at its\n      claimed network address.  The Request-Tag option allows the CoAP\n      server to match block-wise message fragments belonging to the same\n      request.  The update to the client Token processing requirements of\n      RFC 7252 forbids non-secure reuse of Tokens to ensure binding of\n      responses to requests when CoAP is used with security.\n\n  "Group OSCORE - Secure Group Communication for CoAP", Marco Tiloca, Goeran\n  Selander, Francesca Palombini, Jiye Park, 2019-11-04,\n  <draft-ietf-core-oscore-groupcomm-06.txt>\n\n      This document describes a mode for protecting group communication\n      over the Constrained Application Protocol (CoAP).  The proposed mode\n      relies on Object Security for Constrained RESTful Environments\n      (OSCORE) and the CBOR Object Signing and Encryption (COSE) format.\n      In particular, it defines how OSCORE is used in a group communication\n      setting, while fulfilling the same security requirements for group\n      requests and responses.  Source authentication of all messages\n      exchanged within the group is provided by means of digital signatures\n      produced by the sender and embedded in the protected CoAP messages.\n\n  "Uniform Resource Names for Device Identifiers", Jari Arkko, Cullen\n  Jennings, Zach Shelby, 2019-12-13, <draft-ietf-core-dev-urn-04.txt>\n\n      This memo describes a new Uniform Resource Name (URN) namespace for\n      hardware device identifiers.  A general representation of device\n      identity can be useful in many applications, such as in sensor data\n      streams and storage, or equipment inventories.  A URN-based\n      representation can be easily passed along in any application that\n      needs the information.\n\n  "Multipart Content-Format for CoAP", Thomas Fossati, Klaus Hartke, Carsten\n  Bormann, 2019-08-21, <draft-ietf-core-multipart-ct-04.txt>\n\n      This memo defines application/multipart-core, an application-\n      independent media-type that can be used to combine representations of\n      zero or more different media types into a single message, such as a\n      CoAP request or response body, with minimal framing overhead, each\n      along with a CoAP Content-Format identifier.\n\n  "Constrained Application Protocol (CoAP) Hop-Limit Option", Mohamed\n  Boucadair, Tirumaleswar Reddy.K, Jon Shallow, 2019-10-17,\n  <draft-ietf-core-hop-limit-07.txt>\n\n      The presence of Constrained Application Protocol (CoAP) proxies may\n      lead to infinite forwarding loops, which is undesirable.  To prevent\n      and detect such loops, this document specifies the Hop-Limit CoAP\n      option.\n\n  "FETCH & PATCH with Sensor Measurement Lists (SenML)", Ari Keranen, Mojan\n  Mohajer, 2019-12-27, <draft-ietf-core-senml-etch-06.txt>\n\n      The Sensor Measurement Lists (SenML) media type and data model can be\n      used to send collections of resources, such as batches of sensor data\n      or configuration parameters.  The CoAP FETCH, PATCH, and iPATCH\n      methods enable accessing and updating parts of a resource or multiple\n      resources with one request.  This document defines new media types\n      for the CoAP FETCH, PATCH, and iPATCH methods for resources\n      represented with the SenML data model.\n\n  "Extended Tokens and Stateless Clients in the Constrained Application\n  Protocol (CoAP)", Klaus Hartke, 2019-12-06,\n  <draft-ietf-core-stateless-04.txt>\n\n      This document provides considerations for alleviating CoAP clients\n      and intermediaries of keeping per-request state.  To facilitate this,\n      this document additionally introduces a new, optional CoAP protocol\n      extension for extended token lengths.\n      \n      This document updates RFCs 7252 and 8323.\n\n  "Constrained YANG Module Library", Michel Veillette, Ivaylo Petrov,\n  2020-01-23, <draft-ietf-core-yang-library-01.txt>\n\n      This document describes a constrained version of the YANG library\n      that provides information about the YANG modules, datastores, and\n      datastore schemas used by a constrained network management server\n      (e.g., a CORECONF server).\n\n  "SenML Data Value Content-Format Indication", Ari Keranen, Carsten Bormann,\n  2019-11-04, <draft-ietf-core-senml-data-ct-01.txt>\n\n      The Sensor Measurement Lists (SenML) media type supports multiple\n      types of values, from numbers to text strings and arbitrary binary\n      data values.  In order to simplify processing of the data values this\n      document proposes to specify a new SenML field for indicating the\n      Content-Format of the data.\n\n  "The Constrained RESTful Application Language (CoRAL)", Klaus Hartke,\n  2020-01-08, <draft-ietf-core-coral-02.txt>\n\n      The Constrained RESTful Application Language (CoRAL) defines a data\n      model and interaction model as well as two specialized serialization\n      formats for the description of typed connections between resources on\n      the Web ("links"), possible operations on such resources ("forms"),\n      and simple resource metadata.\n\n  "Constrained Resource Identifiers", Klaus Hartke, 2020-01-08,\n  <draft-ietf-core-href-02.txt>\n\n      Constrained Resource Identifiers (CoRIs) are an alternate\n      serialization of Uniform Resource Identifiers (URIs) that encodes the\n      URI components in Concise Binary Object Representation (CBOR) instead\n      of a string of characters.  This simplifies parsing, reference\n      resolution, and comparison of URIs in environments with severe\n      limitations on processing power, code size, and memory size.\n\n  "Additional Units for SenML", Carsten Bormann, 2019-11-04,\n  <draft-ietf-core-senml-more-units-03.txt>\n\n      The Sensor Measurement Lists (SenML) media type supports the\n      indication of units for a quantity represented.  This short document\n      registers a number of additional unit names in the IANA registry for\n      Units in SenML.  It also defines a registry for secondary units that\n      cannot be in SenML\'s main registry as they are derived by linear\n      transformation from units already in that registry; RFC 8428 is\n      updated to also accept these units.\n\nCBOR Object Signing and Encryption (cose)\n-----------------------------------------\n\n  "Use of the HSS/LMS Hash-based Signature Algorithm with CBOR Object Signing\n  and Encryption (COSE)", Russ Housley, 2019-12-11,\n  <draft-ietf-cose-hash-sig-09.txt>\n\n      This document specifies the conventions for using the Hierarchical\n      Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based\n      signature algorithm with the CBOR Object Signing and Encryption\n      (COSE) syntax.  The HSS/LMS algorithm is one form of hash-based\n      digital signature; it is described in RFC 8554.\n\n  "CBOR Object Signing and Encryption (COSE): Structures and Process", Jim\n  Schaad, 2019-11-17, <draft-ietf-cose-rfc8152bis-struct-07.txt>\n\n      Concise Binary Object Representation (CBOR) is a data format designed\n      for small code size and small message size.  There is a need for the\n      ability to have basic security services defined for this data format.\n      This document defines the CBOR Object Signing and Encryption (COSE)\n      protocol.  This specification describes how to create and process\n      signatures, message authentication codes, and encryption using CBOR\n      for serialization.  This specification additionally describes how to\n      represent cryptographic keys using CBOR.\n      \n      This document along with [I-D.ietf-cose-rfc8152bis-algs] obsoletes\n      RFC8152.\n\n  "CBOR Object Signing and Encryption (COSE): Initial Algorithms", Jim\n  Schaad, 2019-11-04, <draft-ietf-cose-rfc8152bis-algs-06.txt>\n\n      Concise Binary Object Representation (CBOR) is a data format designed\n      for small code size and small message size.  There is a need for the\n      ability to have basic security services defined for this data format.\n      This document defines the CBOR Object Signing and Encryption (COSE)\n      protocol.  This specification describes how to create and process\n      signatures, message authentication codes, and encryption using CBOR\n      for serialization.  COSE additionally describes how to represent\n      cryptographic keys using CBOR.\n      \n      In this specification the conventions for the use of a number of\n      cryptographic algorithms with COSE.  The details of the structure of\n      COSE are defined in [I-D.ietf-cose-rfc8152bis-struct].\n      \n      This document along with [I-D.ietf-cose-rfc8152bis-struct] obsoletes\n      RFC8152.\n\n  "CBOR Object Signing and Encryption (COSE): Headers for carrying and\n  referencing X.509 certificates", Jim Schaad, 2019-11-04,\n  <draft-ietf-cose-x509-05.txt>\n\n      The CBOR Signing And Encrypted Message (COSE) structure uses\n      references to keys in general.  For some algorithms, additional\n      properties are defined which carry parts of keys as needed.  The COSE\n      Key structure is used for transporting keys outside of COSE messages.\n      This document extends the way that keys can be identified and\n      transported by providing attributes that refer to or contain X.509\n      certificates.\n\n  "CBOR Object Signing and Encryption (COSE): Hash Algorithms", Jim Schaad,\n  2019-11-04, <draft-ietf-cose-hash-algs-02.txt>\n\n      The CBOR Object Signing and Encryption (COSE) syntax\n      [I-D.ietf-cose-rfc8152bis-struct] does not define any direct methods\n      for using hash algorithms.  There are however circumstances where\n      hash algorithms are used: Indirect signatures where the hash of one\n      or more contents are signed.  X.509 certificate or other object\n      identification by the use of a thumbprint.  This document defines a\n      set of hash algorithms that are identified by COSE Algorithm\n      Identifiers.\n\n  "COSE and JOSE Registrations for WebAuthn Algorithms", Michael Jones,\n  2020-01-26, <draft-ietf-cose-webauthn-algorithms-04.txt>\n\n      The W3C Web Authentication (WebAuthn) specification and the FIDO\n      Alliance Client to Authenticator Protocol (CTAP) specification use\n      CBOR Object Signing and Encryption (COSE) algorithm identifiers.\n      This specification registers the following algorithms in the IANA\n      "COSE Algorithms" registry, which are used by WebAuthn and CTAP\n      implementations: RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512,\n      and SHA-1, and ECDSA using the secp256k1 curve and SHA-256.  It\n      registers the secp256k1 elliptic curve in the IANA "COSE Elliptic\n      Curves" registry.  Also, for use with JSON Object Signing and\n      Encryption (JOSE), it registers the algorithm ECDSA using the\n      secp256k1 curve and SHA-256 in the IANA "JSON Web Signature and\n      Encryption Algorithms" registry and the secp256k1 elliptic curve in\n      the IANA "JSON Web Key Elliptic Curve" registry.\n\nCURves, Deprecating and a Little more Encryption (curdle)\n---------------------------------------------------------\n\n  "Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448",\n  Aris Adamantiadis, Simon Josefsson, Mark Baushke, 2019-09-05,\n  <draft-ietf-curdle-ssh-curves-12.txt>\n\n      This document describes the specification for using Curve25519 and\n      Curve448 key exchange methods in the Secure Shell (SSH) protocol.\n\n  "Key Exchange (KEX) Method Updates and Recommendations for Secure Shell\n  (SSH)", Mark Baushke, 2018-01-02, <draft-ietf-curdle-ssh-kex-sha2-10.txt>\n\n      This document is intended to update the recommended set of key\n      exchange methods for use in the Secure Shell (SSH) protocol to meet\n      evolving needs for stronger security.  This document updates RFC\n      4250.\n\n  "GSS-API Key Exchange with SHA2", Simo Sorce, Hubert Kario, 2019-07-23,\n  <draft-ietf-curdle-gss-keyex-sha2-10.txt>\n\n      This document specifies additions and amendments to RFC4462.  It\n      defines a new key exchange method that uses SHA-2 for integrity and\n      deprecates weak DH groups.  The purpose of this specification is to\n      modernize the cryptographic primitives used by GSS Key Exchanges.\n\n  "Deprecating RC4 in Secure Shell (SSH)", Loganaden Velvindron, 2019-11-25,\n  <draft-ietf-curdle-rc4-die-die-die-18.txt>\n\n      This document deprecates RC4 in Secure Shell (SSH).  Therefore, this\n      document formally moves RFC4345 to historic status.\n\n  "Ed25519 and Ed448 public key algorithms for the Secure Shell (SSH)\n  protocol", Ben Harris, Loganaden Velvindron, 2019-09-09,\n  <draft-ietf-curdle-ssh-ed25519-ed448-11.txt>\n\n      This document describes the use of the Ed25519 and Ed448 digital\n      signature algorithm in the Secure Shell (SSH) protocol.\n\nDeterministic Networking (detnet)\n---------------------------------\n\n  "Deterministic Networking (DetNet) Security Considerations", Tal Mizrahi,\n  Ethan Grossman, Andrew Hacker, Subir Das, John Dowdell, Henrik Austad,\n  Norman Finn, 2020-01-10, <draft-ietf-detnet-security-07.txt>\n\n      A deterministic network is one that can carry data flows for real-\n      time applications with extremely low data loss rates and bounded\n      latency.  Deterministic networks have been successfully deployed in\n      real-time operational technology (OT) applications for some years.\n      However, such networks are typically isolated from external access,\n      and thus the security threat from external attackers is low.  IETF\n      Deterministic Networking (DetNet) specifies a set of technologies\n      that enable creation of deterministic networks on IP-based networks\n      of potentially wide area (on the scale of a corporate network)\n      potentially bringing the OT network into contact with Information\n      Technology (IT) traffic and security threats that lie outside of a\n      tightly controlled and bounded area (such as the internals of an\n      aircraft).  These DetNet technologies have not previously been\n      deployed together on a wide area IP-based network, and thus can\n      present security considerations that may be new to IP-based wide area\n      network designers.  This document, intended for use by DetNet network\n      designers, provides insight into these security considerations.\n\n  "DetNet Flow Information Model", Janos Farkas, Balazs Varga, Rodney\n  Cummings, Yuanlong Jiang, Don Fedyk, 2019-10-28,\n  <draft-ietf-detnet-flow-information-model-06.txt>\n\n      This document describes flow and service information model for\n      Deterministic Networking (DetNet).  These models are defined for IP\n      and MPLS DetNet data planes\n\n  "Deterministic Networking (DetNet) Configuration YANG Model", Xuesong Geng,\n  Mach Chen, Yeoncheol Ryoo, Zhenqiang Li, Reshad Rahman, 2019-11-04,\n  <draft-ietf-detnet-yang-04.txt>\n\n      This document contains the specification for Deterministic Networking\n      flow configuration YANG Model.  The model allows for provisioning of\n      end-to-end DetNet service along the path without dependency on any\n      signaling protocol.\n      \n      The YANG module defined in this document conforms to the Network\n      Management Datastore Architecture (NMDA).\n\n  "DetNet Data Plane Framework", Balazs Varga, Janos Farkas, Lou Berger, Don\n  Fedyk, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-10-28,\n  <draft-ietf-detnet-data-plane-framework-03.txt>\n\n      This document provides an overall framework for the DetNet data\n      plane.  It covers concepts and considerations that are generally\n      common to any Deterministic Networking data plane specification.\n\n  "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over MPLS", Balazs\n  Varga, Janos Farkas, Andrew Malis, Stewart Bryant, Don Fedyk, 2019-10-28,\n  <draft-ietf-detnet-tsn-vpn-over-mpls-01.txt>\n\n      This document specifies the Deterministic Networking data plane when\n      TSN networks are interconnected over a DetNet MPLS Network.\n\n  "DetNet Data Plane: MPLS over UDP/IP", Balazs Varga, Janos Farkas, Lou\n  Berger, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-11-21,\n  <draft-ietf-detnet-mpls-over-udp-ip-04.txt>\n\n      This document specifies the MPLS Deterministic Networking data plane\n      operation and encapsulation over an IP network.  The approach is\n      modeled on the operation of MPLS and over UDP/IP packet switched\n      networks.\n\n  "DetNet Data Plane: MPLS over IEEE 802.1 Time Sensitive Networking (TSN)",\n  Balazs Varga, Janos Farkas, Andrew Malis, Stewart Bryant, 2019-10-28,\n  <draft-ietf-detnet-mpls-over-tsn-01.txt>\n\n      This document specifies the Deterministic Networking MPLS data plane\n      when operating over a TSN sub-network.\n\n  "DetNet Data Plane: MPLS", Balazs Varga, Janos Farkas, Lou Berger, Don\n  Fedyk, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-11-21,\n  <draft-ietf-detnet-mpls-04.txt>\n\n      This document specifies the Deterministic Networking data plane when\n      operating over an MPLS Packet Switched Networks.\n\n  "DetNet Data Plane: IP over IEEE 802.1 Time Sensitive Networking (TSN)",\n  Balazs Varga, Janos Farkas, Andrew Malis, Stewart Bryant, 2019-10-28,\n  <draft-ietf-detnet-ip-over-tsn-01.txt>\n\n      This document specifies the Deterministic Networking IP data plane\n      when operating over a TSN sub-network.\n\n  "DetNet Data Plane: IP over MPLS", Balazs Varga, Janos Farkas, Lou Berger,\n  Don Fedyk, Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-11-21,\n  <draft-ietf-detnet-ip-over-mpls-04.txt>\n\n      This document specifies the Deterministic Networking data plane when\n      operating in an IP over MPLS packet switched network.\n\n  "DetNet Data Plane: IP", Balazs Varga, Janos Farkas, Lou Berger, Don Fedyk,\n  Andrew Malis, Stewart Bryant, Jouni Korhonen, 2019-11-21,\n  <draft-ietf-detnet-ip-04.txt>\n\n      This document specifies the Deterministic Networking data plane when\n      operating in an IP packet switched network.\n\n  "DetNet Bounded Latency", Norman Finn, Jean-Yves Le Boudec, Ehsan\n  Mohammadpour, Jiayi Zhang, Balazs Varga, Janos Farkas, 2019-11-04,\n  <draft-ietf-detnet-bounded-latency-01.txt>\n\n      This document presents a timing model for Deterministic Networking\n      (DetNet), so that existing and future standards can achieve the\n      DetNet quality of service features of bounded latency and zero\n      congestion loss.  It defines requirements for resource reservation\n      protocols or servers.  It calls out queuing mechanisms, defined in\n      other documents, that can provide the DetNet quality of service.\n\nDynamic Host Configuration (dhc)\n--------------------------------\n\n  "YANG Data Model for DHCPv6 Configuration", Yong Cui, Linhui Sun, Ian\n  Farrer, Sladjana Zechlin, Zihao He, Michal Nowikowski, 2019-11-04,\n  <draft-ietf-dhc-dhcpv6-yang-10.txt>\n\n      This document describes several YANG data modules for the\n      configuration and management of DHCPv6 servers, relays, and clients.\n\n  "Link-Layer Addresses Assignment Mechanism for DHCPv6", Bernie Volz, Tomek\n  Mrugalski, Carlos Bernardos, 2020-01-13, <draft-ietf-dhc-mac-assign-03.txt>\n\n      In certain environments, e.g. large scale virtualization deployments,\n      new devices are created in an automated manner.  Such devices\n      typically have their link-layer (MAC) addresses randomized.  With\n      sufficient scale, the likelihood of collision is not acceptable.\n      Therefore an allocation mechanism is required.  This draft proposes\n      an extension to DHCPv6 that allows a scalable approach to link-layer\n      address assignments.\n\n  "SLAP quadrant selection options for DHCPv6", Carlos Bernardos, Alain\n  Mourad, 2020-01-13, <draft-ietf-dhc-slap-quadrant-02.txt>\n\n      The IEEE originally structured the 48-bit MAC address space in such a\n      way that half of it was reserved for local use.  Recently, the IEEE\n      has been working on a new specification (IEEE 802c) which defines a\n      new "optional Structured Local Address Plan" (SLAP) that specifies\n      different assignment approaches in four specified regions of the\n      local MAC address space.\n      \n      The IEEE is working on mechanisms to allocate addresses in the one of\n      these quadrants (IEEE 802.1CQ).  There is work also in the IETF on\n      specifying a new mechanism that extends DHCPv6 operation to handle\n      the local MAC address assignments.  In this document, we complement\n      this ongoing IETF work by defining a mechanism to allow choosing the\n      SLAP quadrant to use in the allocation of the MAC address to the\n      requesting device/client.\n      \n      This document proposes extensions to DHCPv6 protocols to enable a\n      DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant\n      to the server, so that the server allocates the MAC address to the\n      given client out of the quadrant requested by relay or client.\n\n  "DHCPv6 Extension Survey and Considerations", Ren Gang, Lin He, Ying Liu,\n  2020-01-13, <draft-ietf-dhc-problem-statement-of-mredhcpv6-02.txt>\n\n      The manageability, security, privacy protection, and traceability of\n      networks can be supported by extending DHCPv6 protocol according to\n      requirements.  This document provides a survey of current extension\n      practices and typical DHCP server software on extensions, defines a\n      DHCPv6 general model, discusses some extension points, and presents\n      extension cases.\n\n  "DHCPv6 Prefix Delegating relay", Ian Farrer, Naveen Kottapalli, Martin\n  Hunek, Richard Patterson, 2019-12-17,\n  <draft-fkhp-dhc-dhcpv6-pd-relay-requirements-03.txt>\n\n      Operational experience with DHCPv6 prefix delegation has shown that\n      when the DHCPv6 relay function is not co-located with the DHCPv6\n      server function, issues such as timer synchronization between the\n      DHCP functional elements, rejection of client\'s messages by the\n      relay, and other problems have been observed.  These problems can\n      result in prefix delegation failing or traffic to/from clients\n      addressed from the delegated prefix being unrouteable.  Although\n      [RFC8415] mentions this deployment scenario, it does not provide\n      necessary detail on how the relay element should behave when used\n      with PD.\n      \n      This document describes functional requirements for a DHCPv6 PD relay\n      when used for relaying prefixes delegated by a separate DHCPv6\n      server.\n\n  "IPv6-Only-Preferred Option for DHCP", Lorenzo Colitti, Jen Linkova,\n  Michael Richardson, Tomek Mrugalski, 2019-12-09,\n  <draft-link-dhc-v6only-01.txt>\n\n      This document specifies a DHCP option to indicate that a host\n      supports an IPv6-only mode and willing to forgo obtaining an IPv4\n      address if the network provides IPv6 connectivity.\n\nDiameter Maintenance and Extensions (dime)\n------------------------------------------\n\n  "Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand,\n  2018-12-28, <draft-ietf-dime-group-signaling-12.txt>\n\n      In large network deployments, a single Diameter node can support over\n      a million concurrent Diameter sessions.  Recent use cases have\n      revealed the need for Diameter nodes to apply the same operation to a\n      large group of Diameter sessions concurrently.  The Diameter base\n      protocol commands operate on a single session so these use cases\n      could result in many thousands of command exchanges to enforce the\n      same operation on each session in the group.  In order to reduce\n      signaling, it would be desirable to enable bulk operations on all (or\n      part of) the sessions managed by a Diameter node using a single or a\n      few command exchanges.  This document specifies the Diameter protocol\n      extensions to achieve this signaling optimization.\n\nDispatch (dispatch)\n-------------------\n\n  "ECMAScript Media Types Updates", Myles Borins, Mathias Bynens, Matthew\n  Miller, Bradley Farias, 2019-10-31,\n  <draft-ietf-dispatch-javascript-mjs-05.txt>\n\n      This document proposes updates to the ECMAScript media types,\n      superseding the existing registrations for "application/javascript"\n      and "text/javascript" by adding an additional extension and removing\n      usage warnings.  This document updates RFC4329, "Scripting Media\n      Types".\n\nDomain-based Message Authentication, Reporting & Conformance (dmarc)\n--------------------------------------------------------------------\n\n  "Recommended Usage of the Authenticated Received Chain (ARC)", Steven\n  Jones, Kurt Andersen, 2019-10-22, <draft-ietf-dmarc-arc-usage-08.txt>\n\n      The Authentication Received Chain (ARC) provides an authenticated\n      "chain of custody" for a message, allowing each entity that handles\n      the message to see what entities handled it before, and to see what\n      the message\'s authentication assessment was at each step in the\n      handling.  But the specification does not indicate how the entities\n      handling these messages should interpret or utilize ARC results in\n      making decisions about message disposition.  This document will\n      provide guidance in these areas.\n\n  "DMARC (Domain-based Message Authentication, Reporting, and Conformance)\n  Extension For PSDs (Public Suffix Domains)", Scott Kitterman, 2019-10-14,\n  <draft-ietf-dmarc-psd-07.txt>\n\n      DMARC (Domain-based Message Authentication, Reporting, and\n      Conformance) is a scalable mechanism by which a mail-originating\n      organization can express domain-level policies and preferences for\n      message validation, disposition, and reporting, that a mail-receiving\n      organization can use to improve mail handling.  The design of DMARC\n      presumes that domain names represent either nodes in the tree below\n      which registrations occur, or nodes where registrations have\n      occurred; it does not permit a domain name to have both of these\n      properties simultaneously.  Since its deployment in 2015, use of\n      DMARC has shown a clear need for the ability to express policy for\n      these domains as well.\n      \n      Domains at which registrations can occur are referred to as Public\n      Suffix Domains (PSDs).  This document describes an extension to DMARC\n      to enable DMARC functionality for PSDs.\n      \n      This document also seeks to address implementations that consider a\n      domain on a public Suffix list to be ineligible for DMARC\n      enforcement.\n\nDistributed Mobility Management (dmm)\n-------------------------------------\n\n  "Distributed Mobility Anchoring", Anthony Chan, Xinpeng Wei, Jong-Hyouk\n  Lee, Seil Jeon, Carlos Bernardos, 2019-11-01,\n  <draft-ietf-dmm-distributed-mobility-anchoring-14.txt>\n\n      This document defines distributed mobility anchoring in terms of the\n      different configurations and functions to provide IP mobility\n      support.  A network may be configured with distributed mobility\n      anchoring functions for both network-based or host-based mobility\n      support according to the needs of mobility support.  In a distributed\n      mobility anchoring environment, multiple anchors are available for\n      mid-session switching of an IP prefix anchor.  To start a new flow or\n      to handle a flow not requiring IP session continuity as a mobile node\n      moves to a new network, the flow can be started or re-started using\n      an IP address configured from the new IP prefix anchored to the new\n      network.  If the flow needs to survive the change of network, there\n      are solutions that can be used to enable IP address mobility.  This\n      document describes different anchoring approaches, depending on the\n      IP mobility needs, and how this IP address mobility is handled by the\n      network.\n\n  "Segment Routing IPv6 for Mobile User Plane", Satoru Matsushima, Clarence\n  Filsfils, Miya Kohno, Pablo Camarillo, Daniel Voyer, Charles Perkins,\n  2019-11-04, <draft-ietf-dmm-srv6-mobile-uplane-07.txt>\n\n      This document shows the applicability of SRv6 (Segment Routing IPv6)\n      to the user-plane of mobile networks.  The network programming nature\n      of SRv6 accomplish mobile user-plane functions in a simple manner.\n      The statelessness of SRv6 and its ability to control both service\n      layer path and underlying transport can be beneficial to the mobile\n      user-plane, providing flexibility, end-to-end network slicing and SLA\n      control for various applications.  This document describes the SRv6\n      mobile user plane.\n\n  "Proxy Mobile IPv6 extensions for Distributed Mobility Management", Carlos\n  Bernardos, Antonio de la Oliva, Fabio Giust, Juan Zuniga, Alain Mourad,\n  2019-11-02, <draft-ietf-dmm-pmipv6-dlif-05.txt>\n\n      Distributed Mobility Management solutions allow for setting up\n      networks so that traffic is distributed in an optimal way and does\n      not rely on centrally deployed anchors to provide IP mobility\n      support.\n      \n      There are many different approaches to address Distributed Mobility\n      Management, as for example extending network-based mobility protocols\n      (like Proxy Mobile IPv6), or client-based mobility protocols (like\n      Mobile IPv6), among others.  This document follows the former\n      approach and proposes a solution based on Proxy Mobile IPv6 in which\n      mobility sessions are anchored at the last IP hop router (called\n      mobility anchor and access router).  The mobility anchor and access\n      router is an enhanced access router which is also able to operate as\n      a local mobility anchor or mobility access gateway, on a per prefix\n      basis.  The document focuses on the required extensions to\n      effectively support simultaneously anchoring several flows at\n      different distributed gateways.\n\n  "User Plane Protocol and Architectural Analysis on 3GPP 5G System",\n  Shunsuke Homma, Takuya Miyasaka, Satoru Matsushima, Daniel Voyer,\n  2019-11-03, <draft-ietf-dmm-5g-uplane-analysis-03.txt>\n\n      This document analyzes the mobile user plane protocol and the\n      architecture specified in 3GPP 5G documents.  The analysis work is to\n      clarify those specifications, extract protocol and architectural\n      requirements and derive evaluation aspects for user plane protocols\n      on IETF side.  This work is corresponding to the User Plane Protocol\n      Study work on 3GPP side.\n\nDomain Name System Operations (dnsop)\n-------------------------------------\n\n  "The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan,\n  2019-08-23, <draft-ietf-dnsop-alt-tld-12.txt>\n\n      This document reserves a string (ALT) to be used as a TLD label in\n      non-DNS contexts.  It also provides advice and guidance to developers\n      developing alternative namespaces.\n      \n      [Ed note: Text inside square brackets ([]) is additional background\n      information, answers to frequently asked questions, general musings,\n      etc.  They will be removed before publication.  This document is\n      being collaborated on in Github at: https://github.com/wkumari/draft-\n      wkumari-dnsop-alt-tld.  The most recent version of the document, open\n      issues, etc should all be available here.  The authors (gratefully)\n      accept pull requests. ]\n\n  "A Common Operational Problem in DNS Servers - Failure To Communicate.",\n  Mark Andrews, Ray Bellis, 2019-11-04,\n  <draft-ietf-dnsop-no-response-issue-14.txt>\n\n      The DNS is a query / response protocol.  Failing to respond to\n      queries, or responding incorrectly, causes both immediate operational\n      problems and long term problems with protocol development.\n      \n      This document identifies a number of common kinds of queries to which\n      some servers either fail to respond or else respond incorrectly.\n      This document also suggests procedures for zone operators to apply to\n      identify and remediate the problem.\n      \n      The document does not look at the DNS data itself, just the structure\n      of the responses.\n\n  "DNS Transport over TCP - Operational Requirements", John Kristoff, Duane\n  Wessels, 2019-11-02, <draft-ietf-dnsop-dns-tcp-requirements-05.txt>\n\n      This document encourages the practice of permitting DNS messages to\n      be carried over TCP on the Internet.  This includes both DNS over\n      unencrypted TCP, as well as over an encrypted TLS session.  The\n      document also considers the consequences with this form of DNS\n      communication and the potential operational issues that can arise\n      when this best common practice is not upheld.\n\n  "Extended DNS Errors", Warren Kumari, Evan Hunt, Roy Arends, Wes Hardaker,\n  David Lawrence, 2020-01-15, <draft-ietf-dnsop-extended-error-14.txt>\n\n      This document defines an extensible method to return additional\n      information about the cause of DNS errors.  Though created primarily\n      to extend SERVFAIL to provide additional information about the cause\n      of DNS and DNSSEC failures, the Extended DNS Errors option defined in\n      this document allows all response types to contain extended error\n      information.  Extended DNS Error information does not change the\n      processing of RCODEs.\n\n  "Serving Stale Data to Improve DNS Resiliency", David Lawrence, Warren\n  Kumari, Puneet Sood, 2019-12-09, <draft-ietf-dnsop-serve-stale-10.txt>\n\n      This draft defines a method (serve-stale) for recursive resolvers to\n      use stale DNS data to avoid outages when authoritative nameservers\n      cannot be reached to refresh expired data.  One of the motivations\n      for serve-stale is to make the DNS more resilient to DoS attacks, and\n      thereby make them less attractive as an attack vector.  This document\n      updates the definitions of TTL from RFC 1034 and RFC 1035 so that\n      data can be kept in the cache beyond the TTL expiry, updates RFC 2181\n      by interpreting values with the high order bit set as being positive,\n      rather than 0, and suggests a cap of 7 days.\n\n  "Secret Key Transaction Authentication for DNS (TSIG)", Francis Dupont,\n  Stephen Morris, Paul Vixie, Donald Eastlake, Olafur Gudmundsson, Brian\n  Wellington, 2019-11-01, <draft-ietf-dnsop-rfc2845bis-06.txt>\n\n      This document describes a protocol for transaction level\n      authentication using shared secrets and one way hashing.  It can be\n      used to authenticate dynamic updates as coming from an approved\n      client, or to authenticate responses as coming from an approved name\n      server.\n      \n      No recommendation is made here for distributing the shared secrets:\n      it is expected that a network administrator will statically configure\n      name servers and clients using some out of band mechanism.\n      \n      This document obsoletes RFC2845 and RFC4635.\n\n  "Running a Root Server Local to a Resolver", Warren Kumari, Paul Hoffman,\n  2020-01-12, <draft-ietf-dnsop-7706bis-07.txt>\n\n      Some DNS recursive resolvers have longer-than-desired round-trip\n      times to the closest DNS root server such as during a network attack.\n      Some DNS recursive resolver operators want to prevent snooping by\n      third parties of requests sent to DNS root servers.  Such resolvers\n      can greatly decrease the round-trip time and prevent observation of\n      requests by serving a copy of the full root zone on the same server,\n      such as on a loopback address or in the resolver software.  This\n      document shows how to start and maintain such a copy of the root zone\n      that does not cause problems for other users of the DNS, at the cost\n      of adding some operational fragility for the operator.\n      \n      [ This document is being collaborated on in Github at:\n      https://github.com/wkumari/draft-kh-dnsop-7706bis.  The most recent\n      version of the document, open issues, and so on should all be\n      available there.  The authors gratefully accept pull requests. ]\n\n  "Multi Signer DNSSEC models", Shumon Huque, Pallavi Aras, John Dickinson,\n  Jan Vcelak, David Blacka, 2019-07-22,\n  <draft-ietf-dnsop-multi-provider-dnssec-03.txt>\n\n      Many enterprises today employ the service of multiple DNS providers\n      to distribute their authoritative DNS service.  Deploying DNSSEC in\n      such an environment may present some challenges depending on the\n      configuration and feature set in use.  This document will present\n      several deployment models that may be suitable.\n\n  "Message Digest for DNS Zones", Duane Wessels, Piet Barber, Matt Weinberg,\n  Warren Kumari, Wes Hardaker, 2019-12-03,\n  <draft-ietf-dnsop-dns-zone-digest-03.txt>\n\n      This document describes a protocol and new DNS Resource Record that\n      can be used to provide a cryptographic message digest over DNS zone\n      data.  The ZONEMD Resource Record conveys the digest data in the zone\n      itself.  When a zone publisher includes an ZONEMD record, recipients\n      can verify the zone contents for accuracy and completeness.  This\n      provides assurance that received zone data matches published data,\n      regardless of how the zone data has been transmitted and received.\n      \n      ZONEMD is not designed to replace DNSSEC.  Whereas DNSSEC protects\n      individual RRSets (DNS data with fine granularity), ZONEMD protects\n      protects a zone\'s data as a whole, whether consumed by authoritative\n      name servers, recursive name servers, or any other applications.\n      \n      As specified at this time, ZONEMD is not designed for use in large,\n      dynamic zones due to the time and resources required for digest\n      calculation.  The ZONEMD record described in this document includes a\n      field intended to enable future work to support large, dynamic zones.\n\n  "Moving DNSSEC Lookaside Validation (DLV) to Historic Status", Willem\n  Mekking, Dan Mahoney, 2019-10-31, <draft-ietf-dnsop-obsolete-dlv-02.txt>\n\n      This document obsoletes DNSSEC lookaside validation (DLV) and\n      reclassifies RFCs 4431 and 5074 as Historic.  Furthermore, this\n      document updates RFC 6698 by excluding the DLV resource record from\n      certificates, and updates RFC 6840 by excluding the DLV registries\n      from the trust anchor selection.\n\n  "Terminology for DNS Transports and Location", Paul Hoffman, 2019-08-15,\n  <draft-ietf-dnsop-terminology-ter-00.txt>\n\n      This document adds terms and abbreviations to "DNS Terminology" (RFC\n      8499) that relate to DNS running over various transports, as well as\n      terms and abbreviations for DNS resolution at traditional and non-\n      traditional locations.\n\n  "DNS Resolver Information Self-publication", Puneet Sood, Roy Arends, Paul\n  Hoffman, 2019-08-19, <draft-ietf-dnsop-resolver-information-00.txt>\n\n      This document describes methods for DNS resolvers to self-publish\n      information about themselves, such as whether they perform DNSSEC\n      validation or are available over transports other than what is\n      defined in RFC 1035.  The information is returned as a JSON object.\n      The names in this object are defined in an IANA registry that allows\n      for light-weight registration.  Applications and operating systems\n      can use the methods defined here to get the information from\n      resolvers in order to make choices about how to send future queries\n      to those resolvers.\n\n  "Interoperable Domain Name System (DNS) Server Cookies", Ondrej Sury,\n  Willem Toorop, Donald Eastlake, Mark Andrews, 2019-11-18,\n  <draft-ietf-dnsop-server-cookies-02.txt>\n\n      DNS cookies, as specified in RFC 7873, are a lightweight DNS\n      transaction security mechanism that provides limited protection to\n      DNS servers and clients against a variety of denial-of-service and\n      amplification, forgery, or cache poisoning attacks by off-path\n      attackers.\n      \n      This document provides precise directions for creating Server Cookies\n      so that an anycast server set including diverse implementations will\n      interoperate with standard clients.\n      \n      This document updates [RFC7873]\n\n  "Service binding and parameter specification via the DNS (DNS SVCB and\n  HTTPSSVC)", Benjamin Schwartz, Mike Bishop, Erik Nygren, 2019-11-04,\n  <draft-ietf-dnsop-svcb-httpssvc-01.txt>\n\n      This document specifies the "SVCB" and "HTTPSSVC" DNS resource record\n      types to facilitate the lookup of information needed to make\n      connections for origin resources, such as for HTTPS URLs.  SVCB\n      records allow an origin to be served from multiple network locations,\n      each with associated parameters (such as transport protocol\n      configuration and keying material for encrypting TLS SNI).  They also\n      enable aliasing of apex domains, which is not possible with CNAME.\n      The HTTPSSVC DNS RR is a variation of SVCB for HTTPS and HTTP\n      origins.  By providing more information to the client before it\n      attempts to establish a connection, these records offer potential\n      benefits to both performance and privacy.\n      \n      TO BE REMOVED: This proposal is inspired by and based on recent DNS\n      usage proposals such as ALTSVC, ANAME, and ESNIKEYS (as well as long\n      standing desires to have SRV or a functional equivalent implemented\n      for HTTP).  These proposals each provide an important function but\n      are potentially incompatible with each other, such as when an origin\n      is load-balanced across multiple hosting providers (multi-CDN).\n      Furthermore, these each add potential cases for adding additional\n      record lookups in-addition to AAAA/A lookups.  This design attempts\n      to provide a unified framework that encompasses the key functionality\n      of these proposals, as well as providing some extensibility for\n      addressing similar future challenges.\n      \n      TO BE REMOVED: The specific name for this RR type is an open topic\n      for discussion.  "SVCB" and "HTTPSSVC" are meant as placeholders as\n      they are easy to replace.  Other names might include "B", "SRV2",\n      "SVCHTTPS", "HTTPS", and "ALTSVC".\n\n  "YANG Types for DNS Classes and Resource Record Types", Ladislav Lhotka,\n  Petr Spacek, 2019-12-17, <draft-ietf-dnsop-iana-class-type-yang-00.txt>\n\n      This document introduces the YANG module "iana-dns-class-rr-type"\n      that contains derived types reflecting two IANA registries: DNS\n      CLASSes and Resource Record (RR) TYPEs.  These YANG types are\n      intended as a minimum basis for future data modeling work.\n\nExtensions for Scalable DNS Service Discovery (dnssd)\n-----------------------------------------------------\n\n  "Discovery Proxy for Multicast DNS-Based Service Discovery", Stuart\n  Cheshire, 2019-03-24, <draft-ietf-dnssd-hybrid-10.txt>\n\n      This document specifies a network proxy that uses Multicast DNS to\n      automatically populate the wide-area unicast Domain Name System\n      namespace with records describing devices and services found on the\n      local link.\n\n  "DNS Push Notifications", Tom Pusateri, Stuart Cheshire, 2019-10-13,\n  <draft-ietf-dnssd-push-25.txt>\n\n      The Domain Name System (DNS) was designed to return matching records\n      efficiently for queries for data that are relatively static.  When\n      those records change frequently, DNS is still efficient at returning\n      the updated results when polled, as long as the polling rate is not\n      too high.  But there exists no mechanism for a client to be\n      asynchronously notified when these changes occur.  This document\n      defines a mechanism for a client to be notified of such changes to\n      DNS records, called DNS Push Notifications.\n\n  "DNS-SD Privacy and Security Requirements", Christian Huitema, Daniel\n  Kaiser, 2019-12-20, <draft-ietf-dnssd-prireq-03.txt>\n\n      DNS-SD (DNS Service Discovery) normally discloses information about\n      devices offering and requesting services.  This information includes\n      host names, network parameters, and possibly a further description of\n      the corresponding service instance.  Especially when mobile devices\n      engage in DNS Service Discovery over Multicast DNS at a public\n      hotspot, serious privacy problems arise.  We analyze the requirements\n      of a privacy respecting discovery service.\n\nDDoS Open Threat Signaling (dots)\n---------------------------------\n\n  "Use cases for DDoS Open Threat Signaling", Roland Dobbins, Daniel Migault,\n  Robert Moskowitz, Nik Teague, Liang Xia, Kaname Nishizuka, 2019-09-05,\n  <draft-ietf-dots-use-cases-20.txt>\n\n      The DDoS Open Threat Signaling (DOTS) effort is intended to provide\n      protocols to facilitate interoperability across disparate DDoS\n      mitigation solutions.  This document presents sample use cases which\n      describe the interactions expected between the DOTS components as\n      well as DOTS messaging exchanges.  These use cases are meant to\n      identify the interacting DOTS components, how they collaborate, and\n      what are the typical information to be exchanged.\n\n  "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Architecture",\n  Andrew Mortensen, Tirumaleswar Reddy.K, Flemming Andreasen, Nik Teague,\n  Rich Compton, 2020-01-10, <draft-ietf-dots-architecture-15.txt>\n\n      This document describes an architecture for establishing and\n      maintaining Distributed Denial of Service (DDoS) Open Threat\n      Signaling (DOTS) within and between domains.  The document does not\n      specify protocols or protocol extensions, instead focusing on\n      defining architectural relationships, components and concepts used in\n      a DOTS deployment.\n\n  "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel\n  Specification", Tirumaleswar Reddy.K, Mohamed Boucadair, Prashanth Patil,\n  Andrew Mortensen, Nik Teague, 2020-01-06,\n  <draft-ietf-dots-signal-channel-41.txt>\n\n      This document specifies the DOTS signal channel, a protocol for\n      signaling the need for protection against Distributed Denial-of-\n      Service (DDoS) attacks to a server capable of enabling network\n      traffic mitigation on behalf of the requesting client.\n      \n      A companion document defines the DOTS data channel, a separate\n      reliable communication layer for DOTS management and configuration\n      purposes.\n      \n      Editorial Note (To be removed by RFC Editor)\n      \n      Please update these statements within the document with the RFC\n      number to be assigned to this document:\n      \n      o  "This version of this YANG module is part of RFC XXXX;"\n      \n      o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling\n      (DOTS) Signal Channel Specification";\n      \n      o  "| [RFCXXXX] |"\n      \n      o  reference: RFC XXXX\n      \n      Please update this statement with the RFC number to be assigned to\n      the following documents:\n      \n      o  "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling\n      (DOTS) Data Channel Specification (used to be I-D.ietf-dots-data-\n      channel)\n      \n      Please update TBD/TBD1/TBD2 statements with the assignments made by\n      IANA to DOTS Signal Channel Protocol.\n      \n      Also, please update the "revision" date of the YANG modules.\n\n  "Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel\n  Specification", Mohamed Boucadair, Tirumaleswar Reddy.K, 2019-07-21,\n  <draft-ietf-dots-data-channel-31.txt>\n\n      The document specifies a Distributed Denial-of-Service Open Threat\n      Signaling (DOTS) data channel used for bulk exchange of data that\n      cannot easily or appropriately communicated through the DOTS signal\n      channel under attack conditions.\n      \n      This is a companion document to the DOTS signal channel\n      specification.\n      \n      Editorial Note (To be removed by RFC Editor)\n      \n      Please update these statements within the document with the RFC\n      number to be assigned to this document:\n      \n      o  "This version of this YANG module is part of RFC XXXX;"\n      \n      o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling\n      (DOTS) Data Channel Specification";\n      \n      o  reference: RFC XXXX\n      \n      Please update the "revision" date of the YANG module.\n\n  "Multi-homing Deployment Considerations for Distributed-Denial-of-Service\n  Open Threat Signaling (DOTS)", Mohamed Boucadair, Tirumaleswar Reddy.K, Wei\n  Pan, 2020-01-22, <draft-ietf-dots-multihoming-03.txt>\n\n      This document discusses multi-homing considerations for Distributed-\n      Denial-of-Service Open Threat Signaling (DOTS).  The goal is to\n      provide some guidance for DOTS clients/gateways when multihomed.\n\n  "Distributed-Denial-of-Service Open Threat Signaling (DOTS) Agent\n  Discovery", Mohamed Boucadair, Tirumaleswar Reddy.K, 2020-01-09,\n  <draft-ietf-dots-server-discovery-09.txt>\n\n      It may not be possible for a network to determine the cause for an\n      attack, but instead just realize that some resources seem to be under\n      attack.  To fill that gap, Distributed-Denial-of-Service Open Threat\n      Signaling (DOTS) allows a network to inform a DOTS server that it is\n      under a potential attack so that appropriate mitigation actions are\n      undertaken.\n      \n      This document specifies mechanisms to configure DOTS clients with\n      their DOTS servers.  The discovery procedure also covers the DOTS\n      Signal Channel Call Home.\n\n  "Controlling Filtering Rules Using Distributed Denial-of-Service Open\n  Threat Signaling (DOTS) Signal Channel", Kaname Nishizuka, Mohamed\n  Boucadair, Tirumaleswar Reddy.K, Takahiko Nagata, 2019-09-17,\n  <draft-ietf-dots-signal-filter-control-02.txt>\n\n      This document specifies an extension to the DOTS signal channel\n      protocol so that DOTS clients can control their filtering rules when\n      an attack mitigation is active.\n      \n      Particularly, this extension allows a DOTS client to activate or de-\n      activate existing filtering rules during a DDoS attack.  The\n      characterization of these filtering rules is supposed to be conveyed\n      by a DOTS client during an idle time by means of the DOTS data\n      channel protocol.\n      \n      Editorial Note (To be removed by RFC Editor)\n      \n      Please update these statements within the document with the RFC\n      number to be assigned to this document:\n      \n      o  "This version of this YANG module is part of RFC XXXX;"\n      \n      o  "RFC XXXX: Controlling Filtering Rules Using Distributed Denial-\n      of-Service Open Threat Signaling (DOTS) Signal Channel";\n      \n      o  reference: RFC XXXX\n      \n      o  [RFCXXXX]\n      \n      Please update these statements with the RFC number to be assigned to\n      the following documents:\n      \n      o  "RFC SSSS: Distributed Denial-of-Service Open Threat Signaling\n      (DOTS) Signal Channel Specification" (used to be\n      [I-D.ietf-dots-signal-channel])\n      \n      o  "RFC DDDD: Distributed Denial-of-Service Open Threat Signaling\n      (DOTS) Data Channel Specification" (used to be\n      [I-D.ietf-dots-data-channel])\n      \n      Please update the "revision" date of the YANG module.\n\n  "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel\n  Call Home", Tirumaleswar Reddy.K, Mohamed Boucadair, Jon Shallow,\n  2019-11-18, <draft-ietf-dots-signal-call-home-07.txt>\n\n      This document specifies the DOTS signal channel Call Home, which\n      enables a DOTS server to initiate a secure connection to a DOTS\n      client, and to receive the attack traffic information from the DOTS\n      client.  The DOTS server in turn uses the attack traffic information\n      to identify the compromised devices launching the outgoing DDoS\n      attack and takes appropriate mitigation action(s).\n      \n      The DOTS signal channel Call Home is not specific to the home\n      networks; the solution targets any deployment which requires to block\n      DDoS attack traffic closer to the source(s) of a DDoS attack.\n      \n      Editorial Note (To be removed by RFC Editor)\n      \n      Please update these statements within the document with the RFC\n      number to be assigned to this document:\n      \n      o  "This version of this YANG module is part of RFC XXXX;"\n      \n      o  "RFC XXXX: Distributed Denial-of-Service Open Threat Signaling\n      (DOTS) Signal Channel Call Home";\n      \n      o  "| [RFCXXXX] |"\n      \n      o  reference: RFC XXXX\n      \n      Please update this statement with the RFC number to be assigned to\n      the following documents:\n      \n      o  "RFC YYYY: Distributed Denial-of-Service Open Threat Signaling\n      (DOTS) Signal Channel Specification (used to be I-D.ietf-dots-\n      signal-channel)\n      \n      Please update TBD statements with the assignment made by IANA to DOTS\n      Signal Channel Call Home.\n      \n      Also, please update the "revision" date of the YANG module.\n\n  "Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry",\n  Tirumaleswar Reddy.K, Mohamed Boucadair, Ehud Doron, chenmeiling,\n  2019-12-17, <draft-ietf-dots-telemetry-00.txt>\n\n      This document aims to enrich DOTS signal channel protocol with\n      various telemetry attributes allowing optimal DDoS attack mitigation.\n      This document specifies the normal traffic baseline and attack\n      traffic telemetry attributes a DOTS client can convey to its DOTS\n      server in the mitigation request, the mitigation status telemetry\n      attributes a DOTS server can communicate to a DOTS client, and the\n      mitigation efficacy telemetry attributes a DOTS client can\n      communicate to a DOTS server.  The telemetry attributes can assist\n      the mitigator to choose the DDoS mitigation techniques and perform\n      optimal DDoS attack mitigation.\n\nDNS PRIVate Exchange (dprive)\n-----------------------------\n\n  "Recommendations for DNS Privacy Service Operators", Sara Dickinson, Benno\n  Overeinder, Roland van Rijswijk-Deij, Allison Mankin, 2020-01-24,\n  <draft-ietf-dprive-bcp-op-08.txt>\n\n      This document presents operational, policy, and security\n      considerations for DNS recursive resolver operators who choose to\n      offer DNS Privacy services.  With these recommendations, the operator\n      can make deliberate decisions regarding which services to provide,\n      and how the decisions and alternatives impact the privacy of users.\n      \n      This document also presents a framework to assist writers of a DNS\n      Recursive Operator Privacy Statement (analogous to DNS Security\n      Extensions (DNSSEC) Policies and DNSSEC Practice Statements described\n      in RFC6841).\n\n  "DNS Privacy Considerations", Stephane Bortzmeyer, Sara Dickinson,\n  2020-01-16, <draft-ietf-dprive-rfc7626-bis-04.txt>\n\n      This document describes the privacy issues associated with the use of\n      the DNS by Internet users.  It is intended to be an analysis of the\n      present situation and does not prescribe solutions.  This document\n      obsoletes RFC 7626.\n\n  "DNS Zone Transfer-over-TLS", Han Zhang, Pallavi Aras, Willem Toorop, Sara\n  Dickinson, Allison Mankin, 2019-11-18,\n  <draft-ietf-dprive-xfr-over-tls-00.txt>\n\n      DNS zone transfers are transmitted in clear text, which gives\n      attackers the opportunity to collect the content of a zone by\n      eavesdropping on network connections.  The DNS Transaction Signature\n      (TSIG) mechanism is specified to restrict direct zone transfer to\n      authorized clients only, but it does not add confidentiality.  This\n      document specifies use of DNS-over-TLS to prevent zone contents\n      collection via passive monitoring of zone transfers.\n\n  "DNS Privacy Requirements for Exchanges between Recursive Resolvers and\n  Authoritative Servers", Jason Livingood, Alexander Mayrhofer, Benno\n  Overeinder, 2019-12-15, <draft-ietf-dprive-phase2-requirements-00.txt>\n\n      This document provides requirements for adding confidentiality to DNS\n      exchanges between recursive resolvers and authoritative servers.\n\nDelay/Disruption Tolerant Networking (dtn)\n------------------------------------------\n\n  "Bundle Protocol Version 7", Scott Burleigh, Kevin Fall, Edward Birrane,\n  2020-01-23, <draft-ietf-dtn-bpbis-20.txt>\n\n      This Internet Draft presents a specification for Bundle Protocol,\n      adapted from the experimental Bundle Protocol specification\n      developed by the Delay-Tolerant Networking Research group of the\n      Internet Research Task Force and documented in RFC 5050.\n\n  "Bundle Protocol Security Specification", Edward Birrane, Kenneth McKeever,\n  2020-01-27, <draft-ietf-dtn-bpsec-18.txt,.pdf>\n\n      This document defines a security protocol providing end to end data\n      integrity and confidentiality services for the Bundle Protocol.\n\n  "Delay-Tolerant Networking TCP Convergence Layer Protocol Version 4", Brian\n  Sipos, Michael Demmer, Joerg Ott, Simon Perreault, 2020-01-19,\n  <draft-ietf-dtn-tcpclv4-17.txt>\n\n      This document describes a TCP-based convergence layer (TCPCL) for\n      Delay-Tolerant Networking (DTN).  This version of the TCPCL protocol\n      is based on implementation issues in the earlier TCPCL Version 3 of\n      RFC7242 and updates to the Bundle Protocol (BP) contents, encodings,\n      and convergence layer requirements in BP Version 7.  Specifically,\n      the TCPCLv4 uses CBOR-encoded BPv7 bundles as its service data unit\n      being transported and provides a reliable transport of such bundles.\n      \n      This document is an update of the protocol described in RFC7242,\n      reflecting lessons learned.  For this reason it obsoletes RFC7242, an\n      IRTF-stream document.\n      \n      Note to the RFC editor: The Internet Research Task Force is requested\n      to mark RFC7242 as obsolete.\n\n  "Bundle-in-Bundle Encapsulation", Scott Burleigh, 2019-08-04,\n  <draft-ietf-dtn-bibect-02.txt>\n\n      This document describes Bundle-in-Bundle Encapsulation (BIBE), a\n      Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence\n      layer" protocol that tunnels BP "bundles" through encapsulating\n      bundles.  The services provided by the BIBE convergence-layer\n      protocol adapter encapsulate an outbound BP "bundle" in a BIBE\n      convergence-layer protocol data unit for transmission as the payload\n      of a bundle.  Security measures applied to the encapsulating bundle\n      may augment those applied to the encapsulated bundle.  The protocol\n      includes a mechanism for recovery from loss of an encapsulating\n      bundle, called "custody transfer".  This mechanism is adapted from\n      the custody transfer procedures described in the experimental Bundle\n      Protocol specification developed by the Delay-Tolerant Networking\n      Research group of the Internet Research Task Force and documented in\n      RFC 5050.\n\n  "Asynchronous Management Architecture", Edward Birrane, 2019-08-08,\n  <draft-ietf-dtn-ama-00.txt>\n\n      This document describes an asynchronous management architecture (AMA)\n      suitable for providing application-level network management services\n      in a challenged networking environment.  Challenged networks are\n      those that require fault protection, configuration, and performance\n      reporting while unable to provide humans-in-the-loop with synchronous\n      feedback or otherwise preserve transport-layer sessions.  In such a\n      context, networks must exhibit behavior that is both determinable and\n      autonomous while maintaining compatibility with existing network\n      management protocols and operational concepts.\n\nEmergency Context Resolution with Internet Technologies (ecrit)\n---------------------------------------------------------------\n\n  "Data-Only Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes\n  Tschofenig, Randall Gellens, 2019-04-17,\n  <draft-ietf-ecrit-data-only-ea-18.txt>\n\n      RFC 6443 \'Framework for Emergency Calling Using Internet Multimedia\'\n      describes how devices use the Internet to place emergency calls and\n      how Public Safety Answering Points (PSAPs) handle Internet multimedia\n      emergency calls natively.  The exchange of multimedia traffic for\n      emergency services involves a Session Initiation Protocol (SIP)\n      session establishment starting with a SIP INVITE that negotiates\n      various parameters for that session.\n      \n      In some cases, however, the transmission of application data is all\n      that is needed.  Examples of such environments include alerts issued\n      by a temperature sensor, burglar alarm, or chemical spill sensor.\n      Often these alerts are conveyed as one-shot data transmissions.\n      These type of interactions are called \'data-only emergency calls\'.\n      This document describes a container for the data based on the Common\n      Alerting Protocol (CAP) and its transmission using the SIP MESSAGE\n      transaction.\n\nEAP Method Update (emu)\n-----------------------\n\n  "Using EAP-TLS with TLS 1.3", John Mattsson, Mohit Sethi, 2019-12-27,\n  <draft-ietf-emu-eap-tls13-08.txt>\n\n      This document specifies the use of EAP-TLS with TLS 1.3 while\n      remaining backwards compatible with existing implementations of EAP-\n      TLS.  TLS 1.3 provides significantly improved security, privacy, and\n      reduced latency when compared to earlier versions of TLS.  EAP-TLS\n      with TLS 1.3 further improves security and privacy by mandating use\n      of privacy and revocation checking.  This document updates RFC 5216.\n\n  "Improved Extensible Authentication Protocol Method for 3GPP Mobile Network\n  Authentication and Key Agreement (EAP-AKA\')", Jari Arkko, Vesa Lehtovirta,\n  Vesa Torvinen, Pasi Eronen, 2019-11-17, <draft-ietf-emu-rfc5448bis-06.txt>\n\n      The 3GPP Mobile Network Authentication and Key Agreement (AKA) is the\n      primary authentication mechanism for devices wishing to access mobile\n      networks.  RFC 4187 (EAP-AKA) made the use of this mechanism possible\n      within the Extensible Authentication Protocol (EAP) framework.  RFC\n      5448 (EAP-AKA\') was an improved version of EAP-AKA.\n      \n      This memo replaces the specification of EAP-AKA\'.  EAP-AKA\' was\n      defined in RFC 5448 and updated EAP-AKA RFC 4187.  As such this\n      document obsoletes RFC 5448 and updates RFC 4187.\n      \n      EAP-AKA\' differs from EAP-AKA by providing a key derivation function\n      that binds the keys derived within the method to the name of the\n      access network.  The key derivation function has been defined in the\n      3rd Generation Partnership Project (3GPP).  EAP-AKA\' allows its use\n      in EAP in an interoperable manner.  EAP-AKA\' is also an algorithm\n      update, as it employs SHA-256 / HMAC-SHA-256 instead of SHA-1 / HMAC-\n      SHA-1 as in EAP-AKA.\n      \n      This version of EAP-AKA\' specification specifies the protocol\n      behaviour for 5G deployments as well.\n\n  "Perfect-Forward Secrecy for the Extensible Authentication Protocol Method\n  for Authentication and Key Agreement (EAP-AKA\' PFS)", Jari Arkko, Karl\n  Norrman, Vesa Torvinen, 2019-11-17, <draft-ietf-emu-aka-pfs-02.txt>\n\n      Many different attacks have been reported as part of revelations\n      associated with pervasive surveillance.  Some of the reported attacks\n      involved compromising smart cards, such as attacking SIM card\n      manufacturers and operators in an effort to compromise shared secrets\n      stored on these cards.  Since the publication of those reports,\n      manufacturing and provisioning processes have gained much scrutiny\n      and have improved.  However, the danger of resourceful attackers for\n      these systems is still a concern.\n      \n      This specification is an optional extension to the EAP-AKA\'\n      authentication method which was defined in [I-D.ietf-emu-rfc5448bis].\n      The extension, when negotiated, provides Perfect Forward Secrecy for\n      the session key generated as a part of the authentication run in EAP-\n      AKA\'.  This prevents an attacker who has gained access to the long-\n      term pre-shared secret in a SIM card from being able to decrypt any\n      past communications.  In addition, if the attacker stays merely a\n      passive eavesdropper, the extension prevents attacks against future\n      sessions.  This forces attackers to use active attacks instead.\n\n  "Handling Large Certificates and Long Certificate Chains in TLS-based EAP\n  Methods", Mohit Sethi, John Mattsson, Sean Turner, 2019-08-13,\n  <draft-ietf-emu-eaptlscert-00.txt>\n\n      EAP-TLS and other TLS-based EAP methods are widely deployed and used\n      for network access authentication.  Large certificates and long\n      certificate chains combined with authenticators that drop an EAP\n      session after only 40 - 50 round-trips is a major deployment problem.\n      This memo looks at the this problem in detail and describes the\n      potential solutions available.\n\n  "EAP Session-Id Derivation for EAP-SIM, EAP-AKA, and PEAP", Alan DeKok,\n  2020-01-07, <draft-ietf-emu-eap-session-id-02.txt>\n\n      EAP Session-Id derivation has not been defined for EAP-SIM or EAP-AKA\n      when using the fast re-authentication exchange instead of full\n      authentication.  This document updates RFC 5247 to define those\n      derivations for EAP-SIM and EAP-AKA.  RFC 5247 also does not define\n      Session-Id derivation for PEAP.  A definition is given here which\n      follows the definition for other TLS-based EAP methods.\n\nEmail mailstore and eXtensions To Revise or Amend (extra)\n---------------------------------------------------------\n\n  "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev2", Alexey Melnikov, Barry\n  Leiba, 2019-12-03, <draft-ietf-extra-imap4rev2-11.txt>\n\n      The Internet Message Access Protocol, Version 4rev2 (IMAP4rev2)\n      allows a client to access and manipulate electronic mail messages on\n      a server.  IMAP4rev2 permits manipulation of mailboxes (remote\n      message folders) in a way that is functionally equivalent to local\n      folders.  IMAP4rev2 also provides the capability for an offline\n      client to resynchronize with the server.\n      \n      IMAP4rev2 includes operations for creating, deleting, and renaming\n      mailboxes, checking for new messages, permanently removing messages,\n      setting and clearing flags, RFC 5322, RFC 2045 and RFC 2231 parsing,\n      searching, and selective fetching of message attributes, texts, and\n      portions thereof.  Messages in IMAP4rev2 are accessed by the use of\n      numbers.  These numbers are either message sequence numbers or unique\n      identifiers.\n      \n      IMAP4rev2 does not specify a means of posting mail; this function is\n      handled by a mail submission protocol such as RFC 6409.\n\n  "IMAP4 Extension: Message Preview Generation", Michael Slusarz, 2019-12-10,\n  <draft-ietf-extra-imap-fetch-preview-07.txt>\n\n      This document specifies an Internet Message Access Protocol (IMAP)\n      protocol extension allowing a client to request a server-generated\n      abbreviated representation of message data useful as a contextual\n      preview of the entire message.\n\nGitHub Integration and Tooling (git)\n------------------------------------\n\n  "Working Group GitHub Administration", Alissa Cooper, Paul Hoffman,\n  2020-01-21, <draft-ietf-git-github-wg-configuration-05.txt>\n\n      The use of GitHub in IETF working group processes is increasing.\n      This document describes possible uses and conventions for working\n      groups which are considering starting to use GitHub.  It does not\n      mandate any processes, and does not require changes to the processes\n      used by current and future working groups not using GitHub.\n      \n      Discussion of this document takes place on the ietf-and-github\n      mailing list (ietf-and-github@ietf.org), which is archived at\n      <https://mailarchive.ietf.org/arch/search?email_list=ietf-and-\n      github>.\n\n  "Working Group GitHub Usage Guidance", Martin Thomson, Barbara Stark,\n  2019-12-31, <draft-ietf-git-using-github-03.txt>\n\n      This document describes best practices for Working Groups that use\n      GitHub for their work.\n\nGlobal Routing Operations (grow)\n--------------------------------\n\n  "Support for Local RIB in BGP Monitoring Protocol (BMP)", Tim Evens, Serpil\n  Bayraktar, Manish Bhardwaj, Paolo Lucente, 2019-11-04,\n  <draft-ietf-grow-bmp-local-rib-06.txt>\n\n      The BGP Monitoring Protocol (BMP) defines access to the Adj-RIB-In\n      and locally originated routes (e.g. routes distributed into BGP from\n      protocols such as static) but not access to the BGP instance Loc-RIB.\n      This document updates the BGP Monitoring Protocol (BMP) RFC 7854 by\n      adding access to the BGP instance Local-RIB, as defined in RFC 4271\n      the routes that have been selected by the local BGP speaker\'s\n      Decision Process.  These are the routes over all peers, locally\n      originated, and after best-path selection.\n\n  "Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi\n  Sriram, Alexander Azimov, 2020-01-25,\n  <draft-ietf-grow-route-leak-detection-mitigation-02.txt>\n\n      Problem definition for route leaks and enumeration of types of route\n      leaks are provided in [RFC7908].  This document describes a new well-\n      known Large Community that provides a way for route leak prevention,\n      detection, and mitigation.  The configuration process for this\n      Community can be automated with the methodology for setting BGP roles\n      that is described in ietf-idr-bgp-open-policy draft.\n\n  "TLV support for BMP Route Monitoring and Peer Down Messages", Paolo\n  Lucente, Yunan Gu, Henk Smit, 2019-10-15, <draft-ietf-grow-bmp-tlv-01.txt>\n\n      Most of the message types defined by the BGP Monitoring Protocol\n      (BMP) do provision for optional trailing data; however Route\n      Monitoring message (to provide a snapshot of the monitored Routing\n      Information Base) and Peer Down message (to indicate that a peering\n      session was terminated) do not.  Supporting optional data in TLV\n      format across all BMP message types allows for an homogeneous and\n      extensible surface that would be useful for the most different use-\n      cases that need to convey additional data to a BMP station.  While\n      this document does not want to cover any specific utilization\n      scenario, it defines a simple way to support optional TLV data in all\n      message types.\n\nHost Identity Protocol (hip)\n----------------------------\n\n  "Host Identity Protocol Architecture", Robert Moskowitz, Miika Komu,\n  2019-02-14, <draft-ietf-hip-rfc4423-bis-20.txt>\n\n      This memo describes the Host Identity (HI) namespace, that provides a\n      cryptographic namespace to applications, and the associated protocol\n      layer, the Host Identity Protocol, located between the\n      internetworking and transport layers, that supports end-host\n      mobility, multihoming and NAT traversal.  Herein are presented the\n      basics of the current namespaces, their strengths and weaknesses, and\n      how a HI namespace will add completeness to them.  The roles of the\n      HI namespace in the protocols are defined.\n      \n      This document obsoletes RFC 4423 and addresses the concerns raised by\n      the IESG, particularly that of crypto agility.  The section on\n      security considerations describe also measures against flooding\n      attacks, usage of identities in access control lists, weaker types of\n      identifiers and trust on first use.  This document incorporates\n      lessons learned from the implementations of RFC 5201 and goes further\n      to explain how HIP works as a secure signaling channel.\n\n  "Native NAT Traversal Mode for the Host Identity Protocol", Ari Keranen,\n  Jan Melen, Miika Komu, 2018-03-05,\n  <draft-ietf-hip-native-nat-traversal-28.txt>\n\n      This document specifies a new Network Address Translator (NAT)\n      traversal mode for the Host Identity Protocol (HIP).  The new mode is\n      based on the Interactive Connectivity Establishment (ICE) methodology\n      and UDP encapsulation of data and signaling traffic.  The main\n      difference from the previously specified modes is the use of HIP\n      messages for all NAT traversal procedures.\n\n  "HIP Diet EXchange (DEX)", Robert Moskowitz, Rene Hummen, Miika Komu,\n  2019-10-31, <draft-ietf-hip-dex-11.txt>\n\n      This document specifies the Host Identity Protocol Diet EXchange (HIP\n      DEX), a variant of the Host Identity Protocol Version 2 (HIPv2).  The\n      HIP DEX protocol design aims at reducing the overhead of the employed\n      cryptographic primitives by omitting public-key signatures and hash\n      functions.\n      \n      The HIP DEX protocol is primarily designed for computation or memory-\n      constrained sensor/actuator devices.  Like HIPv2, it is expected to\n      be used together with a suitable security protocol such as the\n      Encapsulated Security Payload (ESP) for the protection of upper layer\n      protocol data.  In addition, HIP DEX can also be used as a keying\n      mechanism for security primitives at the MAC layer, e.g., for IEEE\n      802.15.4 networks.\n\nHome Networking (homenet)\n-------------------------\n\n  "Outsourcing Home Network Authoritative Naming Service", Daniel Migault,\n  Ralf Weber, Michael Richardson, Ray Hunter, Chris Griffiths, Wouter\n  Cloetens, 2019-11-16,\n  <draft-ietf-homenet-front-end-naming-delegation-09.txt>\n\n      The Homenet Naming authority is responsible for making devices within\n      the home network accessible by name within the home network as well\n      as from outside the home network (e.g. the Internet).  The names of\n      the devices accessible from the Internet are stored in the Public\n      Homenet Zone, served by a DNS authoritative server.  It is unlikely\n      that home networks will contain sufficiently robust platforms\n      designed to host a service such as the DNS on the Internet and as\n      such would expose the home network to DDoS attacks.\n      \n      This document describes a mechanism that enables the Home Network\n      Authority (HNA) to outsource the naming service to the Outsourcing\n      Infrastructure via a Distribution Master (DM).\n\n  "Homenet profile of the Babel routing protocol", Juliusz Chroboczek,\n  2018-07-18, <draft-ietf-homenet-babel-profile-07.txt>\n\n      This document defines the exact subset of the Babel routing protocol\n      and its extensions that is required by an implementation of the\n      Homenet protocol suite, as well as the interactions between the Home\n      Networking Control Protocol (HNCP) and Babel.\n\nHuman Rights Protocol Considerations (hrpc)\n-------------------------------------------\n\n  "Notes on networking standards and politics", Niels ten Oever, 2019-09-28,\n  <draft-irtf-hrpc-political-07.txt>\n\n      The IETF cannot ordain what standards or protocols are to be used on\n      networks, but the standards development process in the IETF does have\n      an impact on society through its normative standards setting process.\n      This document aims to bring about a better understanding on the\n      political nature of standards and protocols.  Among other things, the\n      IETF\'s work affects what is perceived as technologically possible and\n      useful where networking technologies are being deployed, and its\n      standards reflect what is considered by the technical community to be\n      feasible and good practice.  Whereas there might not be agreement\n      among the Internet protocol community on the specific political\n      nature of the technological development process and its outputs, it\n      is generally agreed that standards and protocols are both products of\n      a political process, and they can also be used for political means.\n\n  "Freedom of Association on the Internet", Stephane Couture, Joseph Hall,\n  Niels ten Oever, Gisela de Acha, 2019-08-22,\n  <draft-irtf-hrpc-association-03.txt>\n\n      This document establishes the link between the Internet architecture\n      and the ability of people to exercise their right to freedom of\n      assembly and association online.  The Internet increasingly mediates\n      our lives, our relationships and our ability to exercise our human\n      rights.  As a forum, it provides a global public space despite being\n      built on predominantly private infrastructure.  Since Internet\n      protocols play a central role in the management, development and use\n      of the Internet, the relation between protocols and the\n      aforementioned rights should be analyzed and any adverse impacts\n      should be mitigated.\n\nHTTP (httpbis)\n--------------\n\n  "HTTP Client Hints", Ilya Grigorik, Yoav Weiss, 2019-11-18,\n  <draft-ietf-httpbis-client-hints-08.txt>\n\n      HTTP defines proactive content negotiation to allow servers to select\n      the appropriate response for a given request, based upon the user\n      agent\'s characteristics, as expressed in request headers.  In\n      practice, clients are often unwilling to send those request headers,\n      because it is not clear whether they will be used, and sending them\n      impacts both performance and privacy.\n      \n      This document defines an Accept-CH response header that servers can\n      use to advertise their use of request headers for proactive content\n      negotiation, along with a set of guidelines for the creation of such\n      headers, colloquially known as "Client Hints."\n\n  "Cookies: HTTP State Management Mechanism", Mike West, John Wilander,\n  2020-01-20, <draft-ietf-httpbis-rfc6265bis-04.txt>\n\n      This document defines the HTTP Cookie and Set-Cookie header fields.\n      These header fields can be used by HTTP servers to store state\n      (called cookies) at HTTP user agents, letting the servers maintain a\n      stateful session over the mostly stateless HTTP protocol.  Although\n      cookies have many historical infelicities that degrade their security\n      and privacy, the Cookie and Set-Cookie header fields are widely used\n      on the Internet.  This document obsoletes RFC 6265.\n\n  "Structured Headers for HTTP", Mark Nottingham, Poul-Henning Kamp,\n  2019-10-31, <draft-ietf-httpbis-header-structure-14.txt>\n\n      This document describes a set of data types and associated algorithms\n      that are intended to make it easier and safer to define and handle\n      HTTP header fields.  It is intended for use by specifications of new\n      HTTP header fields that wish to use a common syntax that is more\n      restrictive than traditional HTTP field values.\n\n  "Expect-CT Extension for HTTP", estark@google.com, 2018-12-09,\n  <draft-ietf-httpbis-expect-ct-08.txt>\n\n      This document defines a new HTTP header field named Expect-CT, which\n      allows web host operators to instruct user agents to expect valid\n      Signed Certificate Timestamps (SCTs) to be served on connections to\n      these hosts.  Expect-CT allows web host operators to discover\n      misconfigurations in their Certificate Transparency deployments.\n      Further, web host operaters can use Expect-CT to ensure that, if a UA\n      which supports Expect-CT accepts a misissued certificate, that\n      certificate will be discoverable in Certificate Transparency logs.\n\n  "Secondary Certificate Authentication in HTTP/2", Mike Bishop, Nick\n  Sullivan, Martin Thomson, 2019-11-01,\n  <draft-ietf-httpbis-http2-secondary-certs-05.txt>\n\n      A use of TLS Exported Authenticators is described which enables\n      HTTP/2 clients and servers to offer additional certificate-based\n      credentials after the connection is established.  The means by which\n      these credentials are used with requests is defined.\n\n  "Building Protocols with HTTP", Mark Nottingham, 2019-11-01,\n  <draft-ietf-httpbis-bcp56bis-09.txt>\n\n      HTTP is often used as a substrate for other application protocols\n      (a.k.a.  HTTP-based APIs).  This document specifies best practices\n      for writing specifications that use HTTP to define new application\n      protocols, especially when they are defined for diverse\n      implementation and broad deployment (e.g., in standards efforts).\n\n  "HTTP Representation Variants", Mark Nottingham, 2019-11-03,\n  <draft-ietf-httpbis-variants-06.txt>\n\n      This specification introduces an alternative way to select a HTTP\n      response from a cache based upon its request headers, using the HTTP\n      "Variants" and "Variant-Key" response header fields.  Its aim is to\n      make HTTP proactive content negotiation more cache-friendly.\n\n  "HTTP Caching", Roy Fielding, Mark Nottingham, Julian Reschke, 2019-11-04,\n  <draft-ietf-httpbis-cache-06.txt>\n\n      The Hypertext Transfer Protocol (HTTP) is a stateless application-\n      level protocol for distributed, collaborative, hypertext information\n      systems.  This document defines HTTP caches and the associated header\n      fields that control cache behavior or indicate cacheable response\n      messages.\n      \n      This document obsoletes RFC 7234.\n\n  "HTTP/1.1 Messaging", Roy Fielding, Mark Nottingham, Julian Reschke,\n  2019-11-04, <draft-ietf-httpbis-messaging-06.txt>\n\n      The Hypertext Transfer Protocol (HTTP) is a stateless application-\n      level protocol for distributed, collaborative, hypertext information\n      systems.  This document specifies the HTTP/1.1 message syntax,\n      message parsing, connection management, and related security\n      concerns.\n      \n      This document obsoletes portions of RFC 7230.\n\n  "HTTP Semantics", Roy Fielding, Mark Nottingham, Julian Reschke,\n  2019-11-04, <draft-ietf-httpbis-semantics-06.txt>\n\n      The Hypertext Transfer Protocol (HTTP) is a stateless application-\n      level protocol for distributed, collaborative, hypertext information\n      systems.  This document defines the semantics of HTTP: its\n      architecture, terminology, the "http" and "https" Uniform Resource\n      Identifier (URI) schemes, core request methods, request header\n      fields, response status codes, response header fields, and content\n      negotiation.\n      \n      This document obsoletes RFC 2818, RFC 7231, RFC 7232, RFC 7233, RFC\n      7235, RFC 7538, RFC 7615, and portions of RFC 7230.\n\n  "The Cache-Status HTTP Response Header", Mark Nottingham, 2019-11-04,\n  <draft-ietf-httpbis-cache-header-02.txt>\n\n      To aid debugging, HTTP caches often append headers to a response\n      detailing how they handled the request.  This specification codifies\n      that practice and updates it for HTTP\'s current caching model.\n\n  "Using TLS 1.3 with HTTP/2", David Benjamin, 2019-10-17,\n  <draft-ietf-httpbis-http2-tls13-03.txt>\n\n      This document updates RFC 7540 by forbidding TLS 1.3 post-handshake\n      authentication, as an analog to the existing TLS 1.2 renegotiation\n      restriction.\n\n  "Digest Headers", Roberto Polli, Lucas Pardue, 2019-11-03,\n  <draft-ietf-httpbis-digest-headers-01.txt>\n\n      This document defines the Digest and Want-Digest header fields for\n      HTTP, thus allowing client and server to negotiate an integrity\n      checksum of the exchanged resource representation data.\n      \n      This document obsoletes RFC 3230.  It replaces the term "instance"\n      with "representation", which makes it consistent with the HTTP\n      Semantic and Context defined in RFC 7231.\n\n  "Extensible Prioritization Scheme for HTTP", Kazuho Oku, Lucas Pardue,\n  2019-11-20, <draft-kazuho-httpbis-priority-04.txt>\n\n      This document describes a scheme for prioritizing HTTP responses.\n      This scheme expresses the priority of each HTTP response using\n      absolute values, rather than as a relative relationship between a\n      group of HTTP responses.\n      \n      This document defines the Priority header field for communicating the\n      initial priority in an HTTP version-independent manner, as well as\n      HTTP/2 and HTTP/3 frames for reprioritizing the responses.  These\n      share a common format structure that is designed to provide future\n      extensibility.\n\nInterface to Network Security Functions (i2nsf)\n-----------------------------------------------\n\n  "Information Model of NSFs Capabilities", Liang Xia, John Strassner,\n  Cataldo Basile, Diego Lopez, 2019-04-24,\n  <draft-ietf-i2nsf-capability-05.txt>\n\n      This draft defines the concept of an NSF (Network Security Function)\n      capability, as well as its information model. Capabilities are a set\n      of features that are available from a managed entity, and are\n      represented as data that unambiguously characterizes an NSF.\n      Capabilities enable management entities to determine the set of\n      features from available NSFs that will be used, and simplify the\n      management of NSFs.\n\n  "Applicability of Interfaces to Network Security Functions to Network-Based\n  Security Services", Jaehoon Jeong, Sangwon Hyun, Tae-Jin Ahn, Susan Hares,\n  Diego Lopez, 2019-09-16, <draft-ietf-i2nsf-applicability-18.txt>\n\n      This document describes the applicability of Interface to Network\n      Security Functions (I2NSF) to network-based security services in\n      Network Functions Virtualization (NFV) environments, such as\n      firewall, deep packet inspection, or attack mitigation engines.\n\n  "Software-Defined Networking (SDN)-based IPsec Flow Protection", Rafael\n  Lopez, Gabriel Lopez-Millan, Fernando Pereniguez-Garcia, 2019-08-05,\n  <draft-ietf-i2nsf-sdn-ipsec-flow-protection-07.txt>\n\n      This document describes how providing IPsec-based flow protection by\n      means of a Software-Defined Network (SDN) controller (aka.  Security\n      Controller) and establishes the requirements to support this service.\n      It considers two main well-known scenarios in IPsec: (i) gateway-to-\n      gateway and (ii) host-to-host.  The SDN-based service described in\n      this document allows the distribution and monitoring of IPsec\n      information from a Security Controller to one or several flow-based\n      Network Security Function (NSF).  The NSFs implement IPsec to protect\n      data traffic between network resources.\n      \n      The document focuses on the NSF Facing Interface by providing models\n      for configuration and state data required to allow the Security\n      Controller to configure the IPsec databases (SPD, SAD, PAD) and IKEv2\n      to establish Security Associations with a reduced intervention of the\n      network administrator.\n\n  "I2NSF Consumer-Facing Interface YANG Data Model", Jaehoon Jeong, Chaehong\n  Chung, Tae-Jin Ahn, Rakesh Kumar, Susan Hares, 2019-11-04,\n  <draft-ietf-i2nsf-consumer-facing-interface-dm-07.txt>\n\n      This document describes an information model and a YANG data model\n      for the Consumer-Facing Interface between an Interface to Network\n      Security Functions (I2NSF) User and Security Controller in an I2NSF\n      system in a Network Functions Virtualization (NFV) environment.  The\n      information model defines various types of managed objects and the\n      relationship among them needed to build the interface.  The\n      information model is organized based on the "Event-Condition-Action"\n      (ECA) policy model defined by a capability information model for\n      I2NSF [i2nsf-capability-im], and the data model is defined for\n      enabling different users of a given I2NSF system to define, manage,\n      and monitor security policies for specific flows within an\n      administrative domain.\n\n  "I2NSF Network Security Function-Facing Interface YANG Data Model", Jinyong\n  Kim, Jaehoon Jeong, J., PARK, Susan Hares, Qiushi Lin, 2019-11-04,\n  <draft-ietf-i2nsf-nsf-facing-interface-dm-08.txt>\n\n      This document defines a YANG data model for configuring security\n      policy rules on Network Security Functions (NSF) in the Interface to\n      Network Security Functions (I2NSF) framework.  The YANG data model in\n      this document corresponds to the information model for NSF-Facing\n      Interface in the I2NSF framework.\n\n  "I2NSF Capability YANG Data Model", Susan Hares, Jaehoon Jeong, Jinyong\n  Kim, Robert Moskowitz, Qiushi Lin, 2019-07-25,\n  <draft-ietf-i2nsf-capability-data-model-05.txt>\n\n      This document defines a YANG data model for the capabilities of\n      various Network Security Functions (NSFs) in the Interface to Network\n      Security Functions (I2NSF) framework to centrally manage the\n      capabilities of the various NSFs.\n\n  "I2NSF Registration Interface YANG Data Model", Sangwon Hyun, Jaehoon\n  Jeong, TaeKyun Roh, Sarang Wi, J., PARK, 2020-01-21,\n  <draft-ietf-i2nsf-registration-interface-dm-06.txt>\n\n      This document defines an information model and a YANG data model for\n      Registration Interface between Security Controller and Developer\'s\n      Management System (DMS) in the Interface to Network Security\n      Functions (I2NSF) framework to register Network Security Functions\n      (NSF) of the DMS into the Security Controller.  The objective of\n      these information and data models is to support NSF capability\n      registration and query via I2NSF Registration Interface.\n\n  "I2NSF NSF Monitoring YANG Data Model", Jaehoon Jeong, Chaehong Chung,\n  Susan Hares, Liang Xia, Henk Birkholz, 2019-11-04,\n  <draft-ietf-i2nsf-nsf-monitoring-data-model-02.txt>\n\n      This document proposes an information model and the corresponding\n      YANG data model for monitoring Network Security Functions (NSFs) in\n      the Interface to Network Security Functions (I2NSF) framework.  If\n      the monitoring of NSFs is performed in a comprehensive way, it is\n      possible to detect the indication of malicious activity, anomalous\n      behavior or the potential sign of denial of service attacks in a\n      timely manner.  This monitoring functionality is based on the\n      monitoring information that is generated by NSFs.  Thus, this\n      document describes not only an information model for monitoring NSFs\n      along with a YANG data diagram, but also the corresponding YANG data\n      model for monitoring NSFs.\n      \n      Editorial Note (To be removed by RFC Editor)\n      \n      Please update these statements within the document with the RFC\n      number to be assigned to this document:\n      \n      "This version of this YANG module is part of RFC 6087;"\n      \n      "RFC XXXX: I2NSF NSF Monitoring YANG Data Model"\n      \n      "reference: RFC 6087"\n      \n      Please update the "revision" date of the YANG module.\n\nInterface to the Routing System (i2rs)\n--------------------------------------\n\n  "A YANG Data Model for Layer-2 Network Topologies", Jie Dong, Xiugang Wei,\n  Qin WU, Mohamed Boucadair, Anders Liu, 2019-10-15,\n  <draft-ietf-i2rs-yang-l2-network-topology-12.txt>\n\n      This document defines a YANG data model for Layer 2 network\n      topologies.\n      \n      Editorial Note (To be removed by RFC Editor)\n      \n      Please update these statements within the document with the RFC\n      number to be assigned to this document:\n      \n      o  "This version of this YANG module is part of RFC XXXX;"\n      \n      o  "RFC XXXX: A YANG Data Model for Layer-2 Network Topologies";\n      \n      o  reference: RFC XXXX\n      \n      Please update the "revision" date of the YANG module.\n\nInternet Architecture Board (iab)\n---------------------------------\n\n  "The Harmful Consequences of the Robustness Principle", Martin Thomson,\n  2019-11-03, <draft-iab-protocol-maintenance-04.txt>\n\n      The robustness principle, often phrased as "be conservative in what\n      you send, and liberal in what you accept", has long guided the design\n      and implementation of Internet protocols.  The posture this statement\n      advocates promotes interoperability in the short term, but can\n      negatively affect the protocol ecosystem over time.  For a protocol\n      that is actively maintained, the robustness principle can, and\n      should, be avoided.\n\n  "Principles for Operation of Internet Assigned Numbers Authority (IANA)\n  Registries", Russ Housley, Olaf Kolkman, 2019-06-26,\n  <draft-iab-rfc7500-bis-00.txt>\n\n      This document provides principles for the operation of Internet\n      Assigned Numbers Authority (IANA) registries.\n\n  "Long-term Viability of Protocol Extension Mechanisms", Martin Thomson,\n  2019-08-07, <draft-iab-use-it-or-lose-it-00.txt>\n\n      The ability to change protocols depends on exercising the extension\n      and version negotiation mechanisms that support change.  Protocols\n      that don\'t use these mechanisms can find that deploying changes can\n      be difficult and costly.\n\n  "The Internet is for End Users", Mark Nottingham, 2020-01-22,\n  <draft-iab-for-the-users-02.txt>\n\n      This document explains why the IAB believes the IETF should consider\n      end users as its highest priority concern, and how that can be done.\n\n  "Report from the IAB Workshop on Exploring Synergy between Content\n  Aggregation and the Publisher Ecosystem (ESCAPE)", Martin Thomson, Mark\n  Nottingham, 2019-09-18, <draft-iab-escape-report-00.txt>\n\n      The Exploring Synergy between Content Aggregation and the Publisher\n      Ecosystem (ESCAPE) Workshop was convened by the Internet Architecture\n      Board (IAB) in July 2019.  This report summarizes its significant\n      points of discussion and identifies topics that may warrant further\n      consideration.\n\nIETF Administrative Support Activity 2 (iasa2)\n----------------------------------------------\n\n  "Update to the Process for Selection of Trustees for the IETF Trust", Jari\n  Arkko, Ted Hardie, 2019-02-04, <draft-ietf-iasa2-trust-update-03.txt>\n\n      This memo updates the process for selection of trustees for the IETF\n      Trust.  Previously, the Internet Administrative Oversight Committee\n      (IAOC) members also acted as trustees, but the IAOC has been\n      eliminated as part of an update of the structure of the Internet\n      Administrative Support Activity (IASA).  This memo specifies that the\n      trustees shall be selected separately.\n      \n      This memo obsoletes RFC 4371.  The changes relate only to the\n      selection of trustees.  All other aspects of the IETF Trust remain as\n      they are today.\n\n  "Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust", Jari\n  Arkko, 2018-10-11, <draft-ietf-iasa2-trust-rationale-03.txt>\n\n      This document is published to capture the rationale for the changes\n      introduced in RFC NNNN (RFC Editor: please replace NNNN with the RFC\n      number of [I-D.ietf-iasa2-trust-update]), Update to the Process for\n      Selection of Trustees for the IETF Trust.\n      \n      At the time RFC NNNN was published, IETF administrative structure\n      changes ("IASA 2.0") had an impact on the IETF Trust because members\n      of the IETF Administrative Oversight Committee (IAOC), which was\n      being phased out, had served as Trustees of the IETF Trust.  This\n      document provides background on the past IETF Trust arrangements,\n      explains the effect of the rules in the founding documents during the\n      transition to the new arrangement, and provides a rationale for the\n      update.\n\n  "Advice to the Trustees of the IETF Trust on Rights to Be Granted in IETF\n  Documents", Joel Halpern, 2019-08-21, <draft-ietf-iasa2-rfc5377bis-03.txt>\n\n      Contributors grant intellectual property rights to the IETF.  The\n      IETF Trust holds and manages those rights on behalf of the IETF.  The\n      Trustees of the IETF Trust are responsible for that management.  This\n      management includes granting the licenses to copy, implement, and\n      otherwise use IETF Contributions, among them Internet-Drafts and\n      RFCs.  The Trustees of the IETF Trust accept direction from the IETF\n      regarding the rights to be granted.  This document describes the\n      desires of the IETF regarding outbound rights to be granted in IETF\n      Contributions.  This document obsoletes RFC 5377 solely for the\n      purpose of removing references to the IAOC which was part of IASA.\n\n  "Update to the IETF Anti-Harassment Procedures for the Replacement of the\n  IAOC with the IETF Administration LLC", Pete Resnick, Adrian Farrel,\n  2019-09-14, <draft-ietf-iasa2-rfc7776bis-03.txt>\n\n      The IETF Anti-Harassment Procedures are described in RFC 7776.\n      \n      The IETF Administrative Oversight Committee (IAOC) has been replaced\n      by the IETF Administration LLC, and the IETF Administrative Director\n      has been replaced by the IETF LLC Executive Director.  This document\n      updates RFC 7776 to amend these terms.\n      \n      RFC 7776 contained updates to RFC 7437.  draft-ietf-iasa2-rfc7437bis\n      has incorporated those updates, so this document also updates RFC\n      7776 to remove those updates.\n      \n      NOTE for RFC Editor and Readers of this Document\n      \n      When published as an RFC\n      \n      o  All references to and mentions of draft-ietf-iasa2-rfc7437bis in\n      this document should be replaced by the RFC that results from\n      draft-ietf-iasa2-rfc7437bis.\n      \n      o  The string "XXXX" should be replaced with the RFC number assigned\n      to the RFC that results from draft-ietf-iasa2-rfc7437bis.\n      \n      o  This note should be removed.\n      \n      *** END OF NOTE ***\n\n  "IAB, IESG, IETF Trust and IETF LLC Selection, Confirmation, and Recall\n  Process: Operation of the IETF Nominating and Recall Committees", Murray\n  Kucherawy, Robert Hinden, Jason Livingood, 2019-07-11,\n  <draft-ietf-iasa2-rfc7437bis-09.txt>\n\n      The process by which the members of the IAB and IESG, some Trustees\n      of the IETF Trust, and some Directors of the IETF LLC are selected,\n      confirmed, and recalled is specified in this document.  This document\n      is based on RFC7437.  Only those updates required to reflect the\n      changes introduced by IASA 2.0 have been included.  Any other changes\n      will be addressed in future documents.\n      \n      This document obsoletes RFC7437 and RFC8318.\n\n  "Consolidated IASA 2.0 Updates of IETF Administrative Terminology", John\n  Klensin, 2019-03-11, <draft-ietf-iasa2-consolidated-upd-07.txt>\n\n      In 2018, the IETF began the transition to a new administrative\n      structure and updated its IETF Administrative Support Activity (IASA)\n      to a new "IASA 2.0" structure.  In addition to more substantive\n      changes that are described in other documents, the transition to the\n      2018 IETF Administrative Support structure changes several position\n      titles and organizational relationships that are referenced\n      elsewhere.  Rather than reissue those referencing documents\n      individually, this specification provides updates to them and\n      deprecates some now-obsolete documents to ensure that there is no\n      confusion due to these changes.\n\n  "The IETF-ISOC Relationship", Gonzalo Camarillo, Jason Livingood,\n  2019-08-27, <draft-ietf-iasa2-rfc2031bis-08.txt>\n\n      This document summarises the Internet Engineering Task Force (IETF) -\n      Internet Society (ISOC) relationship, following a major revision to\n      the structure of the IETF Administrative Support Activity (IASA) in\n      2018.  The IASA was revised under a new "IASA 2.0" structure by the\n      IASA2 Working Group, which changed the IETF\'s administrative, legal,\n      and financial structure.  As a result, it also changed the\n      relationship between the IETF and ISOC, which made it necessary to\n      revise RFC 2031.\n\n  "Structure of the IETF Administrative Support Activity, Version 2.0", Brian\n  Haberman, Joseph Hall, Jason Livingood, 2019-04-12,\n  <draft-ietf-iasa2-rfc4071bis-11.txt>\n\n      The IETF Administrative Support Activity (IASA) was originally\n      established in 2005.  In the years since then, the needs of the IETF\n      evolved in ways that required changes to its administrative\n      structure.  The purpose of this document is to document and describe\n      the IETF Administrative Support Activity, version 2 (IASA 2.0).  It\n      defines the roles and responsibilities of the IETF Administration LLC\n      Board, the IETF Executive Director, and the Internet Society in the\n      fiscal and administrative support of the IETF standards process.  It\n      also defines the membership and selection rules for the IETF\n      Administration LLC Board.\n      \n      This document obsoletes RFC 4071, RFC 4333, and RFC 7691.\n\nInteractive Connectivity Establishment (ice)\n--------------------------------------------\n\n  "Trickle ICE: Incremental Provisioning of Candidates for the Interactive\n  Connectivity Establishment (ICE) Protocol", Emil Ivov, Eric Rescorla,\n  Justin Uberti, Peter Saint-Andre, 2018-04-15,\n  <draft-ietf-ice-trickle-21.txt>\n\n      This document describes "Trickle ICE", an extension to the\n      Interactive Connectivity Establishment (ICE) protocol that enables\n      ICE agents to begin connectivity checks while they are still\n      gathering candidates, by incrementally exchanging candidates over\n      time instead of all at once.  This method can considerably accelerate\n      the process of establishing a communication session.\n\n  "Interactive Connectivity Establishment Patiently Awaiting Connectivity\n  (ICE PAC)", Christer Holmberg, Justin Uberti, 2019-10-13,\n  <draft-ietf-ice-pac-03.txt>\n\n      During the process of establishing peer-to-peer connectivity, ICE\n      agents can encounter situations where they have no candidate pairs to\n      check, and, as a result, conclude that ICE processing has failed.\n      However, because additional candidate pairs can be discovered during\n      ICE processing, declaring failure at this point may be premature.\n      This document discusses when these situations can occur and proposes\n      a way to avoid premature failure.  This document updates RFC 8445 and\n      RFC XXXX.\n      \n      [RFC EDITOR NOTE: Please replace RFC XXXX with the RFC number of\n      draft-ietf-ice-trickle once it has been published.  Please also\n      indicate that this specification updates RFC XXXX.]\n\nInformation-Centric Networking (icnrg)\n--------------------------------------\n\n  "Research Directions for Using ICN in Disaster Scenarios", Jan Seedorf,\n  Mayutan Arumaithurai, Atsushi Tagami, K. Ramakrishnan, Nicola\n  Blefari-Melazzi, 2019-11-26, <draft-irtf-icnrg-disaster-09.txt>\n\n      Information Centric Networking (ICN) is a new paradigm where the\n      network provides users with named content, instead of communication\n      channels between hosts.  This document outlines some research\n      directions for Information Centric Networking with respect to\n      applying ICN approaches for coping with natural or human-generated,\n      large-scale disasters.  This document is a product of the\n      Information-Centric Networking Research Group (ICNRG).\n\n  "File-Like ICN Collections (FLIC)", Christian Tschudin, Christopher Wood,\n  Marc Mosko, David Oran, 2019-11-04, <draft-irtf-icnrg-flic-02.txt>\n\n      This document describes a bare bones "index table"-approach for\n      organizing a set of ICN data objects into a large, File-Like ICN\n      Collection (FLIC).  At the core of this collection is a so called\n      manifest which acts as the collection\'s root node.  The manifest\n      contains an index table with pointers, each pointer being a hash\n      value pointing to either a final data block or another index table\n      node.\n\n  "Information-Centric Networking (ICN): CCNx and NDN Terminology", Bastiaan\n  Wissingh, Christopher Wood, Alex Afanasyev, Lixia Zhang, David Oran,\n  Christian Tschudin, 2020-01-17, <draft-irtf-icnrg-terminology-08.txt>\n\n      Information Centric Networking (ICN) is a novel paradigm where\n      network communications are accomplished by requesting named content,\n      instead of sending packets to destination addresses.  Named Data\n      Networking (NDN) and Content-Centric Networking (CCNx) are two\n      prominent ICN architectures.  This document provides an overview of\n      the terminology and definitions that have been used in describing\n      concepts in these two implementations of ICN.  While there are other\n      ICN architectures, they are not part of the NDN and CCNx concepts and\n      as such are out of scope for this document.  This document is a\n      product of the Information-Centric Networking Research Group (ICNRG).\n\n  "Native Deployment of ICN in LTE, 4G Mobile Networks", Prakash suthar,\n  Milan Stolic, Anil Jangam, Dirk Trossen, Ravi Ravindran, 2019-11-04,\n  <draft-irtf-icnrg-icn-lte-4g-05.txt>\n\n      LTE, 4G mobile networks use IP-based transport for control plane to\n      establish the data session and user plane for actual data delivery.\n      In existing architecture, IP transport used in the user plane is not\n      optimized for data transport, which leads to an inefficient data\n      delivery.  IP unicast routing from server to clients is used for\n      delivery of multimedia content to User Equipment (UE), where each\n      user gets a separate stream.  From a bandwidth and routing\n      perspective, this approach is inefficient.  Multicast and broadcast\n      technologies have emerged recently for mobile networks, but their\n      deployments are very limited or at an experimental stage due to\n      complex architecture and radio spectrum issues.  ICN is a rapidly\n      emerging technology with built-in features for efficient multimedia\n      data delivery.  However much of the work is focused on fixed\n      networks.  The focus of this draft is on native deployment of ICN in\n      cellular mobile networks by using ICN in a 3GPP protocol stack.  ICN\n      has an inherent capability for multicast, anchorless mobility and\n      security, and it is optimized for data delivery using local caching\n      at the edge.  The proposed approaches in this draft allow ICN to be\n      enabled natively over the current LTE stack comprising PDCP/RLC/MAC/\n      PHY, or in a dual stack mode (along with IP).  These approaches can\n      help optimize the mobile networks by leveraging the inherent benefits\n      of ICN.\n\n  "Deployment Considerations for Information-Centric Networking (ICN)", Akbar\n  Rahman, Dirk Trossen, Dirk Kutscher, Ravi Ravindran, 2019-09-03,\n  <draft-irtf-icnrg-deployment-guidelines-07.txt>\n\n      Information-Centric Networking (ICN) is now reaching technological\n      maturity after many years of fundamental research and\n      experimentation.  This document provides a number of deployment\n      considerations in the interest of helping the ICN community move\n      forward to the next step of live deployments.  First, the major\n      deployment configurations for ICN are described including the key\n      overlay and underlay approaches.  Then proposed deployment migration\n      paths are outlined to address major practical issues such as network\n      and application migration.  Next, selected ICN trial experiences are\n      summarized.  Finally, protocol areas that require further\n      standardization are identified to facilitate future interoperable ICN\n      deployments.  This document is a product of the Information-Centric\n      Networking Research Group (ICNRG).\n\n  "MAP-Me : Managing Anchorless Mobility in Content Centric Networking",\n  Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini,\n  2019-11-03, <draft-irtf-icnrg-mapme-04.txt>\n\n      Consumer mobility is supported in ICN by design, in virtue of its\n      connectionless pull-based communication model; producer mobility\n      though is not natively supported.  This document describes MAP-Me, an\n      anchor-less solution to manage micro-mobility of content producers in\n      the CCN (Content Centric Networking) and NDN (Named Data Networking)\n      architectures, with support for latency-sensitive applications.  MAP-\n      Me consists in the combination of two data plane protocols, triggered\n      by producer movements, and leveraging ICN named-based data plane.\n      The main protocol consists in a lightweight FIB update process,\n      complemented by a mechanism of local notification and scoped\n      discovery suitable for low latency applications and fast mobility.\n\n  "Design Guidelines for Name Resolution Service in ICN", Jungha Hong, Taewan\n  You, Yong-Geun Hong, Lijun Dong, Cedric Westphal, Borje Ohlman, 2019-11-04,\n  <draft-irtf-icnrg-nrs-requirements-03.txt>\n\n      This document discusses the functionalities and design guidelines for\n      Name Resolution Service (NRS) in ICN.  The NRS in ICN is to translate\n      an object name into some other information such as a locator, another\n      name, etc. for forwarding the object request.\n\n  "Architectural Considerations of ICN using Name Resolution Service", Jungha\n  Hong, Taewan You, Yong-Geun Hong, Ved Kafle, 2019-11-04,\n  <draft-irtf-icnrg-nrsarch-considerations-03.txt>\n\n      This document discusses architectural considerations and implications\n      of Information-Centric Networking (ICN) related to the usage of the\n      Name Resolution Service (NRS).  It describes how ICN architectures\n      may change and what implications are introduced within the ICN\n      routing system when NRS is integrated into ICN.\n\n  "ICN Adaptation to LowPAN Networks (ICN LoWPAN)", Cenk Gundogan, Thomas\n  Schmidt, Matthias Waehlisch, Christopher Scherb, Claudio Marxer, Christian\n  Tschudin, 2019-11-04, <draft-irtf-icnrg-icnlowpan-06.txt>\n\n      This document defines a convergence layer for CCNx and NDN over IEEE\n      802.15.4 LoWPAN networks.  A new frame format is specified to adapt\n      CCNx and NDN packets to the small MTU size of IEEE 802.15.4.  For\n      that, syntactic and semantic changes to the TLV-based header formats\n      are described.  To support compatibility with other LoWPAN\n      technologies that may coexist on a wireless medium, the dispatching\n      scheme provided by 6LoWPAN is extended to include new dispatch types\n      for CCNx and NDN.  Additionally, the link fragmentation component of\n      the 6LoWPAN dispatching framework is applied to ICN chunks.  In its\n      second part, the document defines stateless and stateful compression\n      schemes to improve efficiency on constrained links.  Stateless\n      compression reduces TLV expressions to static header fields for\n      common use cases.  Stateful compression schemes elide state local to\n      the LoWPAN and replace names in data packets by short local\n      identifiers.\n\n  "Internet Protocol Tunneling over Content Centric Mobile Networks", Greg\n  White, Susmit Shannigrahi, Chengyu Fan, 2019-08-02,\n  <draft-irtf-icnrg-ipoc-00.txt>\n\n      This document describes a protocol that enables tunneling of Internet\n      Protocol traffic over a Content Centric Network (CCN) or a Named Data\n      Network (NDN).  The target use case for such a protocol is to provide\n      an IP mobility plane for mobile networks that might otherwise use IP-\n      over-IP tunneling, such as the GPRS Tunneling Protocol (GTP) used by\n      the Evolved Packet Core in LTE networks (LTE-EPC).  By leveraging the\n      elegant, built-in support for mobility provided by CCN or NDN, this\n      protocol achieves performance on par with LTE-EPC, equivalent\n      efficiency, and substantially lower implementation and protocol\n      complexity [Shannigrahi].  Furthermore, the use of CCN/NDN for this\n      purpose paves the way for the deployment of ICN native applications\n      on the mobile network.\n\n  "Enabling ICN in 3GPP\'s 5G NextGen Core Architecture", Ravi Ravindran,\n  Prakash suthar, Dirk Trossen, Chonggang Wang, Greg White, 2019-11-27,\n  <draft-irtf-icnrg-5gc-icn-01.txt>\n\n      The proposed 3GPP\'s 5G core nextgen architecture (5GC) allows the\n      introduction of new user and control plane function, considering the\n      support for network slicing functions, that offers greater\n      flexibility to handle heterogeneous devices and applications.  In\n      this draft, we provide a short description of the proposed 5GC\n      architecture, including recent efforts to provide cellular Local Area\n      Network (LAN) connectivity, followed by extensions to 5GC\'s control\n      and user plane to support Packet Data Unit (PDU) sessions from\n      Information-Centric Networks (ICN).  In addition, ICN over 5GLAN is\n      also described.\n\nInter-Domain Routing (idr)\n--------------------------\n\n  "Extended Optional Parameters Length for BGP OPEN Message", Enke Chen, John\n  Scudder, 2019-11-18, <draft-ietf-idr-ext-opt-param-08.txt>\n\n      The Optional Parameters in the BGP OPEN message as defined in the\n      base BGP specification are limited to 255 octets due to a one-octet\n      length field.  BGP Capabilities are carried in this field and may\n      foreseeably exceed 255 octets in the future, leading to concern about\n      this limitation.\n      \n      In this document we update RFC 4271 by extending, in a backward-\n      compatible manner, the length of the Optional Parameters in the BGP\n      OPEN.  The Parameter Length field of individual Optional Parameters\n      is also extended.\n\n  "Dissemination of Flow Specification Rules for IPv6", Christoph Loibl,\n  Robert Raszuk, Susan Hares, 2019-11-03, <draft-ietf-idr-flow-spec-v6-10.txt>\n\n      Dissemination of Flow Specification Rules [I-D.ietf-idr-rfc5575bis]\n      provides a protocol extension for propagation of traffic flow\n      information for the purpose of rate limiting or filtering.  The\n      [I-D.ietf-idr-rfc5575bis] specifies those extensions for IPv4\n      protocol data packets only.\n      \n      This specification extends [I-D.ietf-idr-rfc5575bis] and defines\n      changes to the original document in order to make it also usable and\n      applicable to IPv6 data packets.\n\n  "BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian Cassar,\n  Erik Aman, Bruno Decraene, Kevin Wang, 2020-01-08,\n  <draft-ietf-idr-bgp-optimal-route-reflection-20.txt>\n\n      This document proposes a solution for BGP route reflectors to allow\n      them to choose the best path for their clients that the clients\n      themselves would have chosen under the same conditions, without\n      requiring further state or any new features to be placed on the\n      clients.  This facilitates, for example, best exit point policy (hot\n      potato routing).  This solution is primarily applicable in\n      deployments using centralized route reflectors.\n      \n      The solution relies upon all route reflectors learning all paths\n      which are eligible for consideration.  Best path selection is\n      performed in each route reflector based on a configured virtual\n      location in the IGP.  The location can be the same for all clients or\n      different per peer/update group or per peer.  Best path selection can\n      also be performed based on user configured policies in each route\n      reflector.\n\n  "Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro,\n  Juan Alcaide, Clarence Filsfils, David Smith, Prodosh Mohapatra,\n  2019-08-09, <draft-ietf-idr-bgp-flowspec-oid-10.txt>\n\n      This document describes a modification to the validation procedure\n      defined in [RFC5575bis] for the dissemination of BGP Flow\n      Specifications.  [RFC5575bis] requires that the originator of the\n      Flow Specification matches the originator of the best-match unicast\n      route for the destination prefix embedded in the Flow Specification.\n      This allows only BGP speakers within the data forwarding path (such\n      as autonomous system border routers) to originate BGP Flow\n      Specifications.  Though it is possible to disseminate such Flow\n      Specifications directly from border routers, it may be operationally\n      cumbersome in an autonomous system with a large number of border\n      routers having complex BGP policies.  The modification proposed\n      herein enables Flow Specifications to be originated from a\n      centralized BGP route controller.\n\n  "Distribution of Traffic Engineering (TE) Policies and State using BGP-LS",\n  Stefano Previdi, Ketan Talaulikar, Jie Dong, Mach Chen, Hannes Gredler,\n  Jeff Tantsura, 2019-10-14, <draft-ietf-idr-te-lsp-distribution-12.txt>\n\n      This document describes a mechanism to collect the Traffic\n      Engineering and Policy information that is locally available in a\n      node and advertise it into BGP Link State (BGP-LS) updates.  Such\n      information can be used by external components for path computation,\n      re-optimization, service placement, network visualization, etc.\n\n  "Route Target Constrained Distribution of Routes with no Route Targets",\n  Eric Rosen, Keyur Patel, Jeffrey Haas, Robert Raszuk, 2019-10-01,\n  <draft-ietf-idr-rtc-no-rt-12.txt>\n\n      There are a variety of BGP-enabled services in which the originator\n      of a BGP route may attach one or more "Route Targets" to the route.\n      By means of a procedure known as "RT Constrained Distribution" (RTC),\n      a given BGP speaker (call it "B") can announce the set of RTs in\n      which it has interest.  The implication is that if a particular route\n      (call it "R") carries any RTs at all, BGP speaker B wants to receive\n      route R if and only if B has announced interest in one of the RTs\n      carried by R.  However, if route R does not carry any RTs at all,\n      prior specifications do not make it clear whether B\'s use of RTC\n      implies that it does not want to receive route R.  This has caused\n      interoperability problems in the field, as some implementations of\n      RTC do not allow B to receive R, but some services presuppose that B\n      will receive R.  This document updates RFC 4684 by clarifying the\n      effect of the RTC mechanism on routes that do not have any RTs.\n\n  "Performance-based BGP Routing Mechanism", Xiaohu Xu, Shraddha Hegde, Ketan\n  Talaulikar, Mohamed Boucadair, Christian Jacquenet, 2019-10-13,\n  <draft-ietf-idr-performance-routing-02.txt>\n\n      The current BGP specification doesn\'t use network performance metrics\n      (e.g., network latency) in the route selection decision process.\n      This document describes a performance-based BGP routing mechanism in\n      which network latency metric is taken as one of the route selection\n      criteria.  This routing mechanism is useful for those server\n      providers with global reach to deliver low-latency network\n      connectivity services to their customers.\n\n  "BGP Dissemination of L2 Flow Specification Rules", Hao Weiguo, Donald\n  Eastlake, Jim Uttaro, Stephane Litkowski, Shunwan Zhuang, 2019-12-31,\n  <draft-ietf-idr-flowspec-l2vpn-13.txt>\n\n      This document defines a Border Gateway Protocol (BGP) Flow-spec\n      extension to disseminate Ethernet Layer 2 (L2) and Layer 2 Virtual\n      Private Network (L2VPN) traffic filtering rules either by themselves\n      or in conjunction with L3 Flow-specs.  AFI/SAFI 6/133 and 25/134 are\n      used for these purposes.  New component types and an extended\n      community also are defined.\n\n  "Distribution of Traffic Engineering Extended Admin Groups using BGP-LS",\n  Zitao Wang, Qin WU, Jeff Tantsura, Ketan Talaulikar, 2019-11-21,\n  <draft-ietf-idr-eag-distribution-11.txt>\n\n      Administrative groups (commonly referred to as "colors" or "link\n      colors") are link attributes that are advertised by link state\n      protocols like IS-IS (Intermediate System to Intermediate System) and\n      OSPF (Open Shortest Path First) and used for traffic engineering.\n      These administrative groups have initially been defined as a fixed-\n      length 32-bit bitmask.  As networks grew and more use-cases were\n      introduced, the 32-bit length was found to be constraining and hence\n      extended administrative groups were introduced in the link state\n      protocols.  The 32-bit administrative groups are already advertised\n      as link attributes in BGP-LS (Border Gateway Protocol Link-State).\n      This document defines extensions to BGP-LS for advertisement of the\n      extended administrative groups.\n\n  "BGP-LS extensions for Segment Routing BGP Egress Peer Engineering",\n  Stefano Previdi, Ketan Talaulikar, Clarence Filsfils, Keyur Patel, Saikat\n  Ray, Jie Dong, 2019-05-16, <draft-ietf-idr-bgpls-segment-routing-epe-19.txt>\n\n      Segment Routing (SR) leverages source routing.  A node steers a\n      packet through a controlled set of instructions, called segments, by\n      prepending the packet with an SR header.  A segment can represent any\n      instruction, topological or service-based.  SR segments allow\n      steering a flow through any topological path and service chain while\n      maintaining per-flow state only at the ingress node of the SR domain.\n      \n      This document describes an extension to BGP Link-State (BGP-LS) for\n      advertisement of BGP Peering Segments along with their BGP peering\n      node information so that efficient BGP Egress Peer Engineering (EPE)\n      policies and strategies can be computed based on Segment Routing.\n\n  "Making Route Servers Aware of Data Link Failures at IXPs", Randy Bush,\n  Jeffrey Haas, John Scudder, Arnold Nipper, Christoph Dietzel, 2019-09-02,\n  <draft-ietf-idr-rs-bfd-08.txt>\n\n      When BGP route servers are used, the data plane is not congruent with\n      the control plane.  Therefore, peers at an Internet exchange can lose\n      data connectivity without the control plane being aware of it, and\n      packets are lost.  This document proposes the use of a newly defined\n      BGP Subsequent Address Family Identifier (SAFI) both to allow the\n      route server to request its clients use BFD to track data plane\n      connectivity to their peers\' addresses, and for the clients to signal\n      that connectivity state back to the route server.\n\n  "BGP YANG Model for Service Provider Networks", Mahesh Jethanandani, Keyur\n  Patel, Susan Hares, Jeffrey Haas, 2019-10-04,\n  <draft-ietf-idr-bgp-model-07.txt>\n\n      This document defines a YANG data model for configuring and managing\n      BGP, including protocol, policy, and operational aspects, such as\n      RIB, based on data center, carrier and content provider operational\n      requirements.\n\n  "The BGP Tunnel Encapsulation Attribute", Keyur Patel, Gunter Van de Velde,\n  Srihari Ramachandra, 2019-12-01, <draft-ietf-idr-tunnel-encaps-15.txt>\n\n      RFC 5512 defines a BGP Path Attribute known as the "Tunnel\n      Encapsulation Attribute".  This attribute allows one to specify a set\n      of tunnels.  For each such tunnel, the attribute can provide the\n      information needed to create the tunnel and the corresponding\n      encapsulation header.  The attribute can also provide information\n      that aids in choosing whether a particular packet is to be sent\n      through a particular tunnel.  RFC 5512 states that the attribute is\n      only carried in BGP UPDATEs that have the "Encapsulation Subsequent\n      Address Family (Encapsulation SAFI)".  This document deprecates the\n      Encapsulation SAFI (which has never been used in production), and\n      specifies semantics for the attribute when it is carried in UPDATEs\n      of certain other SAFIs.  This document adds support for additional\n      tunnel types, and allows a remote tunnel endpoint address to be\n      specified for each tunnel.  This document also provides support for\n      specifying fields of any inner or outer encapsulations that may be\n      used by a particular tunnel.\n      \n      This document obsoletes RFC 5512.\n\n  "BGP Dissemination of Flow Specification Rules for Tunneled Traffic",\n  Donald Eastlake, Hao Weiguo, Shunwan Zhuang, Zhenbin Li, Rong Gu,\n  2020-01-16, <draft-ietf-idr-flowspec-nvo3-08.txt>\n\n      This draft specifies a Border Gateway Protocol Network Layer\n      Reachability Information (BGP NLRI) encoding format for flow\n      specifications (RFC 5575bis) that can match on a variety of tunneled\n      traffic. In addition, flow specification components are specified for\n      certain tunneling header fields.\n\n  "Applying BGP flowspec rules on a specific interface set", Stephane\n  Litkowski, Adam Simpson, Keyur Patel, Jeffrey Haas, Lucy Yong, 2019-11-18,\n  <draft-ietf-idr-flowspec-interfaceset-05.txt>\n\n      The BGP Flow Specification (flowspec) Network Layer Reachability\n      Information (BGP NLRI) extension (draft-ietf-idr-rfc5575bis) is used\n      to distribute traffic flow specifications into BGP.  The primary\n      application of this extension is the distribution of traffic\n      filtering policies for the mitigation of distributed denial of\n      service (DDoS) attacks.\n      \n      By default, flow specification filters are applied on all forwarding\n      interfaces that are enabled for use by the BGP flowspec extension.  A\n      network operator may wish to apply a given filter selectively to a\n      subset of interfaces based on an internal classification scheme.\n      Examples of this include "all customer interfaces", "all peer\n      interfaces", "all transit interfaces", etc.\n      \n      This document defines BGP Extended Communities (RFC4360) that allow\n      such filters to be selectively applied to sets of forwarding\n      interfaces sharing a common group identifier.  The BGP Extended\n      Communities carrying this group identifier are referred to as the BGP\n      Flowspec "interface-set" Extended Communities.\n\n  "Flowspec Indirection-id Redirect", Gunter Van de Velde, Keyur Patel,\n  Zhenbin Li, 2019-10-29, <draft-ietf-idr-flowspec-path-redirect-10.txt>\n\n      This document defines a new extended community known as "FlowSpec\n      Redirect to indirection-id Extended Community".  This extended\n      community triggers advanced redirection capabilities to flowspec\n      clients.  When activated, this flowspec extended community is used by\n      a flowspec client to retrieve the corresponding next-hop and encoding\n      information within a localised indirection-id mapping table.\n      \n      The functionality detailed in this document allows a network\n      controller to decouple the BGP flowspec redirection instruction from\n      the operation of the available paths.\n\n  "BGP Link-State extensions for Segment Routing", Stefano Previdi, Ketan\n  Talaulikar, Clarence Filsfils, Hannes Gredler, Mach Chen, 2019-06-27,\n  <draft-ietf-idr-bgp-ls-segment-routing-ext-16.txt>\n\n      Segment Routing (SR) allows for a flexible definition of end-to-end\n      paths by encoding paths as sequences of topological sub-paths, called\n      "segments".  These segments are advertised by routing protocols e.g.\n      by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within\n      IGP topologies.\n      \n      This document defines extensions to the BGP Link-state address-family\n      in order to carry segment routing information via BGP.\n\n  "Dissemination of Flow Specification Rules", Christoph Loibl, Susan Hares,\n  Robert Raszuk, Danny McPherson, Martin Bacher, 2020-01-17,\n  <draft-ietf-idr-rfc5575bis-19.txt>\n\n      This document defines a Border Gateway Protocol Network Layer\n      Reachability Information (BGP NLRI) encoding format that can be used\n      to distribute traffic Flow Specifications.  This allows the routing\n      system to propagate information regarding more specific components of\n      the traffic aggregate defined by an IP destination prefix.\n      \n      It also specifies BGP Extended Community encoding formats, that can\n      be used to propagate Traffic Filtering Actions along with the Flow\n      Specification NLRI.  Those Traffic Filtering Actions encode actions a\n      routing system can take if the packet matches the Flow Specification.\n      \n      Additionally, it defines two applications of that encoding format:\n      one that can be used to automate inter-domain coordination of traffic\n      filtering, such as what is required in order to mitigate\n      (distributed) denial-of-service attacks, and a second application to\n      provide traffic filtering in the context of a BGP/MPLS VPN service.\n      Other applications (ie. centralized control of traffic in a SDN or\n      NFV context) are also possible.  Other documents may specify Flow\n      Specification extensions.\n      \n      The information is carried via BGP, thereby reusing protocol\n      algorithms, operational experience, and administrative processes such\n      as inter-provider peering agreements.\n      \n      This document obsoletes both RFC5575 and RFC7674.\n\n  "Route Leak Prevention using Roles in Update and Open messages", Alexander\n  Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Kotikalapudi Sriram,\n  2020-01-09, <draft-ietf-idr-bgp-open-policy-07.txt>\n\n      Route leaks are the propagation of BGP prefixes which violate\n      assumptions of BGP topology relationships; e.g. passing a route\n      learned from one peer to another peer or to a transit provider,\n      passing a route learned from one transit provider to another transit\n      provider or to a peer.  Today, approaches to leak prevention rely on\n      marking routes by operator configuration, with no check that the\n      configuration corresponds to that of the BGP neighbor, or enforcement\n      that the two BGP speakers agree on the relationship.  This document\n      enhances BGP OPEN to establish agreement of the (peer, customer,\n      provider, Route Server, Route Server client) relationship of two\n      neighboring BGP speakers to enforce appropriate configuration on both\n      sides.  Propagated routes are then marked with an OTC attribute\n      according to the agreed relationship, allowing both prevention and\n      detection of route leaks.\n\n  "Signaling MSD (Maximum SID Depth) using Border Gateway Protocol\n  Link-State", Jeff Tantsura, Uma Chunduri, Ketan Talaulikar, Gregory Mirsky,\n  Nikos Triantafillis, 2019-10-15,\n  <draft-ietf-idr-bgp-ls-segment-routing-msd-09.txt>\n\n      This document defines a way for a Border Gateway Protocol Link-State\n      (BGP-LS) speaker to advertise multiple types of supported Maximum SID\n      Depths (MSDs) at node and/or link granularity.\n      \n      Such advertisements allow entities (e.g., centralized controllers) to\n      determine whether a particular Segment Identifier (SID) stack can be\n      supported in a given network.\n\n  "Advertising Segment Routing Policies in BGP", Stefano Previdi, Clarence\n  Filsfils, Ketan Talaulikar, Paul Mattes, Eric Rosen, Dhanendra Jain, Steven\n  Lin, 2019-11-18, <draft-ietf-idr-segment-routing-te-policy-08.txt>\n\n      This document defines a new BGP SAFI with a new NLRI in order to\n      advertise a candidate path of a Segment Routing (SR) Policy.  An SR\n      Policy is a set of candidate paths, each consisting of one or more\n      segment lists.  The headend of an SR Policy may learn multiple\n      candidate paths for an SR Policy.  Candidate paths may be learned via\n      a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP.\n      This document specifies the way in which BGP may be used to\n      distribute SR Policy candidate paths.  New sub-TLVs for the Tunnel\n      Encapsulation Attribute are defined for signaling information about\n      these candidate paths.\n\n  "Signalling ERLD using BGP-LS", Gunter Van de Velde, Wim Henderickx,\n  Matthew Bocci, Keyur Patel, 2019-08-20,\n  <draft-ietf-idr-bgp-ls-segment-routing-rld-05.txt>\n\n      This document defines the attribute encoding to use for BGP-LS to\n      expose ERLD "Entropy capable Readable Label Depth" from a node to a\n      centralised controller (PCE/SDN).\n\n  "Extended BGP Administrative Shutdown Communication", Job Snijders, Jakob\n  Heitz, John Scudder, Alexander Azimov, 2019-10-16,\n  <draft-ietf-idr-rfc8203bis-05.txt>\n\n      This document enhances the BGP Cease NOTIFICATION message\n      "Administrative Shutdown" and "Administrative Reset" subcodes for\n      operators to transmit a short freeform message to describe why a BGP\n      session was shutdown or reset.  This document updates RFC 4486 and\n      obsoletes RFC 8203 by defining an Extended BGP Administrative\n      Shutdown Communication to improve communication using multibyte\n      character sets.\n\n  "BGP-LS Extension for Inter-AS Topology Retrieval", Aijun Wang, Huaimo\n  Chen, Ketan Talaulikar, Shunwan Zhuang, Shaowen Ma, 2019-09-29,\n  <draft-ietf-idr-bgpls-inter-as-topology-ext-07.txt>\n\n      This document describes the process to build Border Gateway Protocol-\n      Link State (BGP-LS) key parameters in inter-domain scenario, defines\n      one new BGP-LS Network Layer Reachability Information (NLRI) type\n      (Stub Link NLRI) and some new inter Autonomous (inter-AS) Traffic\n      Engineering (TE) related Type-Length-Values (TLVs) for BGP-LS to let\n      Software Definition Network (SDN) controller retrieve the network\n      topology automatically under various inter-AS environments.\n      \n      Such extension and process can enable the network operator to collect\n      the interconnect information between different domains and then\n      calculate the overall network topology automatically based on the\n      information provided by BGP-LS protocol.\n\n  "Revision to Capability Codes Registration Procedures", John Scudder,\n  2019-10-15, <draft-ietf-idr-capabilities-registry-change-06.txt>\n\n      This document updates RFC 5492 by making a change to the registration\n      procedures for BGP Capability Codes.  Specifically, the range\n      formerly designated "Reserved for Private Use" is divided into three\n      new ranges, respectively designated as "First Come First Served",\n      "Experimental" and "Reserved".\n\n  "BGP Link State Extensions for SRv6", Gaurav Dawra, Clarence Filsfils,\n  Ketan Talaulikar, Mach Chen, daniel.bernier@bell.ca, Bruno Decraene,\n  2020-01-07, <draft-ietf-idr-bgpls-srv6-ext-02.txt>\n\n      Segment Routing IPv6 (SRv6) allows for a flexible definition of end-\n      to-end paths within various topologies by encoding paths as sequences\n      of topological or functional sub-paths, called "segments".  These\n      segments are advertised by the various protocols such as BGP, ISIS\n      and OSPFv3.\n      \n      BGP Link-state (BGP-LS) address-family solution for SRv6 is similar\n      to BGP-LS for SR for MPLS dataplane.  This draft defines extensions\n      to the BGP-LS to advertise SRv6 Segments along with their behaviors\n      and other attributes via BGP.\n\n  "Application Specific Attributes Advertisement with BGP Link-State", Ketan\n  Talaulikar, Peter Psenak, Jeff Tantsura, 2019-11-16,\n  <draft-ietf-idr-bgp-ls-app-specific-attr-01.txt>\n\n      Various link attributes have been defined in link-state routing\n      protocols like OSPF and IS-IS in the context of the MPLS Traffic\n      Engineering (TE) and GMPLS.  BGP Link-State (BGP-LS) extensions have\n      been defined to distribute these attributes along with other topology\n      information from these link-state routing protocols.  Many of these\n      link attributes can be used for applications other than MPLS TE or\n      GMPLS.\n      \n      Extensions to link-state routing protocols have been defined for such\n      link attributes which enable distribution of their application\n      specific values.  This document defines extensions to BGP-LS address-\n      family to enable advertisement of these application specific\n      attributes as a part of the topology information from the network.\n\n  "Flexible Algorithm Definition Advertisement with BGP Link-State", Ketan\n  Talaulikar, Peter Psenak, Shawn Zandi, Gaurav Dawra, 2020-01-06,\n  <draft-ietf-idr-bgp-ls-flex-algo-02.txt>\n\n      Flexible Algorithm is a solution that allows routing protocols (viz.\n      OSPF and IS-IS) to compute paths over a network based on user-defined\n      (and hence, flexible) constraints and metrics.  The computation is\n      performed by routers participating in the specific network in a\n      distribute manner using a Flex Algorithm definition.  This definition\n      provisioned on one or more routers and propagated (viz.  OSPF and IS-\n      IS flooding) through the network.\n      \n      BGP Link-State (BGP-LS) enables the collection of various topology\n      information from the network.  This draft defines extensions to BGP-\n      LS address-family to advertise the Flexible Algorithm Definition as a\n      part of the topology information from the network.\n\n  "BGP Link-State Extensions for Seamless BFD", Zhenbin Li, Shunwan Zhuang,\n  Ketan Talaulikar, Sam Aldrin, Jeff Tantsura, Gregory Mirsky, 2019-11-01,\n  <draft-ietf-idr-bgp-ls-sbfd-extensions-01.txt>\n\n      Seamless Bidirectional Forwarding Detection (S-BFD) defines a\n      simplified mechanism to use Bidirectional Forwarding Detection (BFD)\n      with large portions of negotiation aspects eliminated, thus providing\n      benefits such as quick provisioning as well as improved control and\n      flexibility to network nodes initiating the path monitoring.  The\n      link-state routing protocols (IS-IS and OSPF) have been extended to\n      advertise the Seamless BFD (S-BFD) Discriminators.\n      \n      This draft defines extensions to the BGP Link-state address-family to\n      carry the S-BFD Discriminators information via BGP.\n\n  "SR Policy Extensions for Path Segment and Bidirectional Path", Cheng Li,\n  China Telecom, Mach Chen, Jie Dong, Zhenbin Li, 2019-08-08,\n  <draft-li-idr-sr-policy-path-segment-01.txt>\n\n      A Segment Routing (SR) policy is a set of candidate SR paths\n      consisting of one or more segment lists with necessary path\n      attributes.  For each SR path, it may also have its own path\n      attributes, and Path Segment is one of them.  A Path Segment is\n      defined to identify an SR path, which can be used for performance\n      measurement, path correlation, and end-2-end path protection.  Path\n      Segment can be also used to correlate two unidirctional SR paths into\n      a bidirectional SR path which is required in some scenarios, for\n      example, mobile backhaul transport network.\n      \n      This document defines extensions to BGP to distribute SR policies\n      carrying Path Segment and bidirectional path information.\n\n  "Deprecation of AS_SET and AS_CONFED_SET in BGP", Warren Kumari,\n  Kotikalapudi Sriram, Lilia Hannachi, 2019-11-03,\n  <draft-ietf-idr-deprecate-as-set-confed-set-02.txt>\n\n      BCP 172 (i.e., RFC 6472) recommends not using AS_SET and\n      AS_CONFED_SET in the Border Gateway Protocol.  This document advances\n      this recommendation to a standards requirement in BGP; it proscribes\n      the use of the AS_SET and AS_CONFED_SET types of path segments in the\n      AS_PATH.  This is done to simplify the design and implementation of\n      BGP and to make the semantics of the originator of a route clearer.\n      This will also simplify the design, implementation, and deployment of\n      various BGP security mechanisms.  This document (if approved) updates\n      RFC 4271 and RFC 5065 by eliminating AS_SET and AS_CONFED_SET types,\n      and obsoletes RFC 6472.\n\n  "Support for Long-lived BGP Graceful Restart", Jim Uttaro, Enke Chen, Bruno\n  Decraene, John Scudder, 2019-09-05, <draft-ietf-idr-long-lived-gr-00.txt>\n\n      In this document we introduce a new BGP capability termed "Long-lived\n      Graceful Restart Capability" so that stale routes can be retained for\n      a longer time upon session failure.  A well-known BGP community\n      "LLGR_STALE" is introduced for marking stale routes retained for a\n      longer time.  A second well-known BGP community, "NO_LLGR", is\n      introduced to mark routes for which these procedures should not be\n      applied.  We also specify that such long-lived stale routes be\n      treated as the least-preferred, and their advertisements be limited\n      to BGP speakers that have advertised the new capability.  Use of this\n      extension is not advisable in all cases, and we provide guidelines to\n      help determine if it is.\n      \n      We update RFC 6368 by specifying that the LLGR_STALE community must\n      be propagated into, or out of, the path attributes exchanged between\n      PE and CE.\n\n  "Distribution of Link-State and Traffic Engineering Information Using BGP",\n  Ketan Talaulikar, 2019-11-01, <draft-ietf-idr-rfc7752bis-02.txt>\n\n      In a number of environments, a component external to a network is\n      called upon to perform computations based on the network topology and\n      current state of the connections within the network, including\n      Traffic Engineering (TE) information.  This is information typically\n      distributed by IGP routing protocols within the network.\n      \n      This document describes a mechanism by which link-state and TE\n      information can be collected from networks and shared with external\n      components using the BGP routing protocol.  This is achieved using a\n      new BGP Network Layer Reachability Information (NLRI) encoding\n      format.  The mechanism is applicable to physical and virtual IGP\n      links.  The mechanism described is subject to policy control.\n      \n      Applications of this technique include Application-Layer Traffic\n      Optimization (ALTO) servers and Path Computation Elements (PCEs).\n      \n      This document obsoletes RFC 7752 by completely replacing that\n      document.  It makes a number of small changes and clarifications to\n      the previous specification.\n\n  "BGP BFD Strict-Mode", Mercia Zheng, Acee Lindem, Jeffrey Haas, Albert Fu,\n  2019-11-04, <draft-ietf-idr-bgp-bfd-strict-mode-02.txt>\n\n      This document specifies extensions to RFC4271 BGP-4 that enable a BGP\n      speaker to negotiate additional Bidirectional Forwarding Detection\n      (BFD) extensions using a BGP capability.  This BFD capability enables\n      a BGP speaker to prevent a BGP session from being established until a\n      BFD session is established.  It is referred to as BGP BFD "strict-\n      mode".  BGP BFD strict-mode will be supported when both the local\n      speaker and its remote peer are BFD strict-mode capable.\n\n  "SR Policy Extensions for Path Segment and Bidirectional Path", Cheng Li,\n  Zhenbin Li, China Telecom, Weiqiang Cheng, Ketan Talaulikar, 2019-10-28,\n  <draft-ietf-idr-sr-policy-path-segment-00.txt>\n\n      A Segment Routing (SR) policy is a set of candidate SR paths\n      consisting of one or more segment lists with necessary path\n      attributes.  For each SR path, it may also have its own path\n      attributes, and Path Segment is one of them.  A Path Segment is\n      defined to identify an SR path, which can be used for performance\n      measurement, path correlation, and end-2-end path protection.  Path\n      Segment can be also used to correlate two unidirctional SR paths into\n      a bidirectional SR path which is required in some scenarios, for\n      example, mobile backhaul transport network.\n      \n      This document defines extensions to BGP to distribute SR policies\n      carrying Path Segment and bidirectional path information.\n\n  "BGP Extensions for Routing Policy Distribution (RPD)", Zhenbin Li, Liang\n  Ou, Yujia Luo, Sujian Lu, Huaimo Chen, Shunwan Zhuang, Haibo Wang,\n  2019-11-01, <draft-ietf-idr-rpd-00.txt>\n\n      It is hard to adjust traffic and optimize traffic paths on a\n      traditional IP network from time to time through manual\n      configurations.  It is desirable to have an automatic mechanism for\n      setting up routing policies, which adjust traffic and optimize\n      traffic paths automatically.  This document describes BGP Extensions\n      for Routing Policy Distribution (BGP RPD) to support this.\n\n  "SR Policies Extensions for Path Segment and Bidirectional Path in BGP-LS",\n  Cheng Li, Zhenbin Li, China Telecom, Weiqiang Cheng, Ketan Talaulikar,\n  2019-11-01, <draft-ietf-idr-bgp-ls-sr-policy-path-segment-00.txt>\n\n      This document specifies the way of collecting configuration and\n      states of SR policies carrying Path Segment and bidirectional path\n      information by using BPG-LS.  Such information can be used by\n      external conponents for many use cases such as performance\n      measurement, path re-optimization and end-to-end protection.\n\n  "Updates to the Allocation Policy for the Border Gateway Protocol - Link\n  State (BGP-LS) Parameters Registries", Adrian Farrel, 2019-11-19,\n  <draft-ietf-idr-bgp-ls-registry-00.txt>\n\n      RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS).  IANA\n      created a registry consistent with that document called the "Border\n      Gateway Protocol - Link State (BGP-LS) Parameters Registry" with a\n      number of sub-registries.  The allocation policy applied by IANA for\n      those policies is "Specification Required" as defined in RFC 8126.\n      \n      This document updates RFC 7752 by changing the allocation policy for\n      all of the registries to "Expert Review" and by updating the guidance\n      to the Designated Experts.\n\nInternet Area (int)\n-------------------\n\n  "Guidelines and Registration Procedures for Interface Types and Tunnel\n  Types", Dave Thaler, Dan Romascanu, 2020-01-16,\n  <draft-thaler-iftype-reg-07.txt>\n\n      This document provides guidelines and procedures for those who are\n      defining, registering, or evaluating definitions of new interface\n      types ("ifType" values) and tunnel types.  The original definition of\n      the IANA interface type registry predated the use of IANA\n      Considerations sections and YANG modules, and so some confusion arose\n      over time.  Tunnel types were added later, with the same requirements\n      and allocation policy as interface types.  This document updates RFC\n      2863, and provides updated guidance for these registries.\n\nInternet Area Working Group (intarea)\n-------------------------------------\n\n  "IP Tunnels in the Internet Architecture", Joseph Touch, Mark Townsley,\n  2019-09-12, <draft-ietf-intarea-tunnels-10.txt>\n\n      This document discusses the role of IP tunnels in the Internet\n      architecture. An IP tunnel transits IP datagrams as payloads in non-\n      link layer protocols. This document explains the relationship of IP\n      tunnels to existing protocol layers and the challenges in supporting\n      IP tunneling, based on the equivalence of tunnels to links. The\n      implications of this document are used to derive recommendations that\n      update MTU and fragment issues in RFC 4459.\n\n  "Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Osama Zia, 2019-10-26,\n  <draft-ietf-intarea-gue-09.txt>\n\n      This specification describes Generic UDP Encapsulation (GUE), which\n      is a scheme for using UDP to encapsulate packets of different IP\n      protocols for transport across layer 3 networks. By encapsulating\n      packets in UDP, specialized capabilities in networking hardware for\n      efficient handling of UDP packets can be leveraged. GUE specifies\n      basic encapsulation methods upon which higher level constructs, such\n      as tunnels and overlay networks for network virtualization, can be\n      constructed. GUE is extensible by allowing optional data fields as\n      part of the encapsulation, and is generic in that it can encapsulate\n      packets of various IP protocols.\n\n  "Discovering Provisioning Domain Names and Data", Pierre Pfister, Eric\n  Vyncke, Tommy Pauly, David Schinazi, Wenqin Shao, 2020-01-06,\n  <draft-ietf-intarea-provisioning-domains-10.txt>\n\n      Provisioning Domains (PvDs) are defined as consistent sets of network\n      configuration information.  This allows hosts to manage connections\n      to multiple networks and interfaces simultaneously, such as when a\n      home router provides connectivity through both a broadband and\n      cellular network provider.\n      \n      This document defines a mechanism for explicitly identifying PvDs\n      through a Router Advertisement (RA) option.  This RA option announces\n      a PvD identifier, which hosts can compare to differentiate between\n      PvDs.  The option can directly carry some information about a PvD and\n      can optionally point to additional PvD information that can be\n      retrieved using HTTP over TLS.\n\n  "IP Fragmentation Considered Fragile", Ron Bonica, Fred Baker, Geoff\n  Huston, Robert Hinden, Ole Troan, Fernando Gont, 2019-09-30,\n  <draft-ietf-intarea-frag-fragile-17.txt>\n\n      This document describes IP fragmentation and explains how it\n      introduces fragility to Internet communication.\n      \n      This document also proposes alternatives to IP fragmentation and\n      provides recommendations for developers and network operators.\n\nIP Performance Measurement (ippm)\n---------------------------------\n\n  "Registry for Performance Metrics", Marcelo Bagnulo, Benoit Claise, Philip\n  Eardley, Alfred Morton, Aamer Akhter, 2019-12-11,\n  <draft-ietf-ippm-metric-registry-23.txt>\n\n      This document defines the format for the IANA Performance Metrics\n      Registry.  This document also gives a set of guidelines for\n      Registered Performance Metric requesters and reviewers.\n\n  "Initial Performance Metrics Registry Entries", Alfred Morton, Marcelo\n  Bagnulo, Philip Eardley, Kevin D\'Souza, 2019-12-11,\n  <draft-ietf-ippm-initial-registry-15.txt>\n\n      This memo defines the set of Initial Entries for the IANA Performance\n      Metrics Registry.  The set includes: UDP Round-trip Latency and Loss,\n      Packet Delay Variation, DNS Response Latency and Loss, UDP Poisson\n      One-way Delay and Loss, UDP Periodic One-way Delay and Loss, ICMP\n      Round-trip Latency and Loss, and TCP round-trip Latency and Loss.\n\n  "Two-Way Active Measurement Protocol (TWAMP) Data Model", Ruth Civil,\n  Alfred Morton, Reshad Rahman, Mahesh Jethanandani, Kostas Pentikousis,\n  2018-07-02, <draft-ietf-ippm-twamp-yang-13.txt>\n\n      This document specifies a data model for client and server\n      implementations of the Two-Way Active Measurement Protocol (TWAMP).\n      The document defines the TWAMP data model through Unified Modeling\n      Language (UML) class diagrams and formally specifies it using a NDMA-\n      compliant YANG model.\n\n  "Data Fields for In-situ OAM", Frank Brockners, Shwetha Bhandari, Carlos\n  Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, David\n  Mozes, Petr Lapukhov, remy@barefootnetworks.com, daniel.bernier@bell.ca,\n  Jennifer Lemon, 2019-10-24, <draft-ietf-ippm-ioam-data-08.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in the packet while the packet\n      traverses a path between two points in the network.  This document\n      discusses the data fields and associated data types for in-situ OAM.\n      In-situ OAM data fields can be embedded into a variety of transports\n      such as NSH, Segment Routing, Geneve, native IPv6 (via extension\n      header), or IPv4.  In-situ OAM can be used to complement OAM\n      mechanisms based on e.g.  ICMP or other types of probe packets.\n\n  "Simple Two-way Active Measurement Protocol", Gregory Mirsky, Guo Jun,\n  Henrik Nydell, Richard Foote, 2019-10-31, <draft-ietf-ippm-stamp-10.txt>\n\n      This document describes a Simple Two-way Active Measurement Protocol\n      which enables the measurement of both one-way and round-trip\n      performance metrics like delay, delay variation, and packet loss.\n\n  "Simple Two-way Active Measurement Protocol (STAMP) Data Model", Gregory\n  Mirsky, Min Xiao, Wei Luo, 2019-10-25, <draft-ietf-ippm-stamp-yang-05.txt>\n\n      This document specifies the data model for implementations of\n      Session-Sender and Session-Reflector for Simple Two-way Active\n      Measurement Protocol (STAMP) mode using YANG.\n\n  "Advanced Unidirectional Route Assessment (AURA)", Jose Alvarez-Hamelin,\n  Alfred Morton, Joachim Fabini, Carlos Pignataro, Ruediger Geib, 2019-12-11,\n  <draft-ietf-ippm-route-07.txt>\n\n      This memo introduces an advanced unidirectional route assessment\n      (AURA) metric and associated measurement methodology, based on the IP\n      Performance Metrics (IPPM) Framework RFC 2330.  This memo updates RFC\n      2330 in the areas of path-related terminology and path description,\n      primarily to include the possibility of parallel subpaths between a\n      given Source and Destination pair, owing to the presence of multi-\n      path technologies.\n\n  "Multipoint Alternate Marking method for passive and hybrid performance\n  monitoring", Giuseppe Fioccola, Mauro Cociglio, Amedeo Sapio, Riccardo\n  Sisto, 2020-01-07, <draft-ietf-ippm-multipoint-alt-mark-04.txt>\n\n      The Alternate Marking method, as presented in RFC 8321 [RFC8321], can\n      be applied only to point-to-point flows because it assumes that all\n      the packets of the flow measured on one node are measured again by a\n      single second node.  This document aims to generalize and expand this\n      methodology to measure any kind of unicast flows, whose packets can\n      follow several different paths in the network, in wider terms a\n      multipoint-to-multipoint network.  For this reason the technique here\n      described is called Multipoint Alternate Marking.  Some definitions\n      here introduced extend the scope of RFC 5644 [RFC5644] in the context\n      of alternate marking schema.\n\n  "Simple Two-way Active Measurement Protocol Optional Extensions", Gregory\n  Mirsky, Min Xiao, Henrik Nydell, Richard Foote, Adi Masputra, Ernesto\n  Ruffini, 2019-10-31, <draft-ietf-ippm-stamp-option-tlv-02.txt>\n\n      This document describes optional extensions to Simple Two-way Active\n      Measurement Protocol (STAMP) which enable measurement performance\n      metrics in addition to ones supported by the STAMP base\n      specification.\n\n  "In-situ OAM IPv6 Options", Shwetha Bhandari, Frank Brockners, Carlos\n  Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Aviv\n  Kfir, Barak Gafni, Petr Lapukhov, Mickey Spiegel, Suresh Krishnan, Rajiv\n  Asati, 2019-09-26, <draft-ietf-ippm-ioam-ipv6-options-00.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in the packet while the packet\n      traverses a path between two points in the network.  This document\n      outlines how IOAM data fields are encapsulated in IPv6.\n\n  "In-situ OAM Direct Exporting", Haoyu Song, Barak Gafni, Tianran Zhou,\n  Zhenbin Li, Frank Brockners, Shwetha Bhandari, Ramesh Sivakolundu, Tal\n  Mizrahi, 2019-10-12, <draft-ioamteam-ippm-ioam-direct-export-00.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) is used\n      for recording and collecting operational and telemetry information.\n      Specifically, IOAM allows telemetry data to be pushed into data\n      packets while they traverse the network.  This document introduces a\n      new IOAM option type called the Direct Export (DEX) option, which is\n      used as a trigger for IOAM data to be directly exported to a\n      collector without being pushed into in-flight data packets.\n\n  "In-situ OAM Flags", Tal Mizrahi, Frank Brockners, Shwetha Bhandari, Ramesh\n  Sivakolundu, Carlos Pignataro, Aviv Kfir, Barak Gafni, Mickey Spiegel,\n  Jennifer Lemon, 2020-01-26, <draft-ietf-ippm-ioam-flags-01.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in the packet while the packet\n      traverses a path between two points in the network.  This document\n      presents new flags in the IOAM Trace Option headers.  Specifically,\n      the document defines the Loopback and Active flags.\n\n  "Metrics and Methods for IP Capacity", Alfred Morton, Ruediger Geib, Len\n  Ciavattone, 2019-11-04, <draft-morton-ippm-capacity-metric-method-01.txt>\n\n      This memo revisits the problem of Network Capacity metrics first\n      examined in RFC 5136.  The memo specifies a more practical Maximum\n      IP-layer Capacity metric definition catering for measurement\n      purposes, and outlines the corresponding methods of measurement.\n\nIP Security Maintenance and Extensions (ipsecme)\n------------------------------------------------\n\n  "Mixing Preshared Keys in IKEv2 for Post-quantum Security", Scott Fluhrer,\n  Panos Kampanakis, David McGrew, Valery Smyslov, 2020-01-14,\n  <draft-ietf-ipsecme-qr-ikev2-11.txt>\n\n      The possibility of quantum computers poses a serious challenge to\n      cryptographic algorithms deployed widely today.  IKEv2 is one example\n      of a cryptosystem that could be broken; someone storing VPN\n      communications today could decrypt them at a later time when a\n      quantum computer is available.  It is anticipated that IKEv2 will be\n      extended to support quantum-secure key exchange algorithms; however\n      that is not likely to happen in the near term.  To address this\n      problem before then, this document describes an extension of IKEv2 to\n      allow it to be resistant to a quantum computer, by using preshared\n      keys.\n\n  "Implicit IV for Counter-based Ciphers in Encapsulating Security Payload\n  (ESP)", Daniel Migault, Tobias Guggemos, Yoav Nir, 2019-10-22,\n  <draft-ietf-ipsecme-implicit-iv-11.txt>\n\n      Encapsulating Security Payload (ESP) sends an initialization vector\n      (IV) in each packet.  The size of IV depends on the applied\n      transform, being usually 8 or 16 octets for the transforms defined by\n      the time this document is written.  Some algorithms such as AES-GCM,\n      AES-CCM and ChaCha20-Poly1305 when used with IPsec, take the IV to\n      generate a nonce that is used as an input parameter for encrypting\n      and decrypting.  This IV must be unique but can be predictable.  As a\n      result, the value provided in the ESP Sequence Number (SN) can be\n      used instead to generate the nonce.  This avoids sending the IV\n      itself, and saves in the case of AES-GCM, AES-CCM and\n      ChaCha20-Poly1305 8 octets per packet.  This document describes how\n      to do this.\n\n  "IKEv2 Notification Status Types for IPv4/IPv6 Coexistence", Mohamed\n  Boucadair, 2019-10-21, <draft-ietf-ipsecme-ipv6-ipv4-codes-04.txt>\n\n      This document specifies new IKEv2 notification status types to better\n      manage IPv4 and IPv6 co-existence.\n      \n      This document updates RFC7296.\n\n  "Labeled IPsec Traffic Selector support for IKEv2", Paul Wouters, Sahana\n  Prasad, 2019-11-04, <draft-ietf-ipsecme-labeled-ipsec-02.txt>\n\n      This document defines a new Traffic Selector (TS) Type for Internet\n      Key Exchange version 2 to add support for negotiating Mandatory\n      Access Control (MAC) security labels as a traffic selector of the\n      Security Policy Database (SPD).  Security Labels for IPsec are also\n      known as "Labeled IPsec".  The new TS type is TS_SECLABEL, which\n      consists of a variable length opaque field specifying the security\n      label.  This document updates the IKEv2 TS negotiation specified in\n      RFC 7296 Section 2.9.\n\n  "Intermediate Exchange in the IKEv2 Protocol", Valery Smyslov, 2019-12-16,\n  <draft-ietf-ipsecme-ikev2-intermediate-03.txt>\n\n      This documents defines a new exchange, called Intermediate Exchange,\n      for the Internet Key Exchange protocol Version 2 (IKEv2).  This\n      exchange can be used for transferring large amount of data in the\n      process of IKEv2 Security Association (SA) establishment.\n      Introducing Intermediate Exchange allows re-using existing IKE\n      Fragmentation mechanism, that helps to avoid IP fragmentation of\n      large IKE messages, but cannot be used in the initial IKEv2 exchange.\n\n  "IP Traffic Flow Security", Christian Hopps, 2019-12-16,\n  <draft-ietf-ipsecme-iptfs-00.txt>\n\n      This document describes a mechanism to enhance IPsec traffic flow\n      security by adding traffic flow confidentiality to encrypted IP\n      encapsulated traffic.  Traffic flow confidentiality is provided by\n      obscuring the size and frequency of IP traffic using a fixed-sized,\n      constant-send-rate IPsec tunnel.  The solution allows for congestion\n      control as well.\n\n  "Group Key Management using IKEv2", Brian Weis, Valery Smyslov, 2020-01-08,\n  <draft-ietf-ipsecme-g-ikev2-00.txt>\n\n      This document presents a set of IKEv2 exchanges that comprise a group\n      key management protocol.  The protocol is in conformance with the\n      Multicast Security (MSEC) key management architecture, which contains\n      two components: member registration and group rekeying.  Both\n      components require a Group Controller/Key Server to download IPsec\n      group security associations to authorized members of a group.  The\n      group members then exchange IP multicast or other group traffic as\n      IPsec packets.  This document obsoletes RFC 6407.\n\n  "Multiple Key Exchanges in IKEv2", C. Tjhai, M. Tomlinson,\n  grbartle@cisco.com, Scott Fluhrer, Daniel Van Geest, Oscar Garcia-Morchon,\n  Valery Smyslov, 2020-01-10, <draft-ietf-ipsecme-ikev2-multiple-ke-00.txt>\n\n      This document describes how to extend the Internet Key Exchange\n      Protocol Version 2 (IKEv2) to allow multiple key exchanges to take\n      place while computing of a shared secret during a Security\n      Association (SA) setup.  The primary application of this feature in\n      IKEv2 is the ability to perform one or more post-quantum key\n      exchanges in conjunction with the classical (Elliptic Curve) Diffie-\n      Hellman key exchange, so that the resulting shared key is resistant\n      against quantum computer attacks.  Another possible application is\n      the ability to combine several key exchanges in situations when no\n      single key exchange algorithm is trusted by both initiator and\n      responder.\n      \n      This document updates RFC7296 by renaming a tranform type 4 from\n      "Diffie-Hellman Group (D-H)" to "Key Exchange Method (KE)" and\n      renaming a field in the Key Exchange Payload from "Diffie-Hellman\n      Group Num" to "Key Exchange Method".  It also renames an IANA\n      registry for this transform type from "Transform Type 4 - Diffie-\n      Hellman Group Transform IDs" to "Transform Type 4 - Key Exchange\n      Method Transform IDs".  These changes generalize key exchange\n      algorithms that can be used in IKEv2.\n\nIP Wireless Access in Vehicular Environments (ipwave)\n-----------------------------------------------------\n\n  "IPv6 Wireless Access in Vehicular Environments (IPWAVE): Problem Statement\n  and Use Cases", Jaehoon Jeong, 2020-01-06,\n  <draft-ietf-ipwave-vehicular-networking-13.txt>\n\n      This document discusses the problem statement and use cases of\n      IPv6-based vehicular networking for Intelligent Transportation\n      Systems (ITS).  The main scenarios of vehicular communications are\n      vehicle-to-vehicle (V2V), vehicle-to-infrastructure (V2I), and\n      vehicle-to-everything (V2X) communications.  First, this document\n      explains use cases using V2V, V2I, and V2X networking.  Next, it\n      makes a problem statement about key aspects in IPv6-based vehicular\n      networking, such as IPv6 Neighbor Discovery, Mobility Management, and\n      Security & Privacy.  For each key aspect, this document specifies\n      requirements for IPv6-based vehicular networking.\n\nJSON Mail Access Protocol (jmap)\n--------------------------------\n\n  "Handling Message Disposition Notification with JMAP", Raphael Ouazana,\n  2019-12-16, <draft-ietf-jmap-mdn-04.txt>\n\n      This document specifies a data model for handling [RFC8098] MDN\n      messages with a server using JMAP.\n\n  "A JSON Meta Application Protocol (JMAP) Subprotocol for WebSocket", Ken\n  Murchison, 2019-11-17, <draft-ietf-jmap-websocket-04.txt>\n\n      This document defines a binding for the JSON Meta Application\n      Protocol (JMAP) over a WebSocket transport layer.  The WebSocket\n      binding for JMAP provides higher performance than the current HTTP\n      binding for JMAP.\n\n  "JMAP for Calendars", Neil Jenkins, Michael Douglass, 2019-10-28,\n  <draft-ietf-jmap-calendars-01.txt>\n\n      This document specifies a data model for synchronizing calendar data\n      with a server using JMAP.\n\n  "JMAP for Quotas", Rene Cordier, Michael Bailly, 2019-09-30,\n  <draft-ietf-jmap-quotas-00.txt>\n\n      This document specifies a data model for handling quotas on mailboxes\n      with a server using JMAP.\n\nCommon Authentication Technology Next Generation (kitten)\n---------------------------------------------------------\n\n  "SAML Enhanced Client SASL and GSS-API Mechanisms", Scott Cantor, Simon\n  Josefsson, 2019-08-28, <draft-ietf-kitten-sasl-saml-ec-19.txt>\n\n      Security Assertion Markup Language (SAML) 2.0 is a generalized\n      framework for the exchange of security-related information between\n      asserting and relying parties.  Simple Authentication and Security\n      Layer (SASL) and the Generic Security Service Application Program\n      Interface (GSS-API) are application frameworks to facilitate an\n      extensible authentication model.  This document specifies a SASL and\n      GSS-API mechanism for SAML 2.0 that leverages the capabilities of a\n      SAML-aware "enhanced client" to address significant barriers to\n      federated authentication in a manner that encourages reuse of\n      existing SAML bindings and profiles designed for non-browser\n      scenarios.\n\n  "SPAKE Pre-Authentication", Nathaniel McCallum, Simo Sorce, Robbie Harwood,\n  Greg Hudson, 2018-08-21, <draft-ietf-kitten-krb-spake-preauth-06.txt>\n\n      This document defines a new pre-authentication mechanism for the\n      Kerberos protocol that uses a password authenticated key exchange.\n      This document has three goals.  First, increase the security of\n      Kerberos pre-authentication exchanges by making offline brute-force\n      attacks infeasible.  Second, enable the use of second factor\n      authentication without relying on FAST.  This is achieved using the\n      existing trust relationship established by the shared first factor.\n      Third, make Kerberos pre-authentication more resilient against time\n      synchronization errors by removing the need to transfer an encrypted\n      timestamp from the client.\n\nLightweight Authenticated Key Exchange (lake)\n---------------------------------------------\n\n  "Requirements for a Lightweight AKE for OSCORE", Malisa Vucinic, Goeran\n  Selander, John Mattsson, Dan Garcia-Carillo, 2019-12-09,\n  <draft-ietf-lake-reqs-00.txt>\n\n      This document compiles the requirements for a lightweight\n      authenticated key exchange protocol for OSCORE.\n\nLimited Additional Mechanisms for PKIX and SMIME (lamps)\n--------------------------------------------------------\n\n  "Use of the SHAKE One-way Hash Functions in the Cryptographic Message\n  Syntax (CMS)", Panos Kampanakis, Quynh Dang, 2019-09-17,\n  <draft-ietf-lamps-cms-shakes-18.txt>\n\n      This document updates the "Cryptographic Message Syntax Algorithms"\n      (RFC3370) and describes the conventions for using the SHAKE family of\n      hash functions in the Cryptographic Message Syntax as one-way hash\n      functions with the RSA Probabilistic signature and ECDSA signature\n      algorithms.  The conventions for the associated signer public keys in\n      CMS are also described.\n\n  "Use of the HSS/LMS Hash-based Signature Algorithm in the Cryptographic\n  Message Syntax (CMS)", Russ Housley, 2019-09-18,\n  <draft-ietf-lamps-cms-hash-sig-10.txt>\n\n      This document specifies the conventions for using the Hierarchical\n      Signature System (HSS) / Leighton-Micali Signature (LMS) hash-based\n      signature algorithm with the Cryptographic Message Syntax (CMS).  In\n      addition, the algorithm identifier and public key syntax are\n      provided.  The HSS/LMS algorithm is one form of hash-based digital\n      signature; it is described in RFC 8554.\n\n  "Problem Statement and Requirements for Header Protection", Alexey\n  Melnikov, Bernie Hoeneisen, 2019-10-29,\n  <draft-ietf-lamps-header-protection-requirements-01.txt>\n\n      Privacy and security issues with email header protection in S/MIME\n      have been identified for some time.  However, the desire to fix these\n      issues has only recently been expressed in the IETF LAMPS Working\n      Group.  The existing S/MIME specification is likely to be updated\n      regarding header protection.\n      \n      This document describes the problem statement, generic use cases, and\n      requirements of header protection.\n\n  "Clarification of Enrollment over Secure Transport (EST): transfer\n  encodings and ASN.1", Michael Richardson, Thomas Werner, Wei Pan,\n  2020-01-03, <draft-ietf-lamps-rfc7030est-clarify-00.txt>\n\n      This document updates RFC7030: Enrollment over Secure Transport (EST)\n      to resolve some errata that was reported, and which has proven to\n      have interoperability when RFC7030 has been extended.\n      \n      This document deprecates the specification of "Content-Transfer-\n      Encoding" headers for EST endpoints, providing a way to do this in an\n      upward compatible way.  This document fixes some syntactical errors\n      in ASN.1 that was presented.\n\n  "Clarifications for Elliptic Curve Cryptogtaphy Subject Public Key\n  Information", Tadahiko Ito, Sean Turner, 2020-01-08,\n  <draft-ietf-lamps-5480-ku-clarifications-00.txt>\n\n      This document updates RFC 5480 to specify semantics for the\n      keyEncipherment and dataEncipherment key usage bits when used in\n      certificates that support Elliptic Curve Cryptography.\n\n  "Update to the Cryptographic Message Syntax (CMS) for Algorithm Identifier\n  Protection", Russ Housley, 2020-01-22,\n  <draft-ietf-lamps-cms-update-alg-id-protect-00.txt>\n\n      This document updates the Cryptographic Message Syntax (CMS)\n      specified in RFC 5652 to ensure that algorithm identifiers are\n      adequately protected.\n\nLocator/ID Separation Protocol (lisp)\n-------------------------------------\n\n  "LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert\n  Cabellos-Aparicio, Damien Saucez, 2020-01-13, <draft-ietf-lisp-sec-20.txt>\n\n      This memo specifies LISP-SEC, a set of security mechanisms that\n      provides origin authentication, integrity and anti-replay protection\n      to LISP\'s EID-to-RLOC mapping data conveyed via mapping lookup\n      process.  LISP-SEC also enables verification of authorization on EID-\n      prefix claims in Map-Reply messages.\n\n  "An Architectural Introduction to the Locator/ID Separation Protocol\n  (LISP)", Albert Cabellos-Aparicio, Damien Saucez, 2015-04-02,\n  <draft-ietf-lisp-introduction-13.txt>\n\n      This document describes the architecture of the Locator/ID Separation\n      Protocol (LISP), making it easier to read the rest of the LISP\n      specifications and providing a basis for discussion about the details\n      of the LISP protocols.  This document is used for introductory\n      purposes, more details can be found in RFC6830, the protocol\n      specification.\n\n  "LISP YANG Model", Vina Ermagan, Alberto Rodriguez-Natal, Florin Coras,\n  Carl Moberg, Reshad Rahman, Albert Cabellos-Aparicio, Fabio Maino,\n  2019-09-07, <draft-ietf-lisp-yang-12.txt>\n\n      This document describes a YANG data model to use with the Locator/ID\n      Separation Protocol (LISP).\n      \n      The YANG modules in this document conform to the Network Management\n      Datastore Architecture (NMDA).\n\n  "The Locator/ID Separation Protocol (LISP)", Dino Farinacci, Vince Fuller,\n  David Meyer, Darrel Lewis, Albert Cabellos-Aparicio, 2020-01-13,\n  <draft-ietf-lisp-rfc6830bis-30.txt>\n\n      This document describes the Data-Plane protocol for the Locator/ID\n      Separation Protocol (LISP).  LISP defines two namespaces, End-point\n      Identifiers (EIDs) that identify end-hosts and Routing Locators\n      (RLOCs) that identify network attachment points.  With this, LISP\n      effectively separates control from data, and allows routers to create\n      overlay networks.  LISP-capable routers exchange encapsulated packets\n      according to EID-to-RLOC mappings stored in a local Map-Cache.\n      \n      LISP requires no change to either host protocol stacks or to underlay\n      routers and offers Traffic Engineering, multihoming and mobility,\n      among other features.\n      \n      This document obsoletes RFC 6830.\n\n  "Locator/ID Separation Protocol (LISP) Control-Plane", Dino Farinacci,\n  Fabio Maino, Vince Fuller, Albert Cabellos-Aparicio, 2020-01-09,\n  <draft-ietf-lisp-rfc6833bis-27.txt>\n\n      This document describes the Control-Plane and Mapping Service for the\n      Locator/ID Separation Protocol (LISP), implemented by two types of\n      LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server --\n      that provides a simplified "front end" for one or more Endpoint ID to\n      Routing Locator mapping databases.\n      \n      By using this Control-Plane service interface and communicating with\n      Map-Resolvers and Map-Servers, LISP Ingress Tunnel Routers (ITRs) and\n      Egress Tunnel Routers (ETRs) are not dependent on the details of\n      mapping database systems, which facilitates modularity with different\n      database designs.  Since these devices implement the "edge" of the\n      LISP Control-Plane infrastructure, connecting EID addressable nodes\n      of a LISP site, their implementation and operational complexity\n      reduces the overall cost and effort of deploying LISP.\n      \n      This document obsoletes RFC 6830 and RFC 6833.\n\n  "LISP Traffic Engineering Use-Cases", Dino Farinacci, Michael Kowal,\n  Parantap Lahiri, 2019-10-07, <draft-ietf-lisp-te-05.txt>\n\n      This document describes how LISP reencapsulating tunnels can be used\n      for Traffic Engineering purposes.  The mechanisms described in this\n      document require no LISP protocol changes but do introduce a new\n      locator (RLOC) encoding.  The Traffic Engineering features provided\n      by these LISP mechanisms can span intra-domain, inter-domain, or\n      combination of both.\n\n  "LISP Mobile Node", Dino Farinacci, Darrel Lewis, David Meyer, Chris White,\n  2019-09-03, <draft-ietf-lisp-mn-06.txt>\n\n      This document describes how a lightweight version of LISP\'s ITR/ETR\n      functionality can be used to provide seamless mobility to a mobile\n      node.  The LISP Mobile Node design described in this document uses\n      standard LISP functionality to provide scalable mobility for LISP\n      mobile nodes.\n\n  "LISP Virtual Private Networks (VPNs)", Victor Moreno, Dino Farinacci,\n  2019-11-17, <draft-ietf-lisp-vpn-05.txt>\n\n      This document describes the use of the Locator/ID Separation Protocol\n      (LISP) to create Virtual Private Networks (VPNs).  LISP is used to\n      provide segmentation in both the LISP data plane and control plane.\n      These VPNs can be created over the top of the Internet or over\n      private transport networks, and can be implemented by Enterprises or\n      Service Providers.  The goal of these VPNs is to leverage the\n      characteristics of LISP - routing scalability, simply expressed\n      Ingress site TE Policy, IP Address Family traversal, and mobility, in\n      ways that provide value to network operators.\n\n  "LISP L2/L3 EID Mobility Using a Unified Control Plane", Marc\n  Portoles-Comeras, Vrushali Ashtaputre, Victor Moreno, Fabio Maino, Dino\n  Farinacci, 2019-11-17, <draft-ietf-lisp-eid-mobility-05.txt>\n\n      The LISP control plane offers the flexibility to support multiple\n      overlay flavors simultaneously.  This document specifies how LISP can\n      be used to provide control-plane support to deploy a unified L2 and\n      L3 overlay solution for End-point Identifier (EID) mobility, as well\n      as analyzing possible deployment options and models.\n\n  "LISP Predictive RLOCs", Dino Farinacci, Padma Pillay-Esnault, 2019-11-04,\n  <draft-ietf-lisp-predictive-rlocs-05.txt>\n\n      This specification describes a method to achieve near-zero packet\n      loss when an EID is roaming quickly across RLOCs.\n\n  "LISP EID Anonymity", Dino Farinacci, Padma Pillay-Esnault, Wassim Haddad,\n  2019-10-07, <draft-ietf-lisp-eid-anonymity-07.txt>\n\n      This specification will describe how ephemeral LISP EIDs can be used\n      to create source anonymity.  The idea makes use of frequently\n      changing EIDs much like how a credit-card system uses a different\n      credit-card numbers for each transaction.\n\n  "Vendor Specific LISP Canonical Address Format (LCAF)", Alberto\n  Rodriguez-Natal, Vina Ermagan, Anton Smirnov, Vrushali Ashtaputre, Dino\n  Farinacci, 2019-09-30, <draft-ietf-lisp-vendor-lcaf-05.txt>\n\n      This document describes a new LISP Canonical Address Format (LCAF),\n      the Vendor Specific LCAF.  This LCAF enables organizations to have\n      internal encodings for LCAF addresses.\n\n  "LISP Generic Protocol Extension", Fabio Maino, Jennifer Lemon, Puneet\n  Agarwal, Darrel Lewis, Michael Smith, 2020-01-08,\n  <draft-ietf-lisp-gpe-14.txt>\n\n      This document describes extentions to the Locator/ID Separation\n      Protocol (LISP) Data-Plane, via changes to the LISP header, to\n      support multi-protocol encapsulation.\n\n  "Publish/Subscribe Functionality for LISP", Alberto Rodriguez-Natal, Vina\n  Ermagan, Johnson Leong, Fabio Maino, Albert Cabellos-Aparicio, Sharon\n  Barkai, Dino Farinacci, Mohamed Boucadair, Christian Jacquenet, Stefano\n  Secci, 2019-09-11, <draft-ietf-lisp-pubsub-04.txt>\n\n      This document specifies an extension to the use of Map-Request to\n      enable Publish/Subscribe (PubSub) operation for LISP.\n\n  "Locator/ID Separation Protocol (LISP) Map-Versioning", Luigi Iannone,\n  Damien Saucez, Olivier Bonaventure, 2019-08-16,\n  <draft-ietf-lisp-6834bis-04.txt>\n\n      This document describes the LISP (Locator/ID Separation Protocol)\n      Map-Versioning mechanism, which provides in-packet information about\n      Endpoint ID to Routing Locator (EID-to-RLOC) mappings used to\n      encapsulate LISP data packets.  The proposed approach is based on\n      associating a version number to EID-to-RLOC mappings and the\n      transport of such a version number in the LISP-specific header of\n      LISP-encapsulated packets.  LISP Map-Versioning is particularly\n      useful to inform communicating Ingress Tunnel Routers (ITRs) and\n      Egress Tunnel Routers (ETRs) about modifications of the mappings used\n      to encapsulate packets.  The mechanism is optional and transparent to\n      implementations not supporting this feature, since in the LISP-\n      specific header and in the Map Records, bits used for Map-Versioning\n      can be safely ignored by ITRs and ETRs that do not support or do not\n      want to use the mechanism.\n      \n      This document obsoletes RFC 6834 "Locator/ID Separation Protocol\n      (LISP) Map-Versioning", which is the initial experimental\n      specifications of the mechanisms updated by this document.\n\n  "LISP Control-Plane ECDSA Authentication and Authorization", Dino\n  Farinacci, Erik Nordmark, 2019-09-16, <draft-ietf-lisp-ecdsa-auth-02.txt>\n\n      This draft describes how LISP control-plane messages can be\n      individually authenticated and authorized without a a priori shared-\n      key configuration.  Public-key cryptography is used with no new PKI\n      infrastructure required.\n\n  "Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA\n  Registry for Packet Type Allocations", Mohamed Boucadair, Christian\n  Jacquenet, 2019-01-24, <draft-ietf-lisp-rfc8113bis-03.txt>\n\n      This document specifies a Locator/ID Separation Protocol (LISP)\n      shared message type for defining future extensions and conducting\n      experiments without consuming a LISP packet type codepoint for each\n      extension.\n      \n      This document obsoletes RFC 8113.\n\n  "Network-Hexagons: H3-LISP GeoState & Mobility Network", sbarkai@gmail.com,\n  Bruno Fernandez-Ruiz, Sharon Barkai, Rotem Tamir, Alberto Rodriguez-Natal,\n  Fabio Maino, Albert Cabellos-Aparicio, Dino Farinacci, 2019-12-09,\n  <draft-ietf-lisp-nexagon-00.txt>\n\n      This document specifies combined use of H3-LISP for geo-state &\n      mobility:\n      - Enabling real-time tile by tile indexed annotation of public\n      roads\n      - For sharing: hazards, blockages, conditions, maintenance,\n      furniture..\n      - Between MobilityClients producing-consuming the geo-state\n      information\n      - Using addressable grid of channels for physical world\n      current-state\n\nIPv6 over Low Power Wide-Area Networks (lpwan)\n----------------------------------------------\n\n  "LPWAN Static Context Header Compression (SCHC) for CoAP", Ana Minaburo,\n  Laurent Toutain, Ricardo Andreasen, 2019-12-10,\n  <draft-ietf-lpwan-coap-static-context-hc-12.txt>\n\n      This draft defines the way SCHC header compression can be applied to\n      CoAP headers.  The CoAP header structure differs from IPv6 and UDP\n      protocols since CoAP uses a flexible header with a variable number of\n      options, themselves of variable length.  The CoAP protocol messages\n      format is asymmetric: the request messages have a header format\n      different from the one in the response messages.  This document\n      explains how to use the SCHC compression mechanism for CoAP.\n\n  "Static Context Header Compression (SCHC) and fragmentation for LPWAN,\n  application to UDP/IPv6", Ana Minaburo, Laurent Toutain, Carles Gomez,\n  Dominique Barthel, Juan Zuniga, 2019-12-05,\n  <draft-ietf-lpwan-ipv6-static-context-hc-24.txt>\n\n      This document defines the Static Context Header Compression (SCHC)\n      framework, which provides both a header compression mechanism and an\n      optional fragmentation mechanism.  SCHC has been designed for Low\n      Power Wide Area Networks (LPWAN).\n      \n      SCHC compression is based on a common static context stored both in\n      the LPWAN device and in the network infrastructure side.  This\n      document defines a generic header compression mechanism and its\n      application to compress IPv6/UDP headers.\n      \n      This document also specifies an optional fragmentation and reassembly\n      mechanism.  It can be used to support the IPv6 MTU requirement over\n      the LPWAN technologies.  Fragmentation is needed for IPv6 datagrams\n      that, after SCHC compression or when such compression was not\n      possible, still exceed the layer-2 maximum payload size.\n      \n      The SCHC header compression and fragmentation mechanisms are\n      independent of the specific LPWAN technology over which they are\n      used.  This document defines generic functionalities and offers\n      flexibility with regard to parameter settings and mechanism choices.\n      This document standardizes the exchange over the LPWAN between two\n      SCHC entities.  Settings and choices specific to a technology or a\n      product are expected to be grouped into profiles, which are specified\n      in other documents.  Data models for the context and profiles are out\n      of scope.\n\n  "Static Context Header Compression (SCHC) over LoRaWAN", Olivier Gimenez,\n  Ivaylo Petrov, 2019-12-20, <draft-ietf-lpwan-schc-over-lorawan-05.txt>\n\n      The Static Context Header Compression (SCHC) specification describes\n      generic header compression and fragmentation techniques for LPWAN\n      (Low Power Wide Area Networks) technologies.  SCHC is a generic\n      mechanism designed for great flexibility so that it can be adapted\n      for any of the LPWAN technologies.\n      \n      This document provides the adaptation of SCHC for use in LoRaWAN\n      networks, and provides elements such as efficient parameterization\n      and modes of operation.  This is called a profile.\n\n  "Data Model for Static Context Header Compression (SCHC)", Ana Minaburo,\n  Laurent Toutain, 2020-01-23, <draft-ietf-lpwan-schc-yang-data-model-01.txt>\n\n      This document describes a YANG data model for the SCHC (Static\n      Context Header Compression) compression and fragmentation rules.\n\n  "SCHC over Sigfox LPWAN", Juan Zuniga, Carles Gomez, Laurent Toutain,\n  2019-11-04, <draft-ietf-lpwan-schc-over-sigfox-01.txt>\n\n      The Static Context Header Compression (SCHC) specification describes\n      a header compression scheme and a fragmentation functionality for Low\n      Power Wide Area Network (LPWAN) technologies.  SCHC offers a great\n      level of flexibility that can be tailored for different LPWAN\n      technologies.\n      \n      The present document provides the optimal parameters and modes of\n      operation when SCHC is implemented over a Sigfox LPWAN.\n\n  "SCHC over NB-IoT", Edgar Ramos, Ana Minaburo, 2019-11-16,\n  <draft-ietf-lpwan-schc-over-nbiot-01.txt>\n\n      The Static Context Header Compression (SCHC) specification describes\n      a header compression and fragmentation functionalities for LPWAN (Low\n      Power Wide Area Networks) technologies.  SCHC was designed to be\n      adapted over any of the LPWAN technologies.\n      \n      This document describes the use of SCHC over the NB-IoT wireless\n      access, and provides elements for an efficient parameterization.\n\nLink State Routing (lsr)\n------------------------\n\n  "YANG Data Model for IS-IS Protocol", Stephane Litkowski, Derek Yeung, Acee\n  Lindem, Zhaohui Zhang, Ladislav Lhotka, 2019-10-15,\n  <draft-ietf-isis-yang-isis-cfg-42.txt>\n\n      This document defines a YANG data model that can be used to configure\n      and manage the IS-IS protocol on network elements.\n\n  "YANG Data Model for OSPF Protocol", Derek Yeung, Yingzhen Qu, Zhaohui\n  Zhang, Ing-Wher Chen, Acee Lindem, 2019-10-17, <draft-ietf-ospf-yang-29.txt>\n\n      This document defines a YANG data model that can be used to configure\n      and manage OSPF.  The model is based on YANG 1.1 as defined in RFC\n      7950 and conforms to the Network Management Datastore Architecture\n      (NMDA) as described in RFC 8342.\n\n  "Signaling Entropy Label Capability and Entropy Readable Label-stack Depth\n  Using OSPF", Xiaohu Xu, Sriganesh Kini, Peter Psenak, Clarence Filsfils,\n  Stephane Litkowski, Matthew Bocci, 2019-10-25,\n  <draft-ietf-ospf-mpls-elc-12.txt>\n\n      Multiprotocol Label Switching (MPLS) has defined a mechanism to load-\n      balance traffic flows using Entropy Labels (EL).  An ingress Label\n      Switching Router (LSR) cannot insert ELs for packets going into a\n      given tunnel unless an egress LSR has indicated via signaling that it\n      has the capability to process ELs, referred to as Entropy Label\n      Capability (ELC), on that tunnel.  In addition, it would be useful\n      for ingress LSRs to know each LSR\'s capability of reading the maximum\n      label stack depth and performing EL-based load-balancing, referred to\n      as Entropy Readable Label Depth (ERLD).  This document defines a\n      mechanism to signal these two capabilities using OSPF and OSPFv3.\n      These mechanism is particularly useful in the environment where\n      Segment Routing (SR) is used, where label advertisements are done via\n      protocols like OSPF and OSPFv3.\n\n  "Signaling Entropy Label Capability and Entropy Readable Label Depth Using\n  IS-IS", Xiaohu Xu, Sriganesh Kini, Peter Psenak, Clarence Filsfils,\n  Stephane Litkowski, Matthew Bocci, 2019-10-21,\n  <draft-ietf-isis-mpls-elc-10.txt>\n\n      Multiprotocol Label Switching (MPLS) has defined a mechanism to load-\n      balance traffic flows using Entropy Labels (EL).  An ingress Label\n      Switching Router (LSR) cannot insert ELs for packets going into a\n      given Label Switched Path (LSP) unless an egress LSR has indicated\n      via signaling that it has the capability to process ELs, referred to\n      as Entropy Label Capability (ELC), on that tunnel.  In addition, it\n      would be useful for ingress LSRs to know each LSR\'s capability for\n      reading the maximum label stack depth and performing EL-based load-\n      balancing, referred to as Entropy Readable Label Depth (ERLD).  This\n      document defines a mechanism to signal these two capabilities using\n      IS-IS.  These mechanisms are particularly useful, where label\n      advertisements are done via protocols like IS-IS.\n\n  "Host Router Support for OSPFv2", Keyur Patel, Padma Pillay-Esnault, Manish\n  Bhardwaj, Serpil Bayraktar, 2019-12-18, <draft-ietf-ospf-ospfv2-hbit-12.txt>\n\n      The Open Shortest Path First Version 2 (OSPFv2) protocol does not\n      have a mechanism for a node to repel transit traffic if it is on the\n      shortest path.  This document defines a bit (Host-bit) that enables a\n      router to advertise that it is a non-transit router.  It also\n      describes the changes needed to support the H-bit in the domain.  In\n      addition, this document updates RFC 6987 to advertise type-2 External\n      and Not-So-Stubby-Area (NSSA) Link State Advertisements (LSAs) with a\n      high cost in order to repel traffic effectively.\n\n  "YANG Data Model for OSPF SR (Segment Routing) Protocol", Derek Yeung,\n  Yingzhen Qu, Zhaohui Zhang, Ing-Wher Chen, Acee Lindem, 2019-08-13,\n  <draft-ietf-ospf-sr-yang-10.txt>\n\n      This document defines a YANG data model that can be used to configure\n      and manage OSPF Segment Routing.  The model is based on YANG 1.1 as\n      defined in RFC 7950 and conforms to the Network Management Datastore\n      Architecture (NDMA) as described in RFC 8342.\n\n  "YANG Data Model for IS-IS Segment Routing", Stephane Litkowski, Yingzhen\n  Qu, Pushpasis Sarkar, Ing-Wher Chen, Jeff Tantsura, 2020-01-09,\n  <draft-ietf-isis-sr-yang-07.txt>\n\n      This document defines a YANG data model that can be used to configure\n      and manage IS-IS Segment Routing.\n\n  "IS-IS TE Attributes per application", Les Ginsberg, Peter Psenak, Stefano\n  Previdi, Wim Henderickx, John Drake, 2019-10-30,\n  <draft-ietf-isis-te-app-09.txt>\n\n      Existing traffic engineering related link attribute advertisements\n      have been defined and are used in RSVP-TE deployments.  Since the\n      original RSVP-TE use case was defined, additional applications (e.g.,\n      SRTE, LFA) have been defined which also make use of the link\n      attribute advertisements.  In cases where multiple applications wish\n      to make use of these link attributes the current advertisements do\n      not support application specific values for a given attribute nor do\n      they support indication of which applications are using the\n      advertised value for a given link.\n      \n      This draft introduces new link attribute advertisements which address\n      both of these shortcomings.  It also discusses backwards\n      compatibility issues and how to minimize duplicate advertisements in\n      the presence of routers which do not support the extensions defined\n      in this document.\n\n  "OSPF Link Traffic Engineering Attribute Reuse", Peter Psenak, Les\n  Ginsberg, Wim Henderickx, Jeff Tantsura, John Drake, 2019-10-30,\n  <draft-ietf-ospf-te-link-attr-reuse-10.txt>\n\n      Various link attributes have been defined in OSPF in the context of\n      the MPLS Traffic Engineering (TE) and GMPLS.  Since the original\n      RSVP-TE use case was defined, additional applications (e.g., SRTE,\n      LFA) have been defined which also make use of the link attribute\n      advertisements.  This document defines how to distribute link\n      attributes in OSPFv2 and OSPFv3 for applications other than MPLS TE\n      or GMPLS.\n\n  "IGP Flexible Algorithm", Peter Psenak, Shraddha Hegde, Clarence Filsfils,\n  Ketan Talaulikar, Arkadiy Gulko, 2019-11-04,\n  <draft-ietf-lsr-flex-algo-05.txt>\n\n      IGP protocols traditionally compute best paths over the network based\n      on the IGP metric assigned to the links.  Many network deployments\n      use RSVP-TE based or Segment Routing based Traffic Engineering to\n      enforce traffic over a path that is computed using different metrics\n      or constraints than the shortest IGP path.  This document proposes a\n      solution that allows IGPs themselves to compute constraint based\n      paths over the network.  This document also specifies a way of using\n      Segment Routing (SR) Prefix-SIDs and SRv6 locators to steer packets\n      along the constraint-based paths.\n\n  "Restart Signaling for IS-IS", Les Ginsberg, Paul Wells, 2019-09-19,\n  <draft-ietf-lsr-isis-rfc5306bis-09.txt>\n\n      This document describes a mechanism for a restarting router to signal\n      to its neighbors that it is restarting, allowing them to reestablish\n      their adjacencies without cycling through the down state, while still\n      correctly initiating database synchronization.\n      \n      This document additionally describes a mechanism for a router to\n      signal its neighbors that it is preparing to initiate a restart while\n      maintaining forwarding plane state.  This allows the neighbors to\n      maintain their adjacencies until the router has restarted, but also\n      allows the neighbors to bring the adjacencies down in the event of\n      other topology changes.\n      \n      This document additionally describes a mechanism for a restarting\n      router to determine when it has achieved Link State Protocol Data\n      Unit (LSP) database synchronization with its neighbors and a\n      mechanism to optimize LSP database synchronization, while minimizing\n      transient routing disruption when a router starts.\n      \n      This document obsoletes RFC 5306.\n\n  "IGP extension for PCEP security capability support in the PCE discovery",\n  Diego Lopez, Qin WU, Dhruv Dhody, Zitao Wang, Daniel King, 2019-10-31,\n  <draft-ietf-lsr-pce-discovery-security-support-03.txt>\n\n      When a Path Computation Element (PCE) is a Label Switching Router\n      (LSR) participating in the Interior Gateway Protocol (IGP), or even a\n      server participating in IGP, its presence and path computation\n      capabilities can be advertised using IGP flooding.  The IGP\n      extensions for PCE discovery (RFC 5088 and RFC 5089) define a method\n      to advertise path computation capabilities using IGP flooding for\n      OSPF and IS-IS respectively.  However these specifications lack a\n      method to advertise PCEP security (e.g., Transport Layer\n      Security(TLS), TCP Authentication Option (TCP-AO)) support\n      capability.\n      \n      This document proposes new capability flag bits for PCE-CAP-FLAGS\n      sub-TLV that can be announced as attribute in the IGP advertisement\n      to distribute PCEP security support information.  In addition, this\n      document updates RFC 5088 and RFC 5089 to allow advertisement of Key\n      ID or Key Chain Name Sub-TLV to support TCP AO security capability.\n\n  "IS-IS Routing for Spine-Leaf Topology", Naiming Shen, Les Ginsberg, Sanjay\n  Thyamagundalu, 2019-09-02, <draft-ietf-lsr-isis-spine-leaf-ext-02.txt>\n\n      This document describes a mechanism for routers and switches in a\n      Spine-Leaf type topology to have non-reciprocal Intermediate System\n      to Intermediate System (IS-IS) routing relationships between the\n      leafs and spines.  The leaf nodes do not need to have the topology\n      information of other nodes and exact prefixes in the network.  This\n      extension also has application in the Internet of Things (IoT).\n\n  "Dynamic Flooding on Dense Graphs", Tony Li, Peter Psenak, Les Ginsberg,\n  Huaimo Chen, Tony Przygienda, Dave Cooper, Luay Jalil, Srinath Dontula,\n  2019-11-26, <draft-ietf-lsr-dynamic-flooding-04.txt>\n\n      Routing with link state protocols in dense network topologies can\n      result in sub-optimal convergence times due to the overhead\n      associated with flooding.  This can be addressed by decreasing the\n      flooding topology so that it is less dense.\n      \n      This document discusses the problem in some depth and an\n      architectural solution.  Specific protocol changes for IS-IS, OSPFv2,\n      and OSPFv3 are described in this document.\n\n  "OSPF Prefix Originator Extension", Aijun Wang, Acee Lindem, Jie Dong,\n  Peter Psenak, Ketan Talaulikar, 2019-11-24,\n  <draft-ietf-lsr-ospf-prefix-originator-05.txt>\n\n      This document defines Open Shortest Path First (OSPF) encodings to\n      advertise the router-id of the originator of inter-area prefixes for\n      OSPFv2 and OSPFv3 Link-State Advertisements (LSAs).  The source\n      originator is needed in several multi-area OSPF use cases.\n\n  "IS-IS Extension to Support Segment Routing over IPv6 Dataplane", Peter\n  Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu,\n  2020-01-15, <draft-ietf-lsr-isis-srv6-extensions-04.txt>\n\n      Segment Routing (SR) allows for a flexible definition of end-to-end\n      paths by encoding paths as sequences of topological sub-paths, called\n      "segments".  Segment routing architecture can be implemented over an\n      MPLS data plane as well as an IPv6 data plane.  This draft describes\n      the IS-IS extensions required to support Segment Routing over an IPv6\n      data plane.\n\n  "Invalid TLV Handling in IS-IS", Les Ginsberg, Paul Wells, Tony Li, Tony\n  Przygienda, Shraddha Hegde, 2020-01-15,\n  <draft-ietf-lsr-isis-invalid-tlv-01.txt>\n\n      Key to the extensibility of the Intermediate System to Intermediate\n      System (IS-IS) protocol has been the handling of unsupported and/or\n      invalid Type/Length/Value (TLV) tuples.  Although there are explicit\n      statements in existing specifications, deployment experience has\n      shown that there are inconsistencies in the behavior when a TLV which\n      is disallowed in a particular Protocol Data Unit (PDU) is received.\n      \n      This document discusses such cases and makes the correct behavior\n      explicit in order to insure that interoperability is maximized.\n      \n      This document when approved updates RFC3563, RFC5305, RFC6232, and\n      RFC6233.\n\n  "OSPF YANG Model Augmentations for Additional Features - Version 1", Acee\n  Lindem, Yingzhen Qu, 2019-10-22,\n  <draft-ietf-lsr-ospf-yang-augmentation-v1-00.txt>\n\n      This document defines YANG data modules augmenting the IETF OSPF YANG\n      model to provide support for Traffic Engineering Extensions to OSPF\n      Version 3 as defined in RF 5329, OSPF Two-Part Metric as defined in\n      RFC 8042, OSPF Graceful Link Shutdown as defined in RFC 8379 and OSPF\n      Link-Local Signaling (LLS) Extensions for Local Interface ID\n      Advertisement as defined in RFC 8510.\n\n  "YANG Model for OSPFv3 Extended LSAs", Acee Lindem, Sharmila Palani,\n  Yingzhen Qu, 2019-10-22, <draft-ietf-lsr-ospfv3-extended-lsa-yang-00.txt>\n\n      This document defines a YANG data model augmenting the IETF OSPF YANG\n      model to provide support for OSPFv3 Link State Advertisment (LSA)\n      Extensibility as defined in RFC 8362.  OSPFv3 Extended LSAs provide\n      extensible TLV-based LSAs for the base LSA types defined in RFC 5340.\n\n  "IS-IS Extended Hierarchy", Tony Li, Les Ginsberg, Paul Wells, 2020-01-08,\n  <draft-ietf-lsr-isis-extended-hierarchy-01.txt>\n\n      The IS-IS routing protocol was originally defined with a two level\n      hierarchical structure.  This was adequate for the networks at the\n      time.  As we continue to expand the scale of our networks, it is\n      apparent that additional hierarchy would be a welcome degree of\n      flexibility in network design.\n      \n      This document defines IS-IS Levels 3 through 8.\n\n  "OSPF Strict-Mode for BFD", Ketan Talaulikar, Peter Psenak, Albert Fu,\n  Rejesh Shetty, 2020-01-06, <draft-ietf-lsr-ospf-bfd-strict-mode-00.txt>\n\n      This document specifies the extensions to OSPF that enables a router\n      and its neighbor to signal their intention to use Bidirectional\n      Forwarding Detection (BFD) for their adjacency using link-local\n      advertisement between them.  The signaling of this BFD enablement,\n      allows the router to block and not allow the establishment of\n      adjacency with its neighbor router until a BFD session is\n      successfully established between them.  The document describes this\n      OSPF "strict-mode" of BFD establishment as a prerequisite to\n      adjacency formation.\n\n  "OSPF Reverse Metric", Ketan Talaulikar, Peter Psenak, Hugh Johnston,\n  2020-01-06, <draft-ietf-lsr-ospf-reverse-metric-00.txt>\n\n      This document specifies the extensions to OSPF that enables a router\n      to signal to its neighbor the metric that the neighbor should use\n      towards itself using link-local advertisement between them.  The\n      signalling of this reverse metric, to be used on link(s) towards\n      itself, allows a router to influence the amount of traffic flowing\n      towards itself and in certain use-cases enables routers to maintain\n      symmetric metric on both sides of a link between them.\n\n  "YANG Module for IS-IS Reverse Metric", Christian Hopps, 2020-01-22,\n  <draft-ietf-lsr-yang-isis-reverse-metric-00.txt>\n\n      This document defines a YANG module for managing the reverse metric\n      extension to the the intermediate system to intermediate system\n      routeing protocol.\n\nLink State Vector Routing (lsvr)\n--------------------------------\n\n  "Shortest Path Routing Extensions for BGP Protocol", Keyur Patel, Acee\n  Lindem, Shawn Zandi, Wim Henderickx, 2019-12-10,\n  <draft-ietf-lsvr-bgp-spf-07.txt>\n\n      Many Massively Scaled Data Centers (MSDCs) have converged on\n      simplified layer 3 routing.  Furthermore, requirements for\n      operational simplicity have led many of these MSDCs to converge on\n      BGP as their single routing protocol for both their fabric routing\n      and their Data Center Interconnect (DCI) routing.  This document\n      describes a solution which leverages BGP Link-State distribution and\n      the Shortest Path First (SPF) algorithm similar to Internal Gateway\n      Protocols (IGPs) such as OSPF.\n\n  "Usage and Applicability of Link State Vector Routing in Data Centers",\n  Keyur Patel, Acee Lindem, Shawn Zandi, Gaurav Dawra, 2019-11-02,\n  <draft-ietf-lsvr-applicability-04.txt>\n\n      This document discusses the usage and applicability of Link State\n      Vector Routing (LSVR) extensions in data center networks utilizing\n      CLOS or Fat-Tree topologies.  The document is intended to provide a\n      simplified guide for the deployment of LSVR extensions.\n\n  "Layer 3 Discovery and Liveness", Randy Bush, Rob Austein, Keyur Patel,\n  2019-11-02, <draft-ietf-lsvr-l3dl-03.txt>\n\n      In Massive Data Centers, BGP-SPF and similar routing protocols are\n      used to build topology and reachability databases.  These protocols\n      need to discover IP Layer 3 attributes of links, such as logical link\n      IP encapsulation abilities, IP neighbor address discovery, and link\n      liveness.  This Layer 3 Discovery and Liveness protocol collects\n      these data, which may then be disseminated using BGP-SPF and similar\n      protocols.\n\nLight-Weight Implementation Guidance (lwig)\n-------------------------------------------\n\n  "Building Power-Efficient CoAP Devices for Cellular Networks", Jari Arkko,\n  Anders Eriksson, Ari Keranen, 2016-01-04, <draft-ietf-lwig-cellular-06.txt>\n\n      This memo discusses the use of the Constrained Application Protocol\n      (CoAP) protocol in building sensors and other devices that employ\n      cellular networks as a communications medium.  Building communicating\n      devices that employ these networks is obviously well known, but this\n      memo focuses specifically on techniques necessary to minimize power\n      consumption.\n\n  "TCP Usage Guidance in the Internet of Things (IoT)", Carles Gomez, Jon\n  Crowcroft, Michael Scharf, 2019-11-04,\n  <draft-ietf-lwig-tcp-constrained-node-networks-09.txt>\n\n      This document provides guidance on how to implement and use the\n      Transmission Control Protocol (TCP) in Constrained-Node Networks\n      (CNNs), which are a characterstic of the Internet of Things (IoT).\n      Such environments require a lightweight TCP implementation and may\n      not make use of optional functionality.  This document explains a\n      number of known and deployed techniques to simplify a TCP stack as\n      well as corresponding tradeoffs.  The objective is to help embedded\n      developers with decisions on which TCP features to use.\n\n  "Alternative Elliptic Curve Representations", Rene Struik, 2019-07-24,\n  <draft-ietf-lwig-curve-representations-08.txt,.pdf>\n\n      This document specifies how to represent Montgomery curves and\n      (twisted) Edwards curves as curves in short-Weierstrass form and\n      illustrates how this can be used to carry out elliptic curve\n      computations using existing implementations of, e.g., ECDSA and ECDH\n      using NIST prime curves.\n\nMobile Ad-hoc Networks (manet)\n------------------------------\n\n  "Dynamic Link Exchange Protocol (DLEP) Latency Range Extension", Bow-Nan\n  Cheng, Lou Berger, 2019-11-20,\n  <draft-ietf-manet-dlep-latency-extension-05.txt>\n\n      This document defines an extension to the Dynamic Link Exchange\n      Protocol (DLEP) to provide the range of latency that can be\n      experienced on a link.\n\n  "DLEP DiffServ Aware Credit Window Extension", Bow-Nan Cheng, David\n  Wiggins, Lou Berger, 2019-11-19,\n  <draft-ietf-manet-dlep-da-credit-extension-08.txt>\n\n      This document defines an extension to the Dynamic Link Exchange\n      Protocol (DLEP) that enables a DiffServ aware credit-window scheme\n      for destination-specific and shared flow control.\n\n  "DLEP Link Identifier Extension", Rick Taylor, Stan Ratliff, 2019-09-10,\n  <draft-ietf-manet-dlep-lid-extension-06.txt>\n\n      The Dynamic Link Exchange Protocol, RFC 8175, describes a protocol\n      for modems to advertise the status of wireless links between\n      reachable destinations to attached routers.  The core specification\n      of the protocol assumes that every modem in the radio network has an\n      attached DLEP router, and requires that the MAC address of the DLEP\n      interface on the attached router be used to identify the destination\n      in the network, for purposes of reporting the state and quality of\n      the link to that destination.\n      \n      This document describes a DLEP Extension allowing modems that do not\n      meet the strict requirement above to use DLEP to describe link\n      availability and quality to one or more destinations reachable beyond\n      a device on the Layer 2 domain.\n\n  "DLEP Credit-Based Flow Control Messages and Data Items", Bow-Nan Cheng,\n  David Wiggins, Lou Berger, Stan Ratliff, 2019-11-19,\n  <draft-ietf-manet-dlep-credit-flow-control-05.txt>\n\n      This document defines new Dynamic Link Exchange Protocol (DLEP) Data\n      Items that are used to support credit-based flow control.  Credit\n      window control is used to regulate when data may be sent to an\n      associated virtual or physical queue.  The Data Items are defined in\n      an extensible and reusable fashion.  Their use will be mandated in\n      other documents defining specific DLEP extensions.\n\n  "DLEP Traffic Classification Data Item", Bow-Nan Cheng, David Wiggins, Lou\n  Berger, 2019-11-19, <draft-ietf-manet-dlep-traffic-classification-02.txt>\n\n      This document defines a new Dynamic Link Exchange Protocol (DLEP)\n      Data Item that is used to support traffic classification.  Traffic\n      classification information is used to identify traffic flows based on\n      frame/packet content such as destination address.  The Data Item is\n      defined in an extensible and reusable fashion.  It\'s use will be\n      mandated in other documents defining specific DLEP extensions.  This\n      document aloas introduces DLEP sub data items, and sub data items are\n      defined to support DiffServ and Ethernet traffic classification.\n\nMBONE Deployment (mboned)\n-------------------------\n\n  "Multicast Considerations over IEEE 802 Wireless Media", Charles Perkins,\n  Mike McBride, Dorothy Stanley, Warren Kumari, Juan Zuniga, 2019-12-11,\n  <draft-ietf-mboned-ieee802-mcast-problems-11.txt>\n\n      Well-known issues with multicast have prevented the deployment of\n      multicast in 802.11 (wifi) and other local-area wireless\n      environments.\n      \n      This document describes the problems of known limitations with\n      wireless (primarily 802.11) Layer-2 multicast.  Also described are\n      certain multicast enhancement features that have been specified by\n      the IETF, and by IEEE 802, for wireless media, as well as some\n      operational choices that can be taken to improve the performance of\n      the network.  Finally, some recommendations are provided about the\n      usage and combination of these features and operational choices.\n\n  "Multicast YANG Data Model", Zheng Zhang, Cui(Linda) Wang, Ying Cheng,\n  Xufeng Liu, Mahesh Sivakumar, 2019-09-12,\n  <draft-ietf-mboned-multicast-yang-model-02.txt>\n\n      This document intents to provide a general and all-round multicast\n      YANG data model, which tries to stand at a high level to take full\n      advantages of existed multicast protocol models to control the\n      multicast network, and guides the deployment of multicast service.\n      And also, there will define several possible RPCs about how to\n      interact between multicast YANG data model and multicast protocol\n      models.  This multicast YANG data model is mainly used by the\n      management tools run by the network operators in order to manage,\n      monitor and debug the network resources used to deliver multicast\n      service, as well as gathering some data from the network.\n\n  "Deprecating ASM for Interdomain Multicast", Mikael Abrahamsson, Tim Chown,\n  Leonard Giuliano, Toerless Eckert, 2020-01-03,\n  <draft-ietf-mboned-deprecate-interdomain-asm-06.txt>\n\n      This document recommends deprecation of the use of Any-Source\n      Multicast (ASM) for interdomain multicast.  It recommends the use of\n      Source-Specific Multicast (SSM) for interdomain multicast\n      applications and recommends that hosts and routers in these\n      deployments fully support SSM.  The recommendations in this document\n      do not preclude the continued use of ASM within a single organisation\n      or domain and are especially easy to adopt in existing intradomain\n      ASM/PIM-SM deployments.\n\n  "DNS Reverse IP AMT (Automatic Multicast Tunneling) Discovery", Jake\n  Holland, 2019-12-20, <draft-ietf-mboned-driad-amt-discovery-13.txt>\n\n      This document updates RFC 7450 (Automatic Multicast Tunneling, or\n      AMT) by modifying the relay discovery process.  A new DNS resource\n      record named AMTRELAY is defined for publishing AMT relays for\n      source-specific multicast channels.  The reverse IP DNS zone for a\n      multicast sender\'s IP address is configured to use AMTRELAY resource\n      records to advertise a set of AMT relays that can receive and forward\n      multicast traffic from that sender over an AMT tunnel.  Other\n      extensions and clarifications to the relay discovery process are also\n      defined.\n\nManaged Incident Lightweight Exchange (mile)\n--------------------------------------------\n\n  "JSON binding of IODEF", Takeshi Takahashi, Roman Danyliw, Mio Suzuki,\n  2019-12-24, <draft-ietf-mile-jsoniodef-12.txt,.pdf>\n\n      The Incident Object Description Exchange Format defined in RFC 7970\n      provides an information model and a corresponding XML data model for\n      exchanging incident and indicator information.  This draft gives\n      implementers and operators an alternative format to exchange the same\n      information by defining an alternative data model implementation in\n      JSON and its encoding in CBOR.\n\n  "Definition of ROLIE CSIRT Extension", Stephen Banghart, John Field,\n  2019-10-28, <draft-ietf-mile-rolie-csirt-06.txt>\n\n      This document extends the Resource-Oriented Lightweight Information\n      Exchange (ROLIE) core to add the Indicator and Incident information\n      types, relevant categories, and related requirements needed to\n      support Computer Security Incident Response Team (CSIRT) use cases.\n      Additional supporting requirements are also defined that describe the\n      use of specific formats and link relations pertaining to the new\n      information types.\n\n  "Definition of the ROLIE Vulnerability Extension", Stephen Banghart,\n  2019-10-28, <draft-ietf-mile-rolie-vuln-03.txt>\n\n      This document extends the Resource-Oriented Lightweight Information\n      Exchange (ROLIE) core to add the information type categories and\n      related requirements needed to support Vulnerability use cases.\n      Additional categories, properties, and requirements based on content\n      type enables a higher level of interoperability between ROLIE\n      implementations, and richer metadata for ROLIE consumers.  In\n      particular, usage of the Common Vulnerability Enumeration (CVE) [cve]\n      format is discussed.\n\nMessaging Layer Security (mls)\n------------------------------\n\n  "The Messaging Layer Security (MLS) Protocol", Richard Barnes, Benjamin\n  Beurdouche, Jon Millican, Emad Omara, Katriel Cohn-Gordon, Raphael Robert,\n  2019-11-17, <draft-ietf-mls-protocol-08.txt>\n\n      Messaging applications are increasingly making use of end-to-end\n      security mechanisms to ensure that messages are only accessible to\n      the communicating endpoints, and not to any servers involved in\n      delivering messages.  Establishing keys to provide such protections\n      is challenging for group chat settings, in which more than two\n      clients need to agree on a key but may not be online at the same\n      time.  In this document, we specify a key establishment protocol that\n      provides efficient asynchronous group key establishment with forward\n      secrecy and post-compromise security for groups in size ranging from\n      two to thousands.\n\n  "The Messaging Layer Security (MLS) Architecture", Emad Omara, Benjamin\n  Beurdouche, Eric Rescorla, Srinivas Inguva, Albert Kwon, Alan Duric,\n  2020-01-26, <draft-ietf-mls-architecture-04.txt>\n\n      This document describes the reference architecture, functional and\n      security requirements for the Messaging Layer Security (MLS)\n      protocol.  MLS provides a security layer for group messaging\n      applications with from two to a large number of clients.  It is meant\n      to protect against eavesdropping, tampering, and message forgery.\n\n  "The Messaging Layer Security (MLS) Federation", Emad Omara, Raphael\n  Robert, 2019-09-11, <draft-ietf-mls-federation-00.txt>\n\n      This document describes how the Messaging Layer Security (MLS) can be\n      used in a federated environment where different MLS implementations\n      can interoperate by defining the message format for user key\n      retrieval.  The document also describes some use cases where\n      federation could be useful.\n\nMultiparty Multimedia Session Control (mmusic)\n----------------------------------------------\n\n  "SDP: Session Description Protocol", Ali Begen, Paul Kyzivat, Colin\n  Perkins, Mark Handley, 2019-08-09, <draft-ietf-mmusic-rfc4566bis-37.txt>\n\n      This memo defines the Session Description Protocol (SDP).  SDP is\n      intended for describing multimedia sessions for the purposes of\n      session announcement, session invitation, and other forms of\n      multimedia session initiation.  This document obsoletes RFC 4566.\n\n  "Session Description Protocol (SDP) Offer/Answer Procedures For Stream\n  Control Transmission Protocol (SCTP) over Datagram Transport Layer Security\n  (DTLS) Transport.", Christer Holmberg, Roman Shpount, Salvatore Loreto,\n  Gonzalo Camarillo, 2017-04-20, <draft-ietf-mmusic-sctp-sdp-26.txt>\n\n      The Stream Control Transmission Protocol (SCTP) is a transport\n      protocol used to establish associations between two endpoints.\n      draft-ietf-tsvwg-sctp-dtls-encaps-09 specifies how SCTP can be used\n      on top of the Datagram Transport Layer Security (DTLS) protocol,\n      referred to as SCTP-over-DTLS.\n      \n      This specification defines the following new Session Description\n      Protocol (SDP) protocol identifiers (proto values):\'UDP/DTLS/SCTP\'\n      and \'TCP/DTLS/SCTP\'.  This specification also specifies how to use\n      the new proto values with the SDP Offer/Answer mechanism for\n      negotiating SCTP-over-DTLS associations.\n\n  "Negotiating Media Multiplexing Using the Session Description Protocol\n  (SDP)", Christer Holmberg, Harald Alvestrand, Cullen Jennings, 2018-12-14,\n  <draft-ietf-mmusic-sdp-bundle-negotiation-54.txt>\n\n      This specification defines a new Session Description Protocol (SDP)\n      Grouping Framework extension, \'BUNDLE\'.  The extension can be used\n      with the SDP Offer/Answer mechanism to negotiate the usage of a\n      single transport (5-tuple) for sending and receiving media described\n      by multiple SDP media descriptions ("m=" sections).  Such transport\n      is referred to as a BUNDLE transport, and the media is referred to as\n      bundled media.  The "m=" sections that use the BUNDLE transport form\n      a BUNDLE group.\n      \n      This specification updates RFC 3264, to also allow assigning a zero\n      port value to a "m=" section in cases where the media described by\n      the "m=" section is not disabled or rejected.\n      \n      This specification updates RFC 5888, to also allow an SDP \'group\'\n      attribute to contain an identification-tag that identifies a "m="\n      section with the port set to zero.\n      \n      This specification defines a new RTP Control Protocol (RTCP) source\n      description (SDES) item and a new RTP header extension that can be\n      used to correlate bundled RTP/RTCP packets with their appropriate\n      "m=" section.\n      \n      This specification updates RFC 7941, by adding an exception, for the\n      MID RTP header extension, to the requirement regarding protection of\n      an SDES RTP header extension carrying an SDES item for the MID RTP\n      header extension.\n\n  "WebRTC MediaStream Identification in the Session Description Protocol",\n  Harald Alvestrand, 2018-12-13, <draft-ietf-mmusic-msid-17.txt>\n\n      This document specifies a Session Description Protocol (SDP) Grouping\n      mechanism for RTP media streams that can be used to specify relations\n      between media streams.\n      \n      This mechanism is used to signal the association between the SDP\n      concept of "media description" and the WebRTC concept of\n      "MediaStream" / "MediaStreamTrack" using SDP signaling.\n      \n      This document is a work item of the MMUSIC WG, whose discussion list\n      is mmusic@ietf.org.\n\n  "Session Description Protocol (SDP) Offer/Answer procedures for Interactive\n  Connectivity Establishment (ICE)", Marc Petit-Huguenin, Suhas Nandakumar,\n  Christer Holmberg, Ari Keranen, Roman Shpount, 2019-08-13,\n  <draft-ietf-mmusic-ice-sip-sdp-39.txt>\n\n      This document describes Session Description Protocol (SDP) Offer/\n      Answer procedures for carrying out Interactive Connectivity\n      Establishment (ICE) between the agents.\n      \n      This document obsoletes RFC 5245.\n\n  "A Framework for SDP Attributes when Multiplexing", Suhas Nandakumar,\n  2018-02-28, <draft-ietf-mmusic-sdp-mux-attributes-17.txt>\n\n      The purpose of this specification is to provide a framework for\n      analyzing the multiplexing characteristics of Session Description\n      Protocol (SDP) attributes when SDP is used to negotiate the usage of\n      single 5-tuple for sending and receiving media associated with\n      multiple media descriptions.\n      \n      This specification also categorizes the existing SDP attributes based\n      on the framework described herein.\n\n  "A Session Initiation Protocol (SIP) Usage for Incremental Provisioning of\n  Candidates for the Interactive Connectivity Establishment (Trickle ICE)",\n  Emil Ivov, Thomas Stach, Enrico Marocco, Christer Holmberg, 2018-06-23,\n  <draft-ietf-mmusic-trickle-ice-sip-18.txt>\n\n      The Interactive Connectivity Establishment (ICE) protocol describes a\n      Network Address Translator (NAT) traversal mechanism for UDP-based\n      multimedia sessions established with the Offer/Answer model.  The ICE\n      extension for Incremental Provisioning of Candidates (Trickle ICE)\n      defines a mechanism that allows ICE Agents to shorten session\n      establishment delays by making the candidate gathering and\n      connectivity checking phases of ICE non-blocking and by executing\n      them in parallel.\n      \n      This document defines usage semantics for Trickle ICE with the\n      Session Initiation Protocol (SIP).  The document also defines a new\n      SIP Info Package to support this usage together with the\n      corresponding media type.  Additionally, a new SDP \'end-of-\n      candidates\' attribute and a new SIP Option Tag \'trickle-ice\' are\n      defined.\n\n  "Using Simulcast in SDP and RTP Sessions", Bo Burman, Magnus Westerlund,\n  Suhas Nandakumar, Mo Zanaty, 2019-03-05,\n  <draft-ietf-mmusic-sdp-simulcast-14.txt>\n\n      In some application scenarios it may be desirable to send multiple\n      differently encoded versions of the same media source in different\n      RTP streams.  This is called simulcast.  This document describes how\n      to accomplish simulcast in RTP and how to signal it in SDP.  The\n      described solution uses an RTP/RTCP identification method to identify\n      RTP streams belonging to the same media source, and makes an\n      extension to SDP to relate those RTP streams as being different\n      simulcast formats of that media source.  The SDP extension consists\n      of a new media level SDP attribute that expresses capability to send\n      and/or receive simulcast RTP streams.\n\n  "SDP-based Data Channel Negotiation", Keith Drage, Maridi Makaraju, Richard\n  Ejzak, Jerome Marcon, Roni Even, 2019-05-11,\n  <draft-ietf-mmusic-data-channel-sdpneg-28.txt,.pdf>\n\n      Data channel setup can be done using either the in-band Data Channel\n      Establishment Protocol (DCEP) or using some out-of-band non-DCEP\n      protocol.  This document specifies how the SDP (Session Description\n      Protocol) offer/answer exchange can be used to achieve an out-of-band\n      non-DCEP negotiation for establishing a data channel.\n\n  "MSRP over Data Channels", Keith Drage, Maridi Makaraju, Juergen\n  Stoetzer-Bradler, Richard Ejzak, Jose Recio, 2019-12-09,\n  <draft-ietf-mmusic-msrp-usage-data-channel-14.txt>\n\n      This document specifies how the Message Session Relay Protocol (MSRP)\n      can be instantiated as a data channel sub-protocol, using the SDP\n      offer/answer exchange-based generic data channel negotiation\n      framework.  Two network configurations are documented: a WebRTC end-\n      to-end configuration (connecting two MSRP over data channel\n      endpoints), and a gateway configuration (connecting an MSRP over data\n      channel endpoint with an MSRP over TCP or TLS endpoint).\n\n  "Session Description Protocol (SDP) Offer/Answer Considerations for\n  Datagram Transport Layer Security (DTLS) and Transport Layer Security\n  (TLS)", Christer Holmberg, Roman Shpount, 2017-10-29,\n  <draft-ietf-mmusic-dtls-sdp-32.txt>\n\n      This document defines the Session Description Protocol (SDP) offer/\n      answer procedures for negotiating and establishing a Datagram\n      Transport Layer Security (DTLS) association.  The document also\n      defines the criteria for when a new DTLS association must be\n      established.  The document updates RFC 5763 and RFC 7345, by\n      replacing common SDP offer/answer procedures with a reference to this\n      specification.\n      \n      This document defines a new SDP media-level attribute, \'tls-id\'.\n      \n      This document also defines how the \'tls-id\' attribute can be used for\n      negotiating and establishing a Transport Layer Security (TLS)\n      connection, in conjunction with the procedures in RFC 4145 and RFC\n      8122.\n\n  "RTP Payload Format Restrictions", Adam Roach, 2018-05-15,\n  <draft-ietf-mmusic-rid-15.txt>\n\n      In this specification, we define a framework for specifying\n      restrictions on RTP streams in the Session Description Protocol.\n      This framework defines a new "rid" ("restriction identifier") SDP\n      attribute to unambiguously identify the RTP Streams within an RTP\n      Session and restrict the streams\' payload format parameters in a\n      codec-agnostic way beyond what is provided with the regular Payload\n      Types.\n      \n      This specification updates RFC4855 to give additional guidance on\n      choice of Format Parameter (fmtp) names, and on their relation to the\n      restrictions defined by this document.\n\n  "Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP", Christer\n  Holmberg, 2017-05-05, <draft-ietf-mmusic-mux-exclusive-12.txt>\n\n      This document defines a new SDP media-level attribute, \'rtcp-mux-\n      only\', that can be used by an endpoint to indicate exclusive support\n      of RTP/RTCP multiplexing.  The document also updates RFC 5761, by\n      clarifying that an offerer can use a mechanism to indicate that it is\n      not able to send and receive RTCP on separate ports.\n\n  "Unknown Key Share Attacks on uses of TLS with the Session Description\n  Protocol (SDP)", Martin Thomson, Eric Rescorla, 2019-08-09,\n  <draft-ietf-mmusic-sdp-uks-07.txt>\n\n      This document describes unknown key-share attacks on the use of\n      Datagram Transport Layer Security for the Secure Real-Time Transport\n      Protocol (DTLS-SRTP).  Similar attacks are described on the use of\n      DTLS-SRTP with the identity bindings used in Web Real-Time\n      Communications (WebRTC) and SIP identity.  These attacks are\n      difficult to mount, but they cause a victim to be mislead about the\n      identity of a communicating peer.  Mitigation techniques are defined\n      that implementations of RFC 8122 are encouraged to deploy.\n\n  "T.140 Real-time Text Conversation over WebRTC Data Channels", Christer\n  Holmberg, 2019-12-19, <draft-ietf-mmusic-t140-usage-data-channel-11.txt>\n\n      This document specifies how a WebRTC data channel can be used as a\n      transport mechanism for Real-time text using the ITU-T Protocol for\n      multimedia application text conversation (Recommendation ITU-T\n      T.140), and how the SDP offer/answer mechanism can be used to\n      negotiate such data channel, referred to as T.140 data channel.  The\n      document updates RFC 8373.\n\nMultiprotocol Label Switching (mpls)\n------------------------------------\n\n  "Bidirectional Forwarding Detection (BFD) Directed Return Path", Gregory\n  Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2019-12-19,\n  <draft-ietf-mpls-bfd-directed-13.txt>\n\n      Bidirectional Forwarding Detection (BFD) is expected to be able to\n      monitor a wide variety of encapsulations of paths between systems.\n      When a BFD session monitors an explicitly routed unidirectional path\n      there may be a need to direct egress BFD peer to use a specific path\n      for the reverse direction of the BFD session.\n\n  "Resilient MPLS Rings", Kireeti Kompella, Luis Contreras, 2019-10-23,\n  <draft-ietf-mpls-rmr-12.txt>\n\n      This document describes the use of the MPLS control and data planes\n      on ring topologies.  It describes the special nature of rings, and\n      proceeds to show how MPLS can be effectively used in such topologies.\n      It describes how MPLS rings are configured, auto-discovered and\n      signaled, as well as how the data plane works.  Companion documents\n      describe the details of discovery and signaling for specific\n      protocols.\n\n  "A YANG Data Model for MPLS Base", Tarek Saad, Kamran Raza, Rakesh Gandhi,\n  Xufeng Liu, Vishnu Beeram, 2019-09-12, <draft-ietf-mpls-base-yang-11.txt>\n\n      This document contains a specification of the MPLS base YANG model.\n      The MPLS base YANG model serves as a base framework for configuring\n      and managing an MPLS switching subsystem on an MPLS-enabled router.\n      It is expected that other MPLS YANG models (e.g.  MPLS LSP Static,\n      LDP or RSVP-TE YANG models) will augment the MPLS base YANG model.\n\n  "A YANG Data Model for MPLS Static LSPs", Tarek Saad, Rakesh Gandhi, Xufeng\n  Liu, Vishnu Beeram, Igor Bryskin, 2019-09-12,\n  <draft-ietf-mpls-static-yang-10.txt>\n\n      This document contains the specification for the MPLS Static Label\n      Switched Paths (LSPs) YANG model.  The model allows for the\n      provisioning of static LSP(s) on Label Edge Router(s) LER(s) and\n      Label Switched Router(s) LSR(s) devices along a LSP path without the\n      dependency on any signaling protocol.  The MPLS Static LSP model\n      augments the MPLS base YANG model with specific data to configure and\n      manage MPLS Static LSP(s).\n\n  "Refresh-interval Independent FRR Facility Protection", Chandrasekar R,\n  Tarek Saad, Ina Minei, Dante Pacella, 2019-09-03,\n  <draft-ietf-mpls-ri-rsvp-frr-07.txt>\n\n      RSVP-TE Fast ReRoute extensions specified in RFC 4090 defines two\n      local repair techniques to reroute Label Switched Path (LSP) traffic\n      over pre-established backup tunnel.  Facility backup method allows\n      one or more LSPs traversing a connected link or node to be protected\n      using a bypass tunnel.  The many-to-one nature of local repair\n      technique is attractive from scalability point of view.  This\n      document enumerates facility backup procedures in RFC 4090 that rely\n      on refresh timeout and hence make facility backup method refresh-\n      interval dependent.  The RSVP-TE extensions defined in this document\n      will enhance the facility backup protection mechanism by making the\n      corresponding procedures refresh-interval independent and hence\n      compatible with Refresh-interval Independent RSVP (RI-RSVP) specified\n      in RFC 8370.  Hence, this document updates RFC 4090 in order to\n      support RI-RSVP capability specified in RFC 8370.\n\n  "YANG Data Model for MPLS LDP", Kamran Raza, Rajiv Asati, Xufeng Liu,\n  Santosh Esale, Xia Chen, Himanshu Shah, 2019-11-04,\n  <draft-ietf-mpls-ldp-yang-07.txt>\n\n      This document describes a YANG data model for Multi-Protocol Label\n      Switching (MPLS) Label Distribution Protocol (LDP).  The model also\n      serves as the base model to define Multipoint LDP (mLDP) model.\n      \n      The YANG modules in this document conform to the Network Management\n      Datastore Architecture (NMDA).\n\n  "RFC6374 Synonymous Flow Labels", Stewart Bryant, Mach Chen, Zhenbin Li,\n  George Swallow, Siva Sivabalan, Gregory Mirsky, Giuseppe Fioccola,\n  2019-07-29, <draft-ietf-mpls-rfc6374-sfl-04.txt>\n\n      This document describes a method of making RFC6374 performance\n      measurements on flows carried over an MPLS Label Switched path.  This\n      allows loss and delay measurements to be made on multi-point to point\n      LSPs and allows the measurement of flows within an MPLS construct\n      using RFC6374.\n\n  "Synonymous Flow Label Framework", Stewart Bryant, Mach Chen, Zhenbin Li,\n  George Swallow, Siva Sivabalan, Gregory Mirsky, 2019-10-09,\n  <draft-ietf-mpls-sfl-framework-06.txt>\n\n      RFC 8372 describes the requirement for introducing flow identities\n      within the MPLS architecture.  This document describes a method of\n      accomplishing this by using a technique called Synonymous Flow Labels\n      in which labels which mimic the behaviour of other labels provide the\n      identification service.  These identifiers can be used to trigger\n      per-flow operations on the packet at the receiving label switching\n      router.\n\n  "RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels", Mike Taillon,\n  Tarek Saad, Rakesh Gandhi, Abhishek Deshmukh, Markus Jork, Vishnu Beeram,\n  2020-01-12, <draft-ietf-mpls-summary-frr-rsvpte-08.txt>\n\n      This document updates RFC 4090 for the Resource Reservation Protocol\n      (RSVP) Traffic-Engineering (TE) procedures defined for facility\n      backup protection.  The updates include extensions that reduce the\n      amount of signaling and processing that occurs during Fast Reroute\n      (FRR), and subsequently, improves scalability when undergoing FRR\n      convergence after a link or node failure.  These extensions allow the\n      RSVP message exchange between the Point of Local Repair (PLR) and the\n      Merge Point (MP) to be independent of the number of protected Label\n      Switched Paths (LSPs) traversing between them when facility bypass\n      FRR protection is used.  The signaling extensions are fully backwards\n      compatible with nodes that do not support them.\n\n  "Special Purpose Label terminology", Loa Andersson, Kireeti Kompella,\n  Adrian Farrel, 2019-11-21, <draft-ietf-mpls-spl-terminology-01.txt>\n\n      This document discusses and recommends a terminology that may be used\n      when MPLS Special Purpose Labels (SPL) are specified and documented.\n      \n      This document updates RFC 7274 and RFC 3032.\n\n  "Resilient MPLS Rings and Multicast", Zhaohui Zhang, Santosh Esale,\n  2019-08-13, <draft-ietf-mpls-rmr-multicast-00.txt>\n\n      With Resilient MPLS Rings (RMR), although all existing multicast\n      procedures and solutions can work as is, there are optimizations that\n      could be done for RSVP-TE P2MP tunnel signaling and Fast-ReRouting\n      for both mLDP and RSVP-TE P2MP tunnels.  This document describes RMR\n      multicast on a high level, with detailed protocol procedure for RSVP-\n      TE P2MP optimizations specified in a separate document.  This\n      document also discusses end to end multicast when there are RMRs.\n\n  "Updating the IANA MPLS LSP Ping Parameters", Loa Andersson, Tarek Saad,\n  Mach Chen, Carlos Pignataro, 2019-10-17,\n  <draft-ietf-mpls-lsp-ping-registries-update-00.txt>\n\n      This document updates RFC 8029 and RFC 8611 that define IANA\n      registries for MPLS LSP Ping.  The updates are mostly for\n      clarification and to align this registry with recent developments..\n\nMultipath TCP (mptcp)\n---------------------\n\n  "TCP Extensions for Multipath Operation with Multiple Addresses", Alan\n  Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, Christoph Paasch,\n  2019-06-08, <draft-ietf-mptcp-rfc6824bis-18.txt>\n\n      TCP/IP communication is currently restricted to a single path per\n      connection, yet multiple paths often exist between peers.  The\n      simultaneous use of these multiple paths for a TCP/IP session would\n      improve resource usage within the network and, thus, improve user\n      experience through higher throughput and improved resilience to\n      network failure.\n      \n      Multipath TCP provides the ability to simultaneously use multiple\n      paths between peers.  This document presents a set of extensions to\n      traditional TCP to support multipath operation.  The protocol offers\n      the same type of service to applications as TCP (i.e., reliable\n      bytestream), and it provides the components necessary to establish\n      and use multiple TCP flows across potentially disjoint paths.\n      \n      This document specifies v1 of Multipath TCP, obsoleting v0 as\n      specified in RFC6824, through clarifications and modifications\n      primarily driven by deployment experience.\n\nMeeting Venue (mtgvenue)\n------------------------\n\n  "IETF Plenary Meeting Venue Selection Process", Eliot Lear, 2018-06-14,\n  <draft-ietf-mtgvenue-iaoc-venue-selection-process-16.txt>\n\n      The IASA has responsibility for arranging IETF plenary meeting Venue\n      selection and operation.  This memo specifies IETF community\n      requirements for meeting venues, including hotels and meeting room\n      space.  It directs the IASA to make available additional process\n      documents that describe the current meeting selection process.\n\n  "High level guidance for the meeting policy of the IETF", Suresh Krishnan,\n  2018-07-02, <draft-ietf-mtgvenue-meeting-policy-07.txt>\n\n      This document describes a meeting location policy for the IETF and\n      the various stakeholders for realizing such a policy.\n\nNetwork Configuration (netconf)\n-------------------------------\n\n  "YANG Groupings for TLS Clients and TLS Servers", Kent Watsen, Gary Wu,\n  Liang Xia, 2019-11-20, <draft-ietf-netconf-tls-client-server-17.txt>\n\n      This document defines three YANG modules: the first defines groupings\n      for a generic TLS client, the second defines groupings for a generic\n      TLS server, and the third defines common identities and groupings\n      used by both the client and the server.  It is intended that these\n      groupings will be used by applications using the TLS protocol.\n\n  "RESTCONF Client and Server Models", Kent Watsen, 2019-11-20,\n  <draft-ietf-netconf-restconf-client-server-17.txt>\n\n      This document defines two YANG modules, one module to configure a\n      RESTCONF client and the other module to configure a RESTCONF server.\n      Both modules support the TLS transport protocol with both standard\n      RESTCONF and RESTCONF Call Home connections.\n      \n      Editorial Note (To be removed by RFC Editor)\n      \n      This draft contains many placeholder values that need to be replaced\n      with finalized values at the time of publication.  This note\n      summarizes all of the substitutions that are needed.  No other RFC\n      Editor instructions are specified elsewhere in this document.\n      \n      This document contains references to other drafts in progress, both\n      in the Normative References section, as well as in body text\n      throughout.  Please update the following references to reflect their\n      final RFC assignments:\n      \n      o  I-D.ietf-netconf-keystore\n      \n      o  I-D.ietf-netconf-tcp-client-server\n      \n      o  I-D.ietf-netconf-tls-client-server\n      \n      o  I-D.ietf-netconf-http-client-server\n      \n      Artwork in this document contains shorthand references to drafts in\n      progress.  Please apply the following replacements:\n      \n      o  "XXXX" --> the assigned RFC value for this draft\n      \n      o  "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client-\n      server\n      \n      o  "BBBB" --> the assigned RFC value for I-D.ietf-netconf-tls-client-\n      server\n      \n      o  "CCCC" --> the assigned RFC value for I-D.ietf-netconf-http-\n      client-server\n      \n      Artwork in this document contains placeholder values for the date of\n      publication of this draft.  Please apply the following replacement:\n      \n      o  "2019-11-20" --> the publication date of this draft\n      \n      The following Appendix section is to be removed prior to publication:\n      \n      o  Appendix B.  Change Log\n\n  "YANG Groupings for SSH Clients and SSH Servers", Kent Watsen, Gary Wu,\n  Liang Xia, 2019-11-20, <draft-ietf-netconf-ssh-client-server-17.txt>\n\n      This document defines three YANG modules: the first defines groupings\n      for a generic SSH client, the second defines groupings for a generic\n      SSH server, and the third defines common identities and groupings\n      used by both the client and the server.  It is intended that these\n      groupings will be used by applications using the SSH protocol.\n\n  "NETCONF Client and Server Models", Kent Watsen, 2019-11-20,\n  <draft-ietf-netconf-netconf-client-server-17.txt>\n\n      This document defines two YANG modules, one module to configure a\n      NETCONF client and the other module to configure a NETCONF server.\n      Both modules support both the SSH and TLS transport protocols, and\n      support both standard NETCONF and NETCONF Call Home connections.\n      \n      Editorial Note (To be removed by RFC Editor)\n      \n      This draft contains many placeholder values that need to be replaced\n      with finalized values at the time of publication.  This note\n      summarizes all of the substitutions that are needed.  No other RFC\n      Editor instructions are specified elsewhere in this document.\n      \n      This document contains references to other drafts in progress, both\n      in the Normative References section, as well as in body text\n      throughout.  Please update the following references to reflect their\n      final RFC assignments:\n      \n      o  I-D.ietf-netconf-keystore\n      \n      o  I-D.ietf-netconf-tcp-client-server\n      \n      o  I-D.ietf-netconf-ssh-client-server\n      \n      o  I-D.ietf-netconf-tls-client-server\n      \n      Artwork in this document contains shorthand references to drafts in\n      progress.  Please apply the following replacements:\n      \n      o  "XXXX" --> the assigned RFC value for this draft\n      \n      o  "AAAA" --> the assigned RFC value for I-D.ietf-netconf-tcp-client-\n      server\n      \n      o  "YYYY" --> the assigned RFC value for I-D.ietf-netconf-ssh-client-\n      server\n      \n      o  "ZZZZ" --> the assigned RFC value for I-D.ietf-netconf-tls-client-\n      server\n      \n      Artwork in this document contains placeholder values for the date of\n      publication of this draft.  Please apply the following replacement:\n      \n      o  "2019-11-20" --> the publication date of this draft\n      \n      The following Appendix section is to be removed prior to publication:\n      \n      o  Appendix B.  Change Log\n\n  "A YANG Data Model for a Keystore", Kent Watsen, 2019-11-20,\n  <draft-ietf-netconf-keystore-15.txt>\n\n      This document defines a YANG 1.1 module called "ietf-keystore" that\n      enables centralized configuration of both symmetric and asymmetric\n      keys.  The secret value for both key types may be encrypted.\n      Asymmetric keys may be associated with certificates.  Notifications\n      are sent when certificates are about to expire.\n      \n      Editorial Note (To be removed by RFC Editor)\n      \n      This draft contains many placeholder values that need to be replaced\n      with finalized values at the time of publication.  This note\n      summarizes all of the substitutions that are needed.  No other RFC\n      Editor instructions are specified elsewhere in this document.\n      \n      Artwork in this document contains shorthand references to drafts in\n      progress.  Please apply the following replacements:\n      \n      o  "AAAA" --> the assigned RFC value for\n      [I-D.ietf-netconf-crypto-types].\n      \n      o  "XXXX" --> the assigned RFC value for this draft\n      \n      Artwork in this document contains placeholder values for the date of\n      publication of this draft.  Please apply the following replacement:\n      \n      o  "2019-11-20" --> the publication date of this draft\n      \n      The following Appendix section is to be removed prior to publication:\n      \n      o  Appendix A.  Change Log\n\n  "Notification Message Headers and Bundles", Eric Voit, Tim Jenkins, Henk\n  Birkholz, Andy Bierman, Alexander Clemm, 2019-11-17,\n  <draft-ietf-netconf-notification-messages-08.txt>\n\n      This document defines a new notification message format.  Included\n      are:\n      \n      o  a new notification mechanism and encoding to replace the one way\n      operation of RFC-5277\n      \n      o  a set of common, transport agnostic message header objects.\n      \n      o  how to bundle multiple event records into a single notification\n      message.\n      \n      o  how to ensure these new capabilities are only used with capable\n      receivers.\n\n  "Common YANG Data Types for Cryptography", Kent Watsen, HAIGUANG Wang,\n  2019-11-20, <draft-ietf-netconf-crypto-types-13.txt>\n\n      This document defines four YANG modules for types useful to\n      cryptographic applications.  The modules defined include:\n      \n      o  ietf-crypto-types\n      \n      o  iana-symmetric-algs\n      \n      o  iana-asymmetric-algs\n      \n      o  iana-hash-algs\n\n  "A YANG Data Model for a Truststore", Kent Watsen, 2019-11-20,\n  <draft-ietf-netconf-trust-anchors-08.txt>\n\n      This document defines a YANG 1.1 data model for configuring global\n      sets of X.509 certificates, SSH host-keys, raw public keys, and PSKs\n      (pairwise-symmetric or pre-shared keys) that can be referenced by\n      other data models for trust.  While the SSH host-keys are uniquely\n      for the SSH protocol, certificates, raw public keys, and PSKs may\n      have multiple uses, including authenticating protocol peers and\n      verifying signatures.\n\n  "Generic YANG-related System Capabilities and YANG-Push Notification\n  Capabilities", Balazs Lengyel, Alexander Clemm, Benoit Claise, 2020-01-16,\n  <draft-ietf-netconf-notification-capabilities-10.txt>\n\n      This document proposes two YANG modules.  The module ietf-system-\n      capabilities provides a structure that can be used to specify any\n      YANG related system capability.\n      \n      The module ietf-notification-capabilities allows a publisher to\n      specify capabilities related to "Subscription to YANG Datastores"\n      (YANG-Push).  It proposes to use YANG Instance Data to document this\n      information and make it already available at implementation-time, but\n      also allow it to be reported at run-time.\n\n  "YANG Groupings for TCP Clients and TCP Servers", Kent Watsen, Michael\n  Scharf, 2019-10-18, <draft-ietf-netconf-tcp-client-server-03.txt>\n\n      This document defines three YANG modules: the first defines a\n      grouping for configuring a generic TCP client, the second defines a\n      grouping for configuring a generic TCP server, and the third defines\n      a grouping common to the TCP clients and TCP servers.\n\n  "An HTTPS-based Transport for Configured Subscriptions", Mahesh\n  Jethanandani, Kent Watsen, 2019-10-30,\n  <draft-ietf-netconf-https-notif-01.txt>\n\n      This document defines a YANG data module for configuring HTTPS based\n      configured subscription, as defined in Subscribed Notifications\n      (RFC8639).  The use of HTTPS maximizes transport-level\n      interoperability, while allowing for encoding selection from text,\n      e.g.  XML or JSON, to binary.\n\n  "YANG Groupings for HTTP Clients and HTTP Servers", Kent Watsen,\n  2019-11-20, <draft-ietf-netconf-http-client-server-01.txt>\n\n      This document defines two YANG modules: the first defines a minimal\n      grouping for configuring an HTTP client, and the second defines a\n      minimal grouping for configuring an HTTP server.  It is intended that\n      these groupings will be used to help define the configuration for\n      simple HTTP-based protocols (not for complete webservers or\n      browsers).\n\nNetwork Modeling (netmod)\n-------------------------\n\n  "A YANG Data Model for Syslog Configuration", Clyde Wildes, Kiran Koushik,\n  2018-03-16, <draft-ietf-netmod-syslog-model-26.txt>\n\n      This document defines a YANG data model for the configuration of a\n      syslog process.  It is intended this model be used by vendors who\n      implement syslog in their systems.\n\n  "Common Interface Extension YANG Data Models", Robert Wilton, David Ball,\n  tapsingh@cisco.com, Selvakumar Sivaraj, 2019-11-04,\n  <draft-ietf-netmod-intf-ext-yang-08.txt>\n\n      This document defines two YANG modules that augment the Interfaces\n      data model defined in the "YANG Data Model for Interface Management"\n      with additional configuration and operational data nodes to support\n      common lower layer interface properties, such as interface MTU.\n      \n      The YANG modules in this document conform to the Network Management\n      Datastore Architecture (NMDA) defined in RFC 8342.\n\n  "Sub-interface VLAN YANG Data Models", Robert Wilton, David Ball,\n  tapsingh@cisco.com, Selvakumar Sivaraj, 2019-11-04,\n  <draft-ietf-netmod-sub-intf-vlan-model-06.txt>\n\n      This document defines YANG modules to add support for classifying\n      traffic received on interfaces as Ethernet/VLAN framed packets to\n      sub-interfaces based on the fields available in the Ethernet/VLAN\n      frame headers.  These modules allow configuration of Layer 3 and\n      Layer 2 sub-interfaces (e.g. attachment circuits) that can\n      interoperate with IETF based forwarding protocols; such as IP and\n      L3VPN services; or L2VPN services like VPWS, VPLS, and EVPN.  The\n      sub-interfaces also interoperate with VLAN tagged traffic orginating\n      from an IEEE 802.1Q compliant bridge.\n      \n      The model differs from an IEEE 802.1Q bridge model in that the\n      configuration is interface/sub-interface based as opposed to being\n      based on membership of an 802.1Q VLAN bridge.\n      \n      The YANG data models in this document conforms to the Network\n      Management Datastore Architecture (NMDA) defined in RFC 8342.\n\n  "YANG Data Structure Extensions", Andy Bierman, Martin Bjorklund, Kent\n  Watsen, 2019-12-09, <draft-ietf-netmod-yang-data-ext-05.txt>\n\n      This document describes YANG mechanisms for defining abstract data\n      structures with YANG.\n\n  "YANG Module Tags", Christian Hopps, Lou Berger, Dean Bogdanovic,\n  2019-09-25, <draft-ietf-netmod-module-tags-09.txt>\n\n      This document provides for the association of tags with YANG modules.\n      The expectation is for such tags to be used to help classify and\n      organize modules.  A method for defining, reading and writing a\n      modules tags is provided.  Tags may be registered and assigned during\n      module definition; assigned by implementations; or dynamically\n      defined and set by users.  This document also provides guidance to\n      future model writers; as such, this document updates RFC8407.\n\n  "Comparison of NMDA datastores", Alexander Clemm, Yingzhen Qu, Jeff\n  Tantsura, Andy Bierman, 2019-11-04, <draft-ietf-netmod-nmda-diff-03.txt>\n\n      This document defines an RPC operation to compare management\n      datastores that comply with the NMDA architecture.\n\n  "Handling Long Lines in Inclusions in Internet-Drafts and RFCs", Kent\n  Watsen, Erik Auerswald, Adrian Farrel, Qin WU, 2020-01-20,\n  <draft-ietf-netmod-artwork-folding-12.txt>\n\n      This document defines two strategies for handling long lines in\n      width-bounded text content.  One strategy is based on the historical\n      use of a single backslash (\'\\\') character to indicate where line-\n      folding has occurred, with the continuation occurring with the first\n      non-space (\' \') character on the next line.  The second strategy\n      extends the first strategy by adding a second backslash character to\n      identify where the continuation begins and is thereby able to handle\n      cases not supported by the first strategy.  Both strategies use a\n      self-describing header enabling automated reconstitution of the\n      original content.\n\n  "YANG Instance Data File Format", Balazs Lengyel, Benoit Claise,\n  2019-12-04, <draft-ietf-netmod-yang-instance-file-format-06.txt>\n\n      There is a need to document data defined in YANG models when a live\n      server is not available.  Data is often needed already at design or\n      implementation time or needed by groups that do not have a live\n      running server available.  This document specifies a standard file\n      format for YANG instance data (which follows the syntax and semantic\n      from existing YANG models, re-using the same format as the reply to a\n      <get> operation/request) and annotates it with metadata.\n\n  "YANG Module Versioning Requirements", Joe Clarke, 2019-12-30,\n  <draft-ietf-netmod-yang-versioning-reqs-02.txt>\n\n      This document describes the problems that can arise because of the\n      YANG language module update rules, that require all updates to YANG\n      module preserve strict backwards compatibility.  It also defines the\n      requirements on any solution designed to solve the stated problems.\n      This document does not consider possible solutions, nor endorse any\n      particular solution.\n\n  "Common YANG Data Types", Juergen Schoenwaelder, 2019-11-04,\n  <draft-ietf-netmod-rfc6991-bis-02.txt>\n\n      This document introduces a collection of common data types to be used\n      with the YANG data modeling language.  This document obsoletes RFC\n      6991.\n\n  "YANG Geo Location", Christian Hopps, 2019-11-04,\n  <draft-ietf-netmod-geo-location-02.txt>\n\n      This document defines a generic geographical location object YANG\n      grouping.  The geographical location grouping is intended to be used\n      in YANG models for specifying a location on or in reference to the\n      Earth or any other astronomical object.\n\n  "Factory Default Setting", Qin WU, Balazs Lengyel, Ye Niu, 2019-12-06,\n  <draft-ietf-netmod-factory-default-09.txt>\n\n      This document defines a method to reset a server to its factory-\n      default content.  The reset operation may be used, e.g., when the\n      existing configuration has major errors so re-starting the\n      configuration process from scratch is the best option.\n      \n      A new factory-reset RPC is defined.  When resetting a datastore, all\n      previous configuration settings will be lost and replaced by the\n      factory-default content.\n      \n      A new optional "factory-default" read-only datastore is defined, that\n      contains the data that will be copied over to the running datastore\n      at reset.\n\nInternet Video Codec (netvc)\n----------------------------\n\n  "Video Codec Requirements and Evaluation Methodology", Alexey Filippov,\n  Andrey Norkin, jose.roberto.alvarez@huawei.com, 2019-11-21,\n  <draft-ietf-netvc-requirements-10.txt,.pdf>\n\n      This document provides requirements for a video codec designed\n      mainly for use over the Internet. In addition, this document\n      describes an evaluation methodology needed for measuring the\n      compression efficiency to ensure whether the stated requirements are\n      fulfilled or not.\n\n  "Video Codec Testing and Quality Measurement", Thomas Daede, Andrey Norkin,\n  Ilya Brailovskiy, 2019-01-25, <draft-ietf-netvc-testing-08.txt>\n\n      This document describes guidelines and procedures for evaluating a\n      video codec.  This covers subjective and objective tests, test\n      conditions, and materials used for the test.\n\nNetwork File System Version 4 (nfsv4)\n-------------------------------------\n\n  "Integrity Measurement for Network File System version 4", Chuck Lever,\n  2019-10-01, <draft-ietf-nfsv4-integrity-measurement-07.txt>\n\n      This document specifies an OPTIONAL extension to NFS version 4 minor\n      version 2 that enables Linux Integrity Measurement Architecture\n      metadata (IMA) to be conveyed between NFS version 4.2 servers and\n      clients.  Integrity measurement authenticates the creator of a file\'s\n      content and helps guarantee the content\'s integrity end-to-end from\n      creation to use.\n\n  "RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1", Chuck\n  Lever, 2020-01-02, <draft-ietf-nfsv4-rpcrdma-cm-pvt-data-06.txt>\n\n      This document specifies the format of RDMA-CM Private Data exchanged\n      between RPC-over-RDMA version 1 peers as part of establishing a\n      connection.  The addition of the private data payload specified in\n      this document is an optional extension that does not alter the RPC-\n      over-RDMA version 1 protocol.  This document updates RFC 8166.\n\n  "Towards Remote Procedure Call Encryption By Default", Trond Myklebust,\n  Chuck Lever, 2020-01-10, <draft-ietf-nfsv4-rpc-tls-05.txt>\n\n      This document describes a mechanism that, through the use of\n      opportunistic Transport Layer Security (TLS), enables encryption of\n      in-transit Remote Procedure Call (RPC) transactions while\n      interoperating with ONC RPC implementations that do not support this\n      mechanism.  This document updates RFC 5531.\n\n  "Network File System (NFS) Version 4 Minor Version 1 Protocol", David\n  Noveck, Chuck Lever, 2019-10-20,\n  <draft-ietf-nfsv4-rfc5661sesqui-msns-03.txt>\n\n      This document describes the Network File System (NFS) version 4 minor\n      version 1, including features retained from the base protocol (NFS\n      version 4 minor version 0, which is specified in RFC 7530) and\n      protocol extensions made subsequently.  The later minor version has\n      no dependencies on NFS version 4 minor version 0, and is considered a\n      separate protocol.\n      \n      This document obsoletes RFC5661.  It substantialy revises the\n      treatment of features relating to multi-server namesapce superseding\n      the description of those features appearing in RFC5661.\n\n  "RPC-over-RDMA Version 2 Protocol", Chuck Lever, David Noveck, 2020-01-17,\n  <draft-ietf-nfsv4-rpcrdma-version-two-01.txt>\n\n      This document specifies the second version of a transport protocol\n      that conveys Remote Procedure Call (RPC) messages using Remote Direct\n      Memory Access (RDMA).  This version of the protocol is extensible.\n\n  "Network File System (NFS) Upper Layer Binding To RPC-Over-RDMA Version 2",\n  Chuck Lever, 2019-11-17, <draft-ietf-nfsv4-nfs-ulb-v2-00.txt>\n\n      This document specifies Upper Layer Bindings of Network File System\n      (NFS) protocol versions to RPC-over-RDMA version 2.\n\nNetwork Management (nmrg)\n-------------------------\n\n  "Intent Classification", Chen Li, Olga Havel, Will LIU, Pedro\n  Martinez-Julia, Jeferson Nobre, Diego Lopez, 2019-11-18,\n  <draft-li-nmrg-intent-classification-02.txt>\n\n      RFC7575 defines Intent as an abstract high-level policy used to\n      operate the network. Intent management system includes an interface\n      for users to input requests and an engine to translate the intents\n      into the network configuration and manage their lifecycle. Up to\n      now, there is no commonly agreed definition, interface or model of\n      intent.\n      \n      This document discusses what intent means to different stakeholders,\n      describes different ways to classify intent, and an associated\n      taxonomy of this classification. This is a foundation for discussion\n      intent related topics.\n\n  "Intent-Based Networking - Concepts and Definitions", Alexander Clemm,\n  Laurent Ciavaglia, Lisandro Granville, Jeff Tantsura, 2019-12-25,\n  <draft-irtf-nmrg-ibn-concepts-definitions-00.txt>\n\n      Intent and Intent-Based Networking are taking the industry by storm.\n      At the same time, those terms are used loosely and often\n      inconsistently, in many cases overlapping and confused with other\n      concepts such as "policy".  This document is intended to clarify the\n      concept of "Intent" and provide an overview of functionality that\n      associated with it.  The goal is to contribute towards a common and\n      shared understanding of terms, concepts, and functionality which can\n      be used as foundation to guide further definition of associated\n      research and engineering problems and their solutions.\n\nIndividual Submissions (none)\n-----------------------------\n\n  "The ARK Identifier Scheme", John Kunze, Emmanuelle Bermes, 2019-12-20,\n  <draft-kunze-ark-23.txt>\n\n      The ARK (Archival Resource Key) naming scheme is designed to\n      facilitate the high-quality and persistent identification of\n      information objects.  A founding principle of the ARK is that\n      persistence is purely a matter of service and is neither inherent in\n      an object nor conferred on it by a particular naming syntax.  The\n      best that an identifier can do is to lead users to the services that\n      support robust reference.  The term ARK itself refers both to the\n      scheme and to any single identifier that conforms to it.  An ARK has\n      five components:\n      \n      [http://NMAH/]ark:[/]NAAN/Name[Qualifier]\n      \n      an optional and mutable Name Mapping Authority Hostport (usually a\n      hostname), the "ark:" label, the Name Assigning Authority Number\n      (NAAN), the assigned Name, and an optional and possibly mutable\n      Qualifier supported by the NMA.  The NAAN and Name together form the\n      immutable persistent identifier for the object independent of the URL\n      hostname.  An ARK is a special kind of URL that connects users to\n      three things: the named object, its metadata, and the provider\'s\n      promise about its persistence.  When entered into the location field\n      of a Web browser, the ARK leads the user to the named object.  That\n      same ARK, inflected by appending `?info\', returns a metadata record\n      that is both human- and machine-readable.  The returned record\n      contains core metadata and a commitment statement from the current\n      provider.  Tools exist for minting, binding, and resolving ARKs.\n\n  "An IPv4 Flowlabel Option", Thomas Dreibholz, 2019-09-10,\n  <draft-dreibholz-ipv4-flowlabel-30.txt>\n\n      This draft defines an IPv4 option containing a flowlabel that is\n      compatible to IPv6.  It is required for simplified usage of IntServ\n      and interoperability with IPv6.\n\n  "EAP Support in Smartcard", Pascal Urien, Guy Pujolle, 2019-12-15,\n  <draft-urien-eap-smartcard-38.txt>\n\n      This document describes the functional interface, based on the\n      ISO7816 standard, to EAP methods, fully and securely executed in\n      smart cards. This class of tamper resistant device may deliver\n      client or server services; it can compute Root Keys from an Extended\n      Master Session Key (EMSK).\n\n  "Prepaid Extensions to Remote Authentication Dial-In User Service\n  (RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig,\n  Andreas Pashalidis, 2013-02-25,\n  <draft-lior-radius-prepaid-extensions-22.txt>\n\n      This document specifies an extension to the Remote Authentication\n      Dial-In User Service (RADIUS) protocol that enables service providers\n      to charge for prepaid services.  The supported charging models\n      supported are volume-based, duration-based, and based on one-time\n      events.\n\n  "Apple\'s DNS Long-Lived Queries protocol", Stuart Cheshire, Marc Krochmal,\n  2019-08-22, <draft-sekar-dns-llq-06.txt>\n\n      Apple\'s DNS Long-Lived Queries protocol (LLQ) is a protocol for\n      extending the DNS protocol to support change notification, thus\n      allowing clients to learn about changes to DNS data without polling\n      the server.  From 2005 onwards, LLQ was implemented in Apple products\n      including Mac OS X, Bonjour for Windows, and AirPort wireless base\n      stations.  In 2019, the LLQ protocol was superseded by the IETF\n      Standards Track RFC xxxx [[RFC Editor note: Please replace xxxx with\n      RFC number]] "DNS Push Notifications", which builds on experience\n      gained with the LLQ protocol to create a superior replacement.\n      \n      The existing LLQ protocol deployed and used from 2005 to 2019 is\n      documented here to give background regarding the operational\n      experience that informed the development of DNS Push Notifications,\n      and to help facilitate a smooth transition from LLQ to DNS Push\n      Notifications.\n\n  "Applicability of Reliable Server Pooling for Real-Time Distributed\n  Computing", Thomas Dreibholz, 2019-09-10,\n  <draft-dreibholz-rserpool-applic-distcomp-27.txt>\n\n      This document describes the applicability of the Reliable Server\n      Pooling architecture to manage real-time distributed computing pools\n      and access the resources of such pools.\n\n  "Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz,\n  2019-09-10, <draft-hohendorf-secure-sctp-28.txt>\n\n      This document explains the reason for the integration of security\n      functionality into SCTP, and gives a short description of S-SCTP and\n      its services.  S-SCTP is fully compatible with SCTP defined in\n      RFC4960, it is designed to integrate cryptographic functions into\n      SCTP.\n\n  "Applicability of Reliable Server Pooling for SCTP-Based Endpoint\n  Mobility", Thomas Dreibholz, Jobin Pulinthanath, 2019-09-10,\n  <draft-dreibholz-rserpool-applic-mobility-26.txt>\n\n      This document describes a novel mobility concept based on a\n      combination of SCTP with Dynamic Address Reconfiguration extension\n      and Reliable Server Pooling (RSerPool).\n\n  "Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz,\n  Michael Tuexen, 2019-09-10, <draft-dreibholz-rserpool-score-25.txt>\n\n      This memo describes some of the scoring to be used in the testing of\n      Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.\n\n  "Handle Resolution Option for ASAP", Thomas Dreibholz, 2019-09-10,\n  <draft-dreibholz-rserpool-asap-hropt-25.txt>\n\n      This document describes the Handle Resolution option for the ASAP\n      protocol.\n\n  "Definition of a Delay Measurement Infrastructure and Delay-Sensitive\n  Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing\n  Zhou, 2019-09-10, <draft-dreibholz-rserpool-delay-24.txt>\n\n      This document contains the definition of a delay measurement\n      infrastructure and a delay-sensitive Least-Used policy for Reliable\n      Server Pooling.\n\n  "BGP Class of Service Interconnection", Thomas Knoll, 2019-11-18,\n  <draft-knoll-idr-cos-interconnect-23.txt>\n\n      This document focuses on Class of Service Interconnection at inter-\n      domain interconnection points.  It specifies two new transitive\n      attributes, which enable adjacent peers to signal Class of Service\n      Capabilities and certain Class of Service admission control\n      Parameters.  The new "CoS Capability" is deliberately kept simple and\n      denotes the general EF, AF Group BE and LE forwarding support across\n      the advertising AS.  The second "CoS Parameter Attribute" is of\n      variable length and contains a more detailed description of available\n      forwarding behaviours using the PHB id Code encoding.  Each PHB id\n      Code is associated with rate and size based traffic parameters, which\n      will be applied in the ingress AS Border Router for admission control\n      purposes to a given forwarding behaviour.\n\n  "Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas\n  Dreibholz, Xing Zhou, 2019-09-10,\n  <draft-dreibholz-rserpool-enrp-takeover-22.txt>\n\n      This document describes the Takeover Suggestion Flag for the\n      ENRP_HANDLE_UPDATE message of the ENRP protocol.\n\n  "The i;codepoint collation", Bjoern Hoehrmann, 2010-09-14,\n  <draft-hoehrmann-cp-collation-01.txt>\n\n      This memo describes the "i;codepoint" collation.  Character strings\n      are compared based on the Unicode scalar values of the characters.\n      The collation supports equality, substring, and ordering operations.\n\n  "A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)",\n  PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo, 2018-06-06,\n  <draft-spinosa-urn-lex-13.txt>\n\n      This document describes a Uniform Resource Name (URN) Namespace\n      Identification (NID) convention as prescribed by the Internet\n      Engineering Task Force (IETF) for identifying, naming, assigning, and\n      managing persistent resources in the legal domain.\n\n  "Xon/Xoff State Control for Telnet Com Port Control Option", Grant Edwards,\n  2010-03-23, <draft-edwards-telnet-xon-xoff-state-control-00.txt,.pdf>\n\n      This document defines new values for use with the telnet com port\n      control option\'s SET-CONTROL sub-command defined in RFC2217.  These\n      new values provide a mechanism for the telnet client to control and\n      query the outbound Xon/Xoff flow control state of the telnet server\'s\n      physical serial port.  This capability is exposed in the serial port\n      API on some operating systems and is needed by telnet clients that\n      implement a port-redirector service which provides applications local\n      to the redirector/telnet-client with transparent access to the remote\n      serial port on the telnet server.\n\n  "Load Sharing for the Stream Control Transmission Protocol (SCTP)", Paul\n  Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi\n  Natarajan, Randall Stewart, Michael Tuexen, 2020-01-23,\n  <draft-tuexen-tsvwg-sctp-multipath-19.txt>\n\n      The Stream Control Transmission Protocol (SCTP) supports multi-homing\n      for providing network fault tolerance.  However, mainly one path is\n      used for data transmission.  Only timer-based retransmissions are\n      carried over other paths as well.\n      \n      This document describes how multiple paths can be used simultaneously\n      for transmitting user messages.\n\n  "Intelligent OSPF Link State Database Exchange", Huaimo Chen, 2019-10-02,\n  <draft-chen-ospf-intelligent-db-exch-03.txt>\n\n      This document presents an intelligent database exchange mechanism for\n      the database exchange procedure in OSPFv2 and OSPFv3.  This mechanism\n      is backward compatible.  It eliminates the unnecessary database\n      exchanges through using the existing reachability information\n      calculated from the link state database and the un-reachability\n      information about routers recorded.  It significantly speeds up the\n      establishment of the full adjacency between two routers in some\n      situations.\n\n  "Clarification of Proper Use of "@" (at sign) in URI-style Components",\n  Robert Simpson, 2010-07-30, <draft-accilent-at-sign-00.txt>\n\n      Defacto standards have evolved that conflict with existing standards,\n      specifically RFC 3986.  This document clarifies the use of the "@"\n      (at sign) in URIs and partial URI-like addresses.\n\n  "Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G\n  Authentication and Key Agreement (AKA)", Lionel Morand, 2014-04-14,\n  <draft-morand-http-digest-2g-aka-05.txt>\n\n      This document specifies a one-time password generation mechanism for\n      Hypertext Transfer Protocol (HTTP) Digest access authentication based\n      on Global System for Mobile Communications (GSM) authentication and\n      key generation functions A3 and A8, also known as GSM AKA or 2G AKA.\n      The HTTP Authentication Framework includes two authentication\n      schemes: Basic and Digest.  Both schemes employ a shared secret based\n      mechanism for access authentication.  The GSM AKA mechanism performs\n      user authentication and session key distribution in GSM and Universal\n      Mobile Telecommunications System (UMTS) networks.  GSM AKA is a\n      challenge-response based mechanism that uses symmetric cryptography.\n\n  "Extensions to Path Computation Element Communication Protocol (PCEP) for\n  Backup Ingress of a Traffic Engineering Label Switched Path", Huaimo Chen,\n  2020-01-06, <draft-chen-pce-compute-backup-ingress-15.txt>\n\n      This document presents extensions to the Path Computation Element\n      Communication Protocol (PCEP) for a PCC to send a request for\n      computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P\n      LSP to a PCE and for a PCE to compute the backup ingress and reply to\n      the PCC with a computation result for the backup ingress.\n\n  "Extensions to the Path Computation Element Communication Protocol (PCEP)\n  for Backup Egress of a Traffic Engineering Label Switched Path", Huaimo\n  Chen, 2020-01-06, <draft-chen-pce-compute-backup-egress-15.txt>\n\n      This document presents extensions to the Path Computation Element\n      Communication Protocol (PCEP) for a PCC to send a request for\n      computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P\n      LSP to a PCE and for a PCE to compute the backup egress and reply to\n      the PCC with a computation result for the backup egress.\n\n  "OSPF Abnormal State Information", Huaimo Chen, 2019-10-02,\n  <draft-chen-ospf-abnormal-state-info-03.txt>\n\n      This document describes a couple of options for an OSPF router to\n      advertise its abnormal state information in a routing domain.\n\n  "Sender Queue Info Option for the SCTP Socket API", Thomas Dreibholz, Robin\n  Seggelmann, Martin Becke, 2019-09-10,\n  <draft-dreibholz-tsvwg-sctpsocket-sqinfo-19.txt>\n\n      This document describes an extension to the SCTP sockets API for\n      querying information about the sender queue.\n\n  "SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas\n  Dreibholz, Martin Becke, Hakim Adhari, 2019-09-10,\n  <draft-dreibholz-tsvwg-sctpsocket-multipath-19.txt>\n\n      This document describes extensions to the SCTP sockets API for\n      configuring the CMT-SCTP and CMT/RP-SCTP extensions.\n\n  "Encoding the graphemes of the SignWriting Script with the x-ISWA-2010",\n  Stephen Slevinski, Valerie Sutton, 2011-01-03,\n  <draft-slevinski-iswa-2010-00.txt>\n\n      For concreteness, because the universal character set is not yet\n      universal, because an undocumented and unlabeled coded character set\n      hampers information interchange, a 12-bit coded character set has\n      been created that encodes the graphemes of the SignWriting script as\n      described in the open standard of the International SignWriting\n      Alphabet 2010.  The x-ISWA-2010 coded character set is defined with\n      hexadecimal characters and described with Unicode characters, either\n      proposed characters on plane 1 or interchange characters on plane 15.\n      \n      This memo defines a standard coded character set for the Internet\n      community.  It is published for reference, examination,\n      implementation, and evaluation.  Distribution of this memo is\n      unlimited.\n\n  "The Quality for Service Protocol", Jose Aranda, Monica Cortes, Joaquin\n  Salvachua, Tecnalia Innovation, Inaki Sarriegui, 2019-07-05,\n  <draft-aranda-dispatch-q4s-10.txt,.pdf>\n\n      This memo describes an application level protocol for the\n      communication of end-to-end QoS compliance information based on\n      the   Hypertext Transfer Protocol (HTTP) and the Session\n      Description Protocol (SDP).  The Quality for Service Protocol\n      (Q4S) provides a mechanism to negotiate and monitor latency,\n      jitter, bandwidth, and packet, and to alert whenever one of the\n      negotiated conditions is violated.\n      \n      Implementation details on the actions to be triggered upon\n      reception/detection of QoS alerts exchanged by the protocol are\n      out of scope of this document, it is application dependent (e.g.,\n      act to increase quality or reduce bit-rate) or network dependent\n      (e.g., change connection\'s quality profile).\n      \n      This protocol specification is the product of research conducted\n      over a number of years, and is presented here as a permanent\n      record and to offer a foundation for future similar work.  It does\n      not represent a standard protocol and does not have IETF\n      consensus.\n\n  "A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo Chen,\n  2020-01-06, <draft-chen-pce-forward-search-p2p-path-computation-18.txt>\n\n      This document presents a forward search procedure for computing paths\n      for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched\n      Paths (LSPs) crossing a number of domains using multiple Path\n      Computation Elements (PCEs).  In addition, extensions to the Path\n      Computation Element Communication Protocol (PCEP) for supporting the\n      forward search procedure are described.\n\n  "Route Flap Damping Deployment Status Survey", Shishio Tsuchiya, Seiichi\n  Kawamura, Randy Bush, Cristel Pelsser, 2012-06-21,\n  <draft-shishio-grow-isp-rfd-implement-survey-05.txt>\n\n      BGP Route Flap Damping [RFC2439] is a mechanism that targets route\n      stability.  It penalyzes routes that flap with the aim of reducing\n      CPU load on the routers.\n      \n      But it has side-effects.  Thus, in 2006, RIPE recommended not to use\n      Route Flap Damping (see [RIPE-378]).\n      \n      Now, some researchers propose to turn RFD, with less aggressive\n      parameters, back on [draft-ymbk-rfd-usable].\n      \n      This document describes results of a survey conducted among service\n      provider on their use of BGP Route Flap Damping.\n\n  "A Forward-Search P2MP TE LSP Inter-Domain Path Computation", Huaimo Chen,\n  2020-01-06, <draft-chen-pce-forward-search-p2mp-path-17.txt>\n\n      This document presents a forward search procedure for computing a\n      path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label\n      Switched Path (LSP) crossing a number of domains through using\n      multiple Path Computation Elements (PCEs).  In addition, extensions\n      to the Path Computation Element Communication Protocol (PCEP) for\n      supporting the forward search procedure are described.\n\n  "A SAVI Solution for WLAN", Jun Bi, Jianping Wu, You Wang, Tao Lin,\n  2019-11-17, <draft-bi-savi-wlan-18.txt>\n\n      This document describes a source address validation solution for WLAN\n      enabling 802.11i or other security mechanisms.  This mechanism snoops\n      NDP and DHCP packets to bind IP address to MAC address, and relies on\n      the security of MAC address guaranteed by 802.11i or other mechanisms\n      to filter IP spoofing packets.  It can work in the special situations\n      described in the charter of SAVI(Source Address Validation\n      Improvements) workgroup, such as multiple MAC addresses on one\n      interface.  This document describes three different deployment\n      scenarios, with solutions for migration of binding entries when hosts\n      move from one access point to another.\n\n  "A Taxonomy on Private Use Fields in Protocols", Chris Lonvick, 2019-10-17,\n  <draft-lonvick-private-tax-18.txt>\n\n      This document discusses how private use fields in IETF protocols are\n      used.\n\n  "An Extension Language for the DNS", John Levine, Paul Vixie, 2019-10-12,\n  <draft-levine-dnsextlang-12.txt>\n\n      Adding new RRTYPEs to the DNS has required that DNS servers and\n      provisioning software be upgraded to support each new RRTYPE in\n      Master files.  This document defines a DNS extension language\n      intended to allow most new RRTYPEs to be supported by adding entries\n      to configuration data read by the DNS software, with no software\n      changes needed for each RRTYPE.\n\n  "Unified User-Agent String", Mateusz Karcz, 2014-11-10,\n  <draft-karcz-uuas-01.txt>\n\n      User-Agent is a HTTP request-header field. It contains information\n      about the user agent originating the request, which is often used by\n      servers to help identify the scope of reported interoperability\n      problems, to work around or tailor responses to avoid particular user\n      agent limitations, and for analytics regarding browser or operating\n      system use. Over the years contents of this field got complicated\n      and ambiguous. That was the reaction for sending altered version of\n      websites to web browsers other than popular ones. During the\n      development of the WWW, authors of the new web browsers used to\n      construct User-Agent strings similar to Netscape\'s one. Nowadays\n      contents of the User-Agent field are much longer than 15 years ago.\n      This Memo proposes the Uniform User-Agent String as a way to simplify\n      the User-Agent field contents, while maintaining the previous\n      possibility of their use.\n\n  "SNMPD to use cache and shared database based on MIB Classification",\n  Haresh Khandelwal, 2012-03-29,\n  <draft-haresh-sushrut-mib-classification-01.txt>\n\n      This memo defines classification of SNMP MIBs to either use SNMP\n      cache database and shared database (SDB) mechanism to reduce high CPU\n      usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are\n      continuously performed from network management system (NMS)/SNMP\n      manager/SNMP MIB browser to managed device.\n\n  "Analysis of Algorithms For Deriving Port Sets", Tina Tsou, Tetsuya\n  Murakami, Simon Perreault, 2013-05-17,\n  <draft-tsou-softwire-port-set-algorithms-analysis-04.txt>\n\n      This memo analyzes some port set definition algorithms used for\n      stateless IPv4 to IPv6 transition technologies.  The transition\n      technologies using port set algorithms can be divided into two\n      categories: fully stateless approach and binding approach.  Some\n      algorithms can work for both approaches.\n\n  "The Applicability of the PCE to Computing Protection and Recovery Paths\n  for Single Domain and Multi-Domain Networks.", Huaimo Chen, 2019-10-02,\n  <draft-chen-pce-protection-applicability-13.txt>\n\n      The Path Computation Element (PCE) provides path computation\n      functions in support of traffic engineering in Multiprotocol Label\n      Switching (MPLS) and Generalized MPLS (GMPLS) networks.\n      \n      A link or node failure can significantly impact network services in\n      large-scale networks.  Therefore it is important to ensure the\n      survivability of large scale networks which consist of various\n      connections provided over multiple interconnected networks with\n      varying technologies.\n      \n      This document examines the applicability of the PCE architecture,\n      protocols, and procedures for computing protection paths and\n      restoration services, for single and multi-domain networks.\n      \n      This document also explains the mechanism of Fast Re-Route (FRR)\n      where a point of local repair (PLR) needs to find the appropriate\n      merge point (MP) to do bypass path computation using PCE.\n\n  "An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation", Tina\n  Tsou, Simon Perreault, Jing Huang, 2013-09-16,\n  <draft-tsou-behave-ftp46-01.txt>\n\n      An FTP ALG for NAT64 was defined in RFC 6384.  Its scope was limited\n      to an IPv6 client connecting to an IPv4 server.  This memo supports\n      the case of an IPv4 client connecting to an IPv6 server.\n\n  "Web Cache Communication Protocol V2, Revision 1", Douglas McLaggan,\n  2012-08-02, <draft-mclaggan-wccp-v2rev1-00.txt>\n\n      This document describes version 2 of the Web Cache Communication\n      Protocol (WCCP).  The WCCP V2 protocol specifies interactions between\n      one or more routers and one or more web-caches.  The interaction may\n      take place within an IPv4 or IPv6 network.  The purpose of the\n      interaction is to establish and maintain the transparent redirection\n      of selected types of traffic flowing through a group of routers (or\n      similar devices).  The selected traffic is redirected to a group of\n      web-caches (or other traffic optimisation devices) with the aim of\n      optimising resource usage and lowering response times.\n      \n      The protocol does not specify any interaction between the web-caches\n      within a group or between a web-cache and a web-server.\n\n  "Design Discussion and Comparison of Protection Mechanisms for Replay\n  Attack and Withdrawal Suppression in BGPsec", Kotikalapudi Sriram, Doug\n  Montgomery, 2019-10-22,\n  <draft-sriram-replay-protection-design-discussion-13.txt>\n\n      In the context of BGPsec, a withdrawal suppression occurs when an\n      adversary AS suppresses a prefix withdrawal with the intension of\n      continuing to attract traffic for that prefix based on a previous\n      (signed and valid) BGPsec announcement that was earlier propagated.\n      Subsequently if the adversary AS had a BGPsec session reset with a\n      neighboring BGPsec speaker and when the session is restored, the AS\n      replays said previous BGPsec announcement (even though it was\n      withdrawn), then such a replay action is called a replay attack.  The\n      BGPsec protocol should incorporate a method for protection from\n      Replay Attack and Withdrawal Suppression (RAWS), at least to control\n      the window of exposure.  This informational document provides design\n      discussion and comparison of multiple alternative RAWS protection\n      mechanisms weighing their pros and cons.  This is meant to be a\n      companion document to the standards track draft-ietf-sidrops-bgpsec-\n      rollover that will specify a method to be used with BGPsec for RAWS\n      protection.\n\n  "The application/stream+json Media Type", James Snell, 2012-10-11,\n  <draft-snell-activity-streams-type-01.txt>\n\n      This specification defines and registers the application/stream+json\n      Content Type for the JSON Activity Streams format.\n\n  "Cryptographic Security Characteristics of 802.11 Wireless LAN Access\n  Systems", Stephen Orr, Anthony Grieco, Dan Harkins, 2012-10-15,\n  <draft-orr-wlan-security-architectures-00.txt>\n\n      This note identifies all of the places that cryptography is used in\n      Wireless Local Area Network (WLAN) architectures, to simplify the\n      task of selecting the protocols, algorithms, and key sizes needed to\n      achieve a consistent security level across the entire architecture.\n\n  "Observations on the experience and nature of Large Interim Meetings", Joel\n  Jaeggli, Jari Arkko, 2013-01-14, <draft-jaeggli-interim-observations-04.txt>\n\n      Planning, particpipation and conclusions from the experience of\n      participating in the IETF LIM activity on september 29th 2012.\n\n  "I-PAKE: Identity-Based Password Authenticated Key Exchange", Taekyoung\n  Kwon, Hyojin Yoon, Sang Kim, 2013-05-03, <draft-kwon-yoon-kim-ipake-01.txt>\n\n      Although password authentication is the most widespread user\n      authentication method today, cryptographic protocols for mutual\n      authentication and key agreement, i.e., password authenticated key\n      exchange (PAKE), in particular authenticated key exchange (AKE) based\n      on a password only, are not actively used in the real world. This\n      document introduces a quite novel form of PAKE protocols that employ\n      a particular concept of ID-based encryption (IBE). The resulting\n      cryptographic protocol is the ID-based password authenticated key\n      exchange (I-PAKE) protocol which is a secure and efficient PAKE\n      protocol in both soft- and hard-augmented models. I-PAKE achieves the\n      security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also\n      achieves the great efficiency by allowing the whole pre-computation\n      of the ephemeral Diffie-Hellman public keys by both server and\n      client.\n\n  "remoteStorage", Michiel de Jong, F. Kooman, 2019-12-09,\n  <draft-dejong-remotestorage-14.txt>\n\n      This draft describes a protocol by which client-side applications,\n      running inside a web browser, can communicate with a data storage\n      server that is hosted on a different domain name. This way, the\n      provider of a web application need not also play the role of data\n      storage provider. The protocol supports storing, retrieving, and\n      removing individual documents, as well as listing the contents of an\n      individual folder, and access control is based on bearer tokens.\n\n  "A Format for Self-published IP Geolocation Feeds", Erik Kline, Krzysztof\n  Duleba, Zoltan Szamonek, Stefan Moser, Warren Kumari, 2020-01-02,\n  <draft-google-self-published-geofeeds-07.txt>\n\n      This document records a format whereby a network operator can publish\n      a mapping of IP address prefixes to simplified geolocation\n      information, colloquially termed a geolocation "feed".  Interested\n      parties can poll and parse these feeds to update or merge with other\n      geolocation data sources and procedures.  This format intentionally\n      only allows specifying coarse level location.\n      \n      Some technical organizations operating networks that move from one\n      conference location to the next have already experimentally published\n      small geolocation feeds.\n      \n      This document describes a currently deployed format.  At least one\n      consumer (Google) has incorporated these feeds into a geolocation\n      data pipeline, and a significant number of ISPs are using it to\n      inform them where their prefixes should be geolocated.\n\n  "Ruoska Encoding", Jukka-Pekka Makela, 2013-10-12,\n  <draft-ruoska-encoding-06.txt>\n\n      This document describes hierarchically structured binary encoding\n      format called Ruoska Encoding (later RSK).  The main design goals are\n      minimal resource usage, well defined structure with good selection of\n      widely known data types, and still extendable for future usage.\n      \n      The main benefit when compared to non binary hierarchically\n      structured formats like XML is simplicity and minimal resource\n      demands.  Even basic XML parsing is time and memory consuming\n      operation.\n      \n      When compared to other binary formats like BER encoding of ASN.1 the\n      main benefit is simplicity.  ASN.1 with many different encodings is\n      complex and even simple implementation needs a lot of effort.  RSK is\n      also more efficient than BER.\n\n  "Topology-Transparent Zone", Huaimo Chen, Alvaro Retana, Renwei Li, Ning\n  So, Vic liu, Mehmet Toy, Lei Liu, 2019-10-09, <draft-chen-isis-ttz-07.txt>\n\n      This document presents a topology-transparent zone in an area.  A\n      zone is a block/piece of an area, which comprises a group of routers\n      and a number of circuits connecting them.  It is abstracted as a\n      virtual entity such as a single pseudo node or zone edges mess.  Any\n      router outside of the zone is not aware of the zone.  The information\n      about the circuits and routers inside the zone is not distributed to\n      any router outside of the zone.\n\n  "ICANN Registry Interfaces", Gustavo Lozano, Eduardo Alvarez, 2019-09-23,\n  <draft-lozano-icann-registry-interfaces-11.txt>\n\n      This document describes the technical details of the interfaces\n      provided by the Internet Corporation for Assigned Names and Numbers\n      (ICANN) to its contracted parties in order to fulfill reporting\n      requirements.  The interfaces provided by ICANN to Data Escrow Agents\n      and Registry Operators to fulfill the requirements of Specifications\n      2 and 3 of the gTLD Base Registry Agreement are also described in\n      this document.\n\n  "Signing HTTP Messages", Mark Cavage, Manu Sporny, 2019-10-21,\n  <draft-cavage-http-signatures-12.txt>\n\n      When communicating over the Internet using the HTTP protocol, it can\n      be desirable for a server or client to authenticate the sender of a\n      particular message.  It can also be desirable to ensure that the\n      message was not tampered with during transit.  This document\n      describes a way for servers and clients to simultaneously add\n      authentication and message integrity to HTTP messages by using a\n      digital signature.\n\n  "Connectivity Provisioning Negotiation Protocol (CPNP)", Mohamed Boucadair,\n  Christian Jacquenet, Dacheng Zhang, Panos Georgatsos, 2019-12-10,\n  <draft-boucadair-connectivity-provisioning-protocol-18.txt>\n\n      This document specifies the Connectivity Provisioning Negotiation\n      Protocol (CPNP) which is designed for dynamic negotiation of service\n      parameters.\n      \n      CPNP is a generic protocol that can be used for various negotiation\n      purposes that include (but are not necessarily limited to)\n      connectivity provisioning services, storage facilities, Content\n      Delivery Networks footprint, etc.  The protocol can be extended with\n      new Information Elements.\n\n  "Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C, JSON-D",\n  Phillip Hallam-Baker, 2019-10-23, <draft-hallambaker-jsonbcd-15.txt>\n\n      Three binary encodings for JavaScript Object Notation (JSON) are\n      presented.  JSON-B (Binary) is a strict superset of the JSON encoding\n      that permits efficient binary encoding of intrinsic JavaScript data\n      types.  JSON-C (Compact) is a strict superset of JSON-B that supports\n      compact representation of repeated data strings with short numeric\n      codes.  JSON-D (Data) supports additional binary data types for\n      integer and floating-point representations for use in scientific\n      applications where conversion between binary and decimal\n      representations would cause a loss of precision.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html [1] .\n\n  "QoS-level aware Transmission Protocol (QTP) for virtual networks", Julong\n  Lan, Dongnian Cheng, Yuxiang Hu, Guozhen Cheng, Tong Duan, 2019-09-17,\n  <draft-lan-nvo3-qtp-10.txt>\n\n      This document provides a QoS-level aware Transmission Protocol (QTP)\n      for virtual networks.\n\n  "Multicast Traceroute for MVPNs", Robert Kebler, Pavan Kurapati, Saud Asif,\n  mankamana mishra, Stig Venaas, 2019-10-21,\n  <draft-kebler-kurapati-l3vpn-mvpn-mtrace-04.txt>\n\n      Mtrace is a tool used to troubleshoot issues in a network deploying\n      Multicast service.  When multicast is used within a VPN service\n      offering, the base Mtrace specification does not detect the failures.\n      This document specifies a method of using multicast traceroute in a\n      network offering Multicast in VPN service.\n\n  "DNSWL Email Authentication Method Extension", Alessandro Vesely,\n  2019-12-20, <draft-vesely-authmethod-dnswl-13.txt>\n\n      This document describes an additional Email Authentication Method\n      compliant with RFC 8601.  The method consists in looking up the\n      sender\'s IP address in a DNS whitelist.  This document is provided\n      for information in case the method is seen in the field, as well as\n      to suggest a useful practice and register the relevant keywords.\n      \n      This document does not consider black lists.\n\n  "RFCTool User Guide", Phillip Hallam-Baker, 2019-12-31,\n  <draft-hallambaker-rfctool-04.txt>\n\n      RFCTool is a documentation tool for building specifications from\n      multiple sources and multiple source formats.  Source formats\n      currently supported are OOXML/Word, Markdown, XML2RFC and SVG.\n      Publication formats supported are plaintext, HTML and XML2RFC.  This\n      document provides information on how to use RFCTool to generate\n      Internet Drafts and RFCs.\n\n  "Remote APDU Call Secure (RACS)", Pascal Urien, 2019-12-15,\n  <draft-urien-core-racs-14.txt>\n\n      This document describes the Remote APDU Call Protocol Secure (RACS)\n      protocol, dedicated to Grid of Secure Elements (GoSE). These servers\n      host Secure Elements (SE), i.e. tamper resistant chips offering\n      secure storage and cryptographic resources.\n      \n      Secure Elements are microcontrollers whose chip area is about 25mm2;\n      they deliver trusted computing services in constrained environments.\n      \n      RACS supports commands for GoSE inventory and data exchange with\n      secure elements. It is designed according to the representational\n      State Transfer (REST) architecture. RACS resources are identified by\n      dedicated URIs. An HTTP interface is also supported.\n      \n      An open implementation [OPENRACS] is available\n      (https://github.com/purien) for various OS.\n\n  "Use of the WebSocket Protocol as a Transport for the Remote Framebuffer\n  Protocol", Nicholas Wilson, 2013-10-07, <draft-realvnc-websocket-02.txt>\n\n      The Remote Framebuffer protocol (RFB) enables clients to connect to\n      and control remote graphical resources.  This document describes a\n      transport for RFB using the WebSocket protocol, and defines a\n      corresponding WebSocket subprotocol, enabling an RFB server to offer\n      resources to clients with WebSocket connectivity, such as web-\n      browsers.\n\n  "Metadata Query Protocol", Ian Young, 2020-01-16,\n  <draft-young-md-query-12.txt>\n\n      This document defines a simple protocol for retrieving metadata about\n      named entities, or named collections of entities.  The goal of the\n      protocol is to profile various aspects of HTTP to allow requesters to\n      rely on certain, rigorously defined, behaviour.\n      \n      This document is a product of the Research and Education Federations\n      (REFEDS) Working Group process.\n\n  "Ideas for a Next Generation of the Reliable Server Pooling Framework",\n  Thomas Dreibholz, 2019-09-10,\n  <draft-dreibholz-rserpool-nextgen-ideas-12.txt>\n\n      This document collects some idea for a next generation of the\n      Reliable Server Pooling framework.\n\n  "The Applicability of Reliable Server Pooling (RSerPool) for Virtual\n  Network Function Resource Pooling (VNFPOOL)", Thomas Dreibholz, Michael\n  Tuexen, Melinda Shore, Ning Zong, 2019-09-10,\n  <draft-dreibholz-vnfpool-rserpool-applic-09.txt>\n\n      This draft describes the application of Reliable Server\n      Pooling (RSerPool) for Virtual Network Function Resource\n      Pooling (VNFPOOL).\n\n  "Extensions to PCEP for Distributing Label Cross Domains", Huaimo Chen,\n  Autumn Liu, Mehmet Toy, Vic liu, 2020-01-06,\n  <draft-chen-pce-label-x-domains-10.txt>\n\n      This document specifies extensions to PCEP for distributing labels\n      crossing domains for an inter-domain Point-to-Point (P2P) or Point-\n      to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path\n      (LSP).\n\n  "Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol\n  and/or the Transport Layer Security (TLS) Protocol", Walter Hoehlhubmer,\n  2013-11-25, <draft-hoehlhubmer-https-addon-07.txt>\n\n      This document describes an Add-on for websites providing encrypted\n      connectivity (HTTP over TLS).\n      \n      The Add-on has two parts,  one for the Domain Name System (DNS) -\n      storing the X.509 certificate hashes - and one for the webserver\n      itself - an additional webpage providing specific informations.\n\n  "Generic Fault-avoidance Routing Protocol for Data Center Networks", Bin\n  Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish, 2019-11-23,\n  <draft-sl-rtgwg-far-dcn-13.txt>\n\n      This draft describes a generic routing method and protocol for a\n      regular data center network, named the Fault-Avoidance Routing (FAR)\n      protocol.  The FAR protocol provides a generic routing method for all\n      types of regular topology network architectures that have been\n      proposed for large-scale cloud-based data centers over the past few\n      years.  The FAR protocol is designed to leverage any regularity in\n      the topology and compute its routing table in a simplistic manner.\n      Fat-tree is taken as an example architecture to illustrate how the\n      FAR protocol can be applied in real operational scenarios.\n\n  "SAML Profile for the Metadata Query Protocol", Ian Young, 2020-01-16,\n  <draft-young-md-query-saml-12.txt>\n\n      This document profiles the Metadata Query Protocol for use with SAML\n      metadata.\n      \n      This document is a product of the Research and Education Federations\n      (REFEDS) Working Group process.\n      \n      Editorial Note (To be removed by RFC Editor before publication)\n      \n      Discussion of this draft takes place on the MDX mailing list\n      (mdx@lists.iay.org.uk), which is accessed from [MDX.list].\n      \n      XML versions, latest edits and the issues list for this document are\n      available from [md-query].\n      \n      The changes in this draft are summarized in Appendix A.13.\n\n  "Scalable-Group Tag eXchange Protocol (SXP)", Michael Smith, Rakesh\n  Kandula, Syam Appala, 2019-10-21, <draft-smith-kandula-sxp-09.txt>\n\n      This document discusses scalable-group tag exchange protocol (SXP), a\n      control protocol to propagate IP address to Scalable Group Tag (SGT)\n      binding information across network devices.\n\n  "BGP Auto Discovery", Robert Raszuk, Jon Mitchell, Warren Kumari, Keyur\n  Patel, John Scudder, 2019-12-11,\n  <draft-raszuk-idr-bgp-auto-discovery-06.txt>\n\n      This document describes a method for automating portions of a\n      router\'s BGP configuration via discovery of BGP peers with which to\n      establish further sessions from an initial "bootstrap" router.  This\n      method can apply for establishment of either Internal or External BGP\n      peering sessions.\n\n  "Operational recommendations for management of DNSSEC Validator", Daniel\n  Migault, Edward Lewis, Dan York, 2019-11-16,\n  <draft-mglt-dnsop-dnssec-validator-requirements-08.txt>\n\n      The DNS Security Extensions define a process for validating received\n      data and assert them authentic and complete as opposed to forged.\n      \n      This document is focused clarifying the scope and responsibilities of\n      DNSSEC Resolver Operators (DRO) as well as operational\n      recommendations that DNSSEC validators operators SHOULD put in place\n      in order to implement sufficient Trust that makes DNSSEC validation\n      output accurate.  The recommendations described in this document\n      include, provisioning mechanisms as well as monitoring and management\n      mechanisms.\n\n  "Extensions to the Path Computation Element Protocol (PCEP) to Support\n  Resource Sharing-based Path Computation", Xian Zhang, Haomian Zheng, Oscar\n  de Dios, Victor Lopezalvarez, Yunbin Xu, 2019-10-23,\n  <draft-zhang-pce-resource-sharing-11.txt>\n\n      Resource sharing in a network means two or more Label Switched Paths\n      (LSPs) use common pieces of resource along their paths. This can\n      help save network resources and is useful in scenarios such as LSP\n      recovery or when two LSPs do not need to be active at the same time.\n      A Path Computation Element (PCE) is responsible for path computation\n      with such requirement.\n      \n      Existing extensions to the Path Computation Element Protocol (PCEP)\n      allow one path computation request for an LSP to be associated with\n      other (existing) LSPs through the use of the PCEP Association\n      Object.\n      \n      This document extends PCEP in order to support resource-sharing-\n      based path computation as another use of the Association Object to\n      enable better efficiency in the computation and in the resultant\n      paths and network resource usage.\n\n  "Security Mechanism Names for Media", Peter Dawes, 2019-11-26,\n  <draft-dawes-sipcore-mediasec-parameter-11.txt>\n\n      Negotiating the security mechanisms used between a Session Initiation\n      Protocol (SIP) user agent and its next-hop SIP entity is described in\n      [2].  This document adds the capability to distinguish security\n      mechanisms that apply to the media plane by defining a new Session\n      Initiation Protocol (SIP) header field parameter to label such\n      security mechanisms.\n\n  "WebRTC Dependencies", Cullen Jennings, 2019-10-02,\n  <draft-jennings-rtcweb-deps-23.txt>\n\n      This draft will never be published as an RFC and is meant purely to\n      help track the IETF dependencies from the W3C WebRTC documents.\n\n  "A JSON Encoding for HTTP Header Field Values", Julian Reschke, 2019-11-20,\n  <draft-reschke-http-jfv-11.txt>\n\n      This document establishes a convention for use of JSON-encoded field\n      values in HTTP header fields.\n\n  "TFO support for Multipath TCP", Sebastien Barre, Gregory Detal, Olivier\n  Bonaventure, Christoph Paasch, 2019-11-20, <draft-barre-mptcp-tfo-06.txt>\n\n      TCP Fast Open (TFO) is a TCP extension that allows sending data in\n      the SYN, instead of waiting until the TCP connection is established.\n      This document describes what parts of Multipath TCP must be adapted\n      to support it, and how TFO and MPTCP can operate together.\n\n  "Ideas for a Next Generation of the Stream Control Transmission Protocol\n  (SCTP)", Thomas Dreibholz, 2019-09-10,\n  <draft-dreibholz-tsvwg-sctp-nextgen-ideas-10.txt>\n\n      This document collects some ideas for a next generation of the Stream\n      Control Transmission Protocol (SCTP) for further discussion.  It is a\n      result of lessons learned from more than one decade of SCTP\n      deployment.\n\n  "Service Function Path Establishment", Julong Lan, Yuxiang Hu, Guozhen\n  Cheng, Peng Wang, Tong Duan, 2019-09-17,\n  <draft-lan-sfp-establishment-08.txt>\n\n      Service Function Chain architecture leads to more adaptive network\n      nodes. It allows splitting the network function into fine-grained\n      build blocks --- service function, and combining the network\n      functions into service function chain to formulate complicated\n      services. Further, the service function chain should be instantiated\n      by selecting the optimal instance from the candidates for each\n      service function in it. This document discusses the required\n      components during the instantiation of service function chain in the\n      network.\n\n  "LISP RLOC Membership Distribution", Johnson Leong, Darrel Lewis, Gregg\n  Schudel, Anton Smirnov, Chris Cassar, Isidor Kouvelas, 2019-09-10,\n  <draft-kouvelas-lisp-rloc-membership-02.txt>\n\n      The Locator/ID Separation Protocol (LISP) operation is based on EID\n      to RLOC mappings that are exchanged through a mapping system.  The\n      mapping system can use the RLOCs included in mapping registrations to\n      construct the complete set of RLOC addresses across all xTRs that are\n      members of the LISP deployment.  This set can then be made available\n      by the mapping system to all the member xTRs.  An xTR can use the\n      RLOC set to optimise protocol operation as well as to implement new\n      functionality.  This document describes the use of the LISP reliable\n      transport session between an xTR and a Map-Server to communicate the\n      contents of the RLOC membership set.\n\n  "Responsibility for Authoritative DNS and DNSSEC Mistakes", Jason\n  Livingood, 2019-08-13, <draft-livingood-dnsop-auth-dnssec-mistakes-05.txt>\n\n      DNS Security Extensions (DNSSEC) validation by recursive DNS\n      resolvers has been deployed at scale.  However, domain signing tools\n      and processes are not yet as mature and reliable as is the case for\n      non-DNSSEC-related domain administration tools and processes.  This\n      sometimes results in DNSSEC-validation failures, for which operators\n      of validating resolvers are often blamed.  This is similar to other,\n      non-DNSSEC-related authoritative DNS errors, for which individual\n      recursive DNS operators are sometimes incorrectly blamed.  This\n      document makes clear that responsibility for any and all\n      authoritative DNS failures rests squarely with authoritative domain\n      name operators, who are the only party that can properly maintain\n      their domain names and rectify associated authoritative DNS errors.\n\n  "In Case of DNSSEC Validation Failures, Do Not Change Resolvers", Jason\n  Livingood, 2019-08-13, <draft-livingood-dnsop-dont-switch-resolvers-05.txt>\n\n      DNS Security Extensions (DNSSEC) validation by recursive DNS\n      resolvers has been deployed at scale.  However, domain signing tools\n      and processes are not yet as mature and reliable as is the case for\n      non-DNSSEC-related domain administration tools and processes.  This\n      sometimes results in DNSSEC validation failures, for which operators\n      of validating resolvers are often blamed.  When these failures do\n      occur, end users should not change to a non-validating DNS resolver,\n      as that would downgrade their security.  They should instead wait\n      until the authoritative domain operator updates their DNS records to\n      resolve the error and that change propagates across the Internet\'s\n      DNS resolvers, the timing of which may be dependent upon the Time To\n      Live (TTL) settings in the old and/or erroneous DNS resource records.\n\n  "Additional XML Security Uniform Resource Identifiers (URIs)", Donald\n  Eastlake, 2020-01-02, <draft-eastlake-rfc6931bis-xmlsec-uris-11.txt>\n\n      This document updates and corrects the IANA registry for the list of\n      URIs intended for use with XML digital signatures, encryption,\n      canonicalization, and key management.  These URIs identify algorithms\n      and types of information.  This document corrrects three errata\n      against and obsoletes RFC 6931.\n      \n      The intent is to keep this draft alive while it accumulates updates\n      until it seems reasonable to publish the next version.\n\n  "A Simple Control Protocol for MPLS SFLs", Stewart Bryant, George Swallow,\n  Siva Sivabalan, 2020-01-03, <draft-bryant-mpls-sfl-control-06.txt>\n\n      In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow\n      labels (SFL) was introduced.  This document describes a control\n      protocol that runs over an associated control header to request,\n      withdraw, and extend the lifetime of such labels.\n\n  "TE LSP Crossing Topology-Transparent Zones", Huaimo Chen, Renwei Li,\n  Gregory Cauchie, Alvaro Retana, Ning So, Fengman Xu, Mehmet Toy, Vic liu,\n  Lei Liu, 2019-10-02, <draft-chen-teas-rsvp-ttz-02.txt>\n\n      A topology-transparent zone is virtualized as the edges of the zone\n      fully connected.  This document presents the procedures for the\n      establishment of Traffic Engineering (TE) LSPs crossing Topology-\n      Transparent Zones.\n\n  "Simple Certificate Enrolment Protocol", Peter Gutmann, 2019-06-09,\n  <draft-gutmann-scep-14.txt>\n\n      This document specifies the Simple Certificate Enrolment Protocol\n      (SCEP), a PKI protocol that leverages existing technology by using\n      CMS (formerly known as PKCS #7) and PKCS #10 over HTTP.  SCEP is the\n      evolution of the enrolment protocol sponsored by Cisco Systems, which\n      enjoys wide support in both client and server implementations, as\n      well as being relied upon by numerous other industry standards that\n      work with certificates.\n\n  "Multiple Upstream Interface Support for IGMP/MLD Proxy", Hitoshi Asaeda,\n  Luis Contreras, 2019-11-04, <draft-asaeda-pim-multiif-igmpmldproxy-03.txt>\n\n      This document describes the way of supporting multiple upstream\n      interfaces for an IGMP/MLD proxy device.  The proposed extension\n      enables an IGMP/MLD proxy device to receive multicast sessions/\n      channels through the different upstream interfaces.  The upstream\n      interface is selected based on the subscriber address prefixes,\n      channel/session IDs, and interface priority values.  A mechanism for\n      upstream interface takeover that enables to switch from an inactive\n      upstream interface to an active upstream interface is also described.\n\n  "MPTCP Experiences in the NorNet Testbed", Thomas Dreibholz, Simone Ferlin,\n  ozgu@simula.no, Ahmed Elmokashfi, Ioana Livadariu, Xing Zhou, 2019-12-03,\n  <draft-dreibholz-mptcp-nornet-experience-05.txt>\n\n      This document collects some experiences of Multi-Path TCP (MPTCP)\n      evaluations in the NorNet testbed.\n\n  "Encapsulating IP in UDP", Xiaohu Xu, Hamid Assarpour, Shaowen Ma,\n  daniel.bernier@bell.ca, Darren Dukes, Shraddha Hegde, Yiu Lee, Fan\n  Yongbing, 2019-12-13, <draft-xu-intarea-ip-in-udp-08.txt>\n\n      Existing IP-in-IP encapsulation technologies are not adequate for\n      efficient load balancing of IP-in-IP traffic across IP networks.\n      This document specifies additional IP-in-IP encapsulation technology,\n      referred to as IP-in-UDP (User Datagram Protocol), which can\n      facilitate the load balancing of IP-in-IP traffic across IP networks.\n\n  "TLS and DTLS Security Modules", Pascal Urien, 2019-12-15,\n  <draft-urien-uta-tls-dtls-security-module-09.txt>\n\n      Security and trust are very critical topics in the context of the\n      anywhere, anytime, anything internet connectivity. TLS and DTLS are\n      two major IETF protocols widely used to secure IP exchanges.\n      According to CoAP, DTLS is the protocol used by constraint nodes in\n      the Internet of Things (IoT) context.\n      \n      In this draft we specify an ISO7816 interface for TLS and DTLS\n      secure modules based on ISO7816 secure chips, which are today\n      manufactured per billions every year.\n      \n      Secure elements are cheap secure microcontrollers whose size is\n      about 25mm2 and whose security is ranked by evaluations typically\n      according to Common Criteria (CC) standards.\n      \n      The support of TLS and DTLS is based on the EAP-TLS protocol, and\n      the IETF draft "EAP Support in smartcard" describing EAP-TLS support\n      for secure elements. First implementation demonstrates that such low\n      cost security modules are realistic, with a setup time for handshake\n      completion under the second.\n\n  "Extensions to OSPF for Temporal LSP", Huaimo Chen, Mehmet Toy, Vic liu,\n  Lei Liu, 2019-10-02, <draft-chen-ospf-tts-03.txt>\n\n      This document specifies extensions to OSPF for distributing Traffic\n      Engineering (TE) information on a link in a sequence of time\n      intervals.\n\n  "LISP support for Multi-Tuple EIDs", Alberto Rodriguez-Natal, Albert\n  Cabellos-Aparicio, Sharon Barkai, Vina Ermagan, Darrel Lewis, Fabio Maino,\n  Dino Farinacci, 2019-10-07,\n  <draft-rodrigueznatal-lisp-multi-tuple-eids-08.txt>\n\n      This document describes extensions for LISP to support EIDs based on\n      tuples of multiple elements.\n\n  "LISP Map Server Reliable Transport", Johnson Leong, Darrel Lewis, Balaji\n  Venkatachalapathy, Chris Cassar, Isidor Kouvelas, Jesus Arango, 2019-08-08,\n  <draft-kouvelas-lisp-map-server-reliable-transport-05.txt>\n\n      The communication between LISP ETRs and Map-Servers is based on\n      unreliable UDP message exchange coupled with periodic message\n      transmission in order to maintain soft state.  The drawback of\n      periodic messaging is the constant load imposed on both the ETR and\n      the Map-Server.  New use cases for LISP have increased the amount of\n      state that needs to be communicated with requirements that are not\n      satisfied by the current mechanism.  This document introduces the use\n      of a reliable transport for ETR to Map-Server communication in order\n      to eliminate the periodic messaging overhead, while providing\n      reliability, flow-control and endpoint liveness detection.\n\n  "SMTP Service Extension for Client Identity", William Storey, 2019-12-09,\n  <draft-storey-smtp-client-id-08.txt>\n\n      This document defines an extension for the Simple Mail Transfer\n      Protocol (SMTP) called "CLIENTID" to provide a method for clients to\n      indicate an identity to the server.\n      \n      This identity is an additional token that may be used for security\n      and/or informational purposes, and with it a server may optionally\n      apply heuristics using this token.\n\n  "Annotated Example SDP for WebRTC", Suhas Nandakumar, Cullen Jennings,\n  2018-10-09, <draft-ietf-rtcweb-sdp-11.txt>\n\n      The Real-Time Communications in WEB-browsers (Rtcweb) working group\n      is charged to provide protocol support for direct interactive rich\n      communication using audio, video and data between two peers\' web\n      browsers.  With in the Rtcweb framework, Session Description protocol\n      (SDP) is used for negotiating session capabilities between the peers.\n      Such a negotiation happens based on the SDP Offer/Answer exchange\n      mechanism.\n      \n      This document provides an informational reference in describing the\n      role of SDP and the Offer/Answer exchange mechanism for the most\n      common Rtcweb use-cases.\n\n  "RFC Origins of Domain Names", Edward Lewis, 2019-08-06,\n  <draft-lewis-domain-names-13.txt>\n\n      Is the concept of Domain Names owned by the DNS protocol or does the\n      DNS protocol exist to support the concept of Domain Names?  This\n      question has become pertinent in light of proposals to use Domain\n      Names in protocols in ways incompatible with the DNS protocol and the\n      operational environment built to run the protocol.\n      \n      This document is intended to help answer this question by presenting\n      a look into the recorded history of relevant Requests for Comments.\n      This document comprises the research and views of the author and has\n      benefited from review and input from many IETF experts, but it does\n      not represent the consensus opinion of the IETF.\n\n  "PCEP Extension for Distribution of Link-State and TE Information.", Dhruv\n  Dhody, Young Lee, Daniele Ceccarelli, 2019-10-21,\n  <draft-dhodylee-pce-pcep-ls-14.txt>\n\n      In order to compute and provide optimal paths, Path Computation\n      Elements (PCEs) require an accurate and timely Traffic Engineering\n      Database (TED).  Traditionally this TED has been obtained from a link\n      state (LS) routing protocol supporting traffic engineering\n      extensions.\n      \n      This document extends the Path Computation Element Communication\n      Protocol (PCEP) with Link-State and TE Information.\n\n  "MS-originated SMRs", Alberto Rodriguez-Natal, Albert Cabellos-Aparicio,\n  Vina Ermagan, Fabio Maino, Sharon Barkai, 2019-10-07,\n  <draft-rodrigueznatal-lisp-ms-smr-09.txt>\n\n      This document extends [I-D.ietf-lisp-rfc6833bis] to allow Map Servers\n      to send SMR messages.\n      \n      This extension is intended to be used in some SDN deployments that\n      use LISP as a southbound protocol with (P)ITRs that are compliant\n      with [I-D.ietf-lisp-rfc6833bis].  In this use-case mapping updates do\n      not come from ETRs, but rather from a centralized controller that\n      pushes the updates directly to the Mapping System.  In such\n      deployments, Map Servers will benefit from having a mechanism to\n      inform directly (P)ITRs about updates in the mappings they are\n      serving.  Although implementations of this extension exist, this\n      extension is deprecated by [I-D.ietf-lisp-pubsub] and it is being\n      documented for informational purposes.  Newer implementations should\n      look into [I-D.ietf-lisp-pubsub] to support PubSub in LISP\n      deployments.\n\n  "Quantum Relief with TLS and Kerberos", Rick van Rein, Tom Vrancken,\n  2020-01-21, <draft-vanrein-tls-kdh-06.txt>\n\n      This specification describes a mechanism to use Kerberos\n      authentication within the TLS protocol.  This gives users of TLS a\n      strong alternative to classic PKI-based authentication, and at the\n      same introduces a way to insert entropy into TLS\' key schedule such\n      that the resulting protocol becomes resistant against attacks from\n      quantum computers.  We call this Quantum Relief, and specify it as\n      part of a more general framework to make it easier for other\n      technologies to achieve similar benefits.\n\n  "Node Potential Oriented Multi-NextHop Routing Protocol", Julong Lan,\n  Jianhui Zhang, Bin Wang, Wenfen Liu, Tong Duan, 2019-09-17,\n  <draft-lanzhangwang-rtgwg-npmnrp-08.txt>\n\n      The Node Potential Oriented Multi-Nexthop Routing Protocol (NP-MNRP)\n      bases on the idea of "hop-by-hop routing forwarding, multi-backup\n      next hop" and combines with the phenomena that water flows from\n      higher place to lower.  NP-MNRP defines a metric named as node\n      potential, which is based on hop count and the actual link bandwidth,\n      and calculates multiple next-hops through the potential difference\n      between the nodes.\n\n  "Problems in and among industries for the prompt realization of IoT and\n  safety considerations", Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu,\n  Koichi KUNITAKE, Kaoru Maeda, 2020-01-15, <draft-baba-iot-problems-08.txt>\n\n      This document contains opinions gathered from enterprises engaging in\n      the IoT business as stated in the preceding version hereof, and also\n      examines the possibilities of new social problems in the IoT era.\n      Recognition of the importance of information security has grown in\n      step with the rising use of the Internet.  Closer examination reveals\n      that the IoT era may see a new direct physical threat to users.  For\n      instance, the situation at a smart house may lead it to judge that\n      the owner has only temporarily stepped out, causing it to unlock the\n      front door, which in turn makes it easier for thieves to enter.\n      These kinds of scenarios may occur without identity fraud, hacking,\n      and other means of compromising information security.  Therefore, for\n      the purpose of this document, this issue shall be referred to as "IoT\n      Safety" to distinguish it from Information Security.\n      \n      We believe that it is necessary to deepen our understanding of these\n      new IoT-related threats through discussion and ensure there are\n      measures to address these threats in the future.  At the same time,\n      we must also coordinate these measures with the solutions to the\n      problems described in the previous version of this document.\n\n  "PCEP Extensions for BIER-TE", Ran Chen, Zheng Zhang, Senthil Dhanaraj,\n  Fengwei Qin, 2019-11-03, <draft-chen-pce-bier-06.txt>\n\n      Bit Index Explicit Replication (BIER)-TE shares architecture and\n      packet formats with BIER as described in [RFC8279].  BIER-TE forwards\n      and replicates packets based on a BitString in the packet header, but\n      every BitPosition of the BitString of a BIER-TE packet indicates one\n      or more adjacencies as described in [I-D.ietf-bier-te-arch].BIER-TE\n      Path can be derived from a Path Computation Element (PCE).\n      \n      This document specifies extensions to the Path Computation Element\n      Protocol (PCEP) that allow a PCE to compute and initiate the path for\n      the BIER-TE.\n\n  "BGP Based Multicast", Zhaohui Zhang, Leonard Giuliano, Keyur Patel,\n  IJsbrand Wijnands, mankamana mishra, Arkadiy Gulko, 2019-10-29,\n  <draft-zzhang-bess-bgp-multicast-03.txt>\n\n      This document specifies a BGP address family and related procedures\n      that allow BGP to be used for setting up multicast distribution\n      trees.  This document also specifies procedures that enable BGP to be\n      used for multicast source discovery, and for showing interest in\n      receiving particular multicast flows.  Taken together, these\n      procedures allow BGP to be used as a replacement for other multicast\n      routing protocols, such as PIM or mLDP.  The BGP procedures specified\n      here are based on the BGP multicast procedures that were originally\n      designed for use by providers of Multicast Virtual Private Network\n      service.\n\n  "Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix",\n  Naoki Matsuhira, 2019-12-02, <draft-matsuhira-me6e-fp-08.txt>\n\n      This document specifies Multiple Ethernet - IPv6 address mapping\n      encapsulation - fixed prefix (ME6E-FP) base specification.  ME6E-FP\n      makes expantion ethernet network over IPv6 backbone network with\n      encapsuation technoogy.  And also, E6ME-FP can stack multiple\n      Ethernet networks.  ME6E-FP work on own routing domain.\n\n  "Multiple Ethernet - IPv6 address mapping encapsulation - prefix\n  resolution", Naoki Matsuhira, 2019-12-02, <draft-matsuhira-me6e-pr-08.txt>\n\n      This document specifies Multiple Ethernet - IPv6 address mapping\n      encapsulation - Prefix Resolution (ME6E-PR) specification.  ME6E-PR\n      makes expantion ethernet network over IPv6 backbone network with\n      encapsuation technoogy.  And also, E6ME-PR can stack multiple\n      Ethernet networks.  ME6E-PR work on non own routing domain.\n\n  "Information Distribution in Autonomic Networking", Bing Liu, Xun Xiao,\n  Artur Hecker, Sheng Jiang, Zoran Despotovic, 2019-12-12,\n  <draft-liu-anima-grasp-distribution-13.txt>\n\n      This document proposes a solution for information distribution in\n      autonomic networks. Information distribution is categorized into two\n      different modes: 1) instantaneous distribution; 2) publication for\n      retrieval. In the former case, the information is sent, propagates\n      and is disposed of after reception. In the latter case, information\n      needs to be stored in the network.\n      \n      The capabilities to distribute information are basic and fundamental\n      needs for an autonomous network (cf. ANI [I-D.ietf-anima-reference-\n      model]). This document describes typical use cases of information\n      distribution in ANI and requirements to ANI, such that rich\n      information distribution can be natively supported. The document\n      proposes extensions to the autonomic nodes and suggests an\n      implementation based on GRASP extensions as a protocol on the wire.\n\n  "BGP Extensions for Enhanced VPN Auto Discovery", Shunwan Zhuang, Zhenbin\n  Li, Donald Eastlake, Lucy Yong, 2020-01-15,\n  <draft-zhuang-bess-enhanced-vpn-auto-discovery-05.txt>\n\n      A variety of VPN technologies have been widely deployed to bear\n      different services.  As new applications develop, a requirement has\n      been proposed for auto-discovery of Layer 3 Virtual Private Networks\n      (L3VPN) and enhanced auto-discovery requirements for other VPN\n      technologies that already have basic auto-discovery mechanisms.\n      \n      This document identifies some possible applications of these auto-\n      discovery requirements and defines a new BGP NLRI, called the BGP-\n      VPN-INSTANCE NLRI, to satisfy the requirement for auto-discovery of\n      BGP VPN instances. It also defines a new type of extended community,\n      called the Import Route Target, which can be applied to auto-\n      discovery mechanisms of multiple VPN technologies.\n\n  "BGP Extensions for IDs Allocation", Huaimo Chen, Zhenbin Li, Zhenqiang Li,\n  Yanhe Fan, Mehmet Toy, Lei Liu, 2019-10-30,\n  <draft-wu-idr-bgp-segment-allocation-ext-04.txt>\n\n      This document describes extensions to the BGP for IDs allocation.\n      The IDs are SIDs for segment routing (SR), including SR for IPv6\n      (SRv6).  They are distributed to their domains if needed.\n\n  "IPv6 Prefix Delegation and Multi-Addressing Models", Fred Templin,\n  2020-01-01, <draft-templin-v6ops-pdhost-25.txt>\n\n      Requesting nodes typically acquire IPv6 prefixes from a prefix\n      delegation service for the network.  The requesting node can\n      provision the prefix according to whether it acts as a router on\n      behalf of any downstream networks and/or as a host on behalf of its\n      local applications.  In the latter case, the requesting node can use\n      portions of the delegated prefix for its own multi-addressing\n      purposes.  This document therefore considers prefix delegation models\n      for both the classic routing and various multi-addressing use cases.\n\n  "Using compression in the Internet Key Exchange Protocol Version 2\n  (IKEv2)", Valery Smyslov, 2019-09-04,\n  <draft-smyslov-ipsecme-ikev2-compression-08.txt>\n\n      This document describes a method for reducing the size of the IKEv2\n      messages by using lossless compression.  Making IKEv2 messages\n      smaller is desirable for low power consumption battery powered\n      devices.  It also helps to avoid IP fragmentation of IKEv2 messages.\n      This document describes how compression is negotiated maintaining\n      backward compatibility and how it is used in IKEv2.\n\n  "A MILP Model to Solve the Problem of Loading Balance of Routing and\n  Wavelength Assignment for Optical Transport Networks", Shan Yin, Shanguo\n  Huang, Dajiang Wang, Xuan Wang, Yu Zhang, 2019-10-17,\n  <draft-yin-milp-rwa-otn-09.txt>\n\n      The RWA problem can be formulated as a Mixed-Integer linear program.\n      Load balancing is a key factor for the optical transport networks.\n      However, the existed approaches using mixed-Integer linear program to\n      solve the RWA problem are not perfect enough without considering the\n      load balancing of the networks.\n      \n      This documentary provides a model of Mixed-Integer Linear Programming\n      to solve the problem of load balancing needed by routing and\n      wavelength assignment (RWA) process in optical transport networks.\n\n  "Mathematical Mesh 3.0 Part I: Architecture Guide", Phillip Hallam-Baker,\n  2020-01-16, <draft-hallambaker-mesh-architecture-12.txt>\n\n      The Mathematical Mesh \'The Mesh\' is an end-to-end secure\n      infrastructure that makes computers easier to use by making them more\n      secure.  The Mesh provides a set of protocol and cryptographic\n      building blocks that enable encrypted data stored in the cloud to be\n      accessed, managed and exchanged between users with the same or better\n      ease of use than traditional approaches which leave the data\n      vulnerable to attack.\n      \n      This document provides an overview of the Mesh data structures,\n      protocols and examples of its use.\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-\n      architecture.html.\n\n  "Mathematical Mesh: Reference Implementation", Phillip Hallam-Baker,\n  2019-10-23, <draft-hallambaker-mesh-developer-09.txt>\n\n      The Mathematical Mesh \'The Mesh\' is an end-to-end secure\n      infrastructure that facilitates the exchange of configuration and\n      credential data between multiple user devices.\n      \n      This document describes the Mesh reference code and how to install,\n      run and make use of it in applications.  It does not form a part of\n      the Mesh specifications and is not normative.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-developer.html\n      [1] .\n\n  "Special Use Domain Name \'ipv4only.arpa\'", Stuart Cheshire, David Schinazi,\n  2019-11-04, <draft-cheshire-sudn-ipv4only-dot-arpa-15.txt>\n\n      The specification for how a client discovers its local network\'s\n      NAT64 prefix [RFC7050] defines the special name \'ipv4only.arpa\' for\n      this purpose, but in its Domain Name Reservation Considerations\n      section that specification indicates that the name actually has no\n      particularly special properties would require special handling, and\n      does not request IANA to record the name in the Special-Use Domain\n      Names registry.\n      \n      Consequently, despite the well articulated special purpose of the\n      name, \'ipv4only.arpa\' was not recorded in the Special-Use Domain\n      Names registry as a name with special properties.\n      \n      As a result of this omission, in cases where software needs to give\n      this name special treatment in order for it to work correctly, there\n      was no clear mandate authorizing software authors to implement that\n      special treatment.  Software implementers were left with the choice\n      between not implementing the special behavior necessary for the name\n      queries to work correctly, or implementing the special behavior and\n      being accused of being noncompliant with some RFC.\n      \n      This document describes the special treatment required, formally\n      declares the special properties of the name, and adds similar\n      declarations for the corresponding reverse mapping names.\n\n  "The Use of Registries", Erik Wilde, 2019-07-30,\n  <draft-wilde-registries-03.txt>\n\n      Registries for Internet and Web protocols fulfill a wide range of\n      tasks, ranging from low-level networking aspects such as packet type\n      identifiers, all the way up to application-level protocols and\n      standards.  This document summarizes some of the reasons of why,\n      when, and how to use registries.  It serves as an informative\n      reference for specification writers considering whether to create and\n      manage a registry, allowing them to better understand some of the\n      issues associated with certain design and operational decisions.\n\n  "Multiple IPv4 - IPv6 mapped IPv6 address (M46A)", Naoki Matsuhira,\n  2019-12-02, <draft-matsuhira-m46a-07.txt>\n\n      This document specifies Multiple IPv4 - IPv6 mapped IPv6\n      address(M46A) spefification.  M46A is IPv4 mapped IPv6 address with\n      plane ID.  Unique allocation of plane id value enable IPv4 private\n      address unique in IPv6 address space.  This address may use IPv4 over\n      IPv6 encapsulation and IPv4 - IPv6 translation.\n\n  "Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix\n  (M46E-FP)", Naoki Matsuhira, 2019-12-02, <draft-matsuhira-m46e-fp-07.txt>\n\n      This document specifies Multiple IPv4 - IPv6 address mapping\n      encapsulation - fixed prefix (M46E-FP) specification.  M46E-FP makes\n      backbone network to IPv6 only.  And also, M46E-FP can stack many IPv4\n      networks, i.e. the networks using same IPv4 (private) addresses,\n      without interdependence.\n\n  "Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution\n  (M46E-PR)", Naoki Matsuhira, 2019-12-02, <draft-matsuhira-m46e-pr-07.txt>\n\n      This document specifies M46E Prefix Resolution (M46E-PR)\n      specification.  M46E-PR connect IPv4 stub networks between IPv6\n      backbone network.  And also, M46E-PR can stack many IPv4 networks,\n      i.e. the nwtworks using same IPv4 private addresses without\n      interdependence.\n\n  "Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator\n  (M46E-PT)", Naoki Matsuhira, 2019-12-02, <draft-matsuhira-m46e-pt-07.txt>\n\n      This document specifies Multiple IPv4 - IPv6 mapping encapsulation -\n      Prefix Translator (M46E-PT) specification.  M46E-PT expand IPv4\n      network plane by connecting M46E-FP domain and M46E-PR domain.\n      M46E-PT translate prefix part of M46E-FP address and M46E-PR address\n      both are IPv6 address.  M46E-PT does not translate IPv4 packet which\n      is encapsulated, so transparency of IPv4 packet is not broken.\n\n  "Multiple IPv4 - IPv6 address mapping translator (M46T)", Naoki Matsuhira,\n  2019-12-02, <draft-matsuhira-m46t-07.txt>\n\n      This document specifies Multiple IPv4 - IPv6 address mapping\n      Translator (M46T) specification.  M46T enable access to IPv4 only\n      host from IPv6 host.  IPv4 host is identified as M46 address in IPv6\n      address space.  The address assigned to IPv4 host may be global IPv4\n      address or private IPv4 address.  M46T does not support access to\n      IPv6 host from IPv4 only host.\n\n  "Multiple IPv4 address and port number - IPv6 address mapping encapsulation\n  (M4P6E)", Naoki Matsuhira, 2019-12-02, <draft-matsuhira-m4p6e-07.txt>\n\n      This document specifies Multiple IPv4 address and port number - IPv6\n      address mapping encapulation (M4P6E) specification.\n\n  "Nimble out-of-band authentication for EAP (EAP-NOOB)", Tuomas Aura, Mohit\n  Sethi, 2019-10-30, <draft-aura-eap-noob-07.txt>\n\n      Extensible Authentication Protocol (EAP) provides support for\n      multiple authentication methods.  This document defines the EAP-NOOB\n      authentication method for nimble out-of-band (OOB) authentication and\n      key derivation.  This EAP method is intended for bootstrapping all\n      kinds of Internet-of-Things (IoT) devices that have a minimal user\n      interface and no pre-configured authentication credentials.  The\n      method makes use of a user-assisted one-directional OOB channel\n      between the peer device and authentication server.\n\n  "Multi-Stage Transparent Server Load Balancing", Naoki Matsuhira,\n  2019-12-02, <draft-matsuhira-mslb-07.txt>\n\n      This document specifies Multi-Stage Transparent Server Load Balancing\n      (MSLB) specification.  MSLB make server load balancing over Layer3\n      network without packet header change at client and server.  MSLB make\n      server load balancing with any protocol and protocol with encription\n      such as IPsec ESP, SSL/TLS.\n\n  "Conveying Vendor-Specific Information in the Path Computation Element\n  (PCE) Communication Protocol (PCEP) extensions for stateful PCE.", Cheng\n  Li, Haomian Zheng, Siva Sivabalan, 2020-01-11,\n  <draft-dhody-pce-stateful-pce-vendor-08.txt>\n\n      A Stateful Path Computation Element (PCE) maintains information on\n      the current network state, including: computed Label Switched Path\n      (LSPs), reserved resources within the network, and pending path\n      computation requests.  This information may then be considered when\n      computing new traffic engineered LSPs, and for associated and\n      dependent LSPs, received from Path Computation Clients (PCCs).\n      \n      RFC 7470 defines a facility to carry vendor-specific information in\n      PCEP.\n      \n      This document extends this capability for the stateful PCE messages.\n\n  "Packet-Optical Integration in Segment Routing", Madhukar Anand, Sanjoy\n  Bardhan, Ramesh Subrahmaniam, Jeff Tantsura, Utpal Mukhopadhyaya, Clarence\n  Filsfils, 2019-07-29, <draft-anand-spring-poi-sr-08.txt>\n\n      This document illustrates a way to integrate a new class of nodes and\n      links in segment routing to represent transport/optical networks in\n      an opaque way into the segment routing domain.  An instance of this\n      class would be optical networks that are typically transport centric\n      by having very few devices with the capability to process packets.\n      In the IP centric network, this will help in defining a common\n      control protocol for packet optical integration that will include\n      optical paths as \'transport segments\' or sub-paths as an augmentation\n      to packet paths. The transport segment option also defines a general\n      mechanism to allow for future extensibility of segment routing into\n      non-packet domains.\n\n  "A YANG model to manage the optical parameters for in a WDM network",\n  Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel,\n  2019-09-10, <draft-galimbe-ccamp-iv-yang-09.txt>\n\n      This memo defines a Yang model that translate the information model\n      to support Impairment-Aware (IA) Routing and Wavelength Assignment\n      (RWA) functionality.  The information model is defined in draft-ietf-\n      ccamp-wson-iv-info and draft-martinelli-ccamp-wson-iv-encode.  This\n      document defines proper encoding and extend to the models defined in\n      draft-lee-ccamp-wson-yang tu support Impairment-Aware (IA) Routing\n      and Wavelength Assignment (RWA) functions\n      \n      The Yang model defined in this memo can be used for Optical\n      Parameters monitoring and/or configuration of the multivendor\n      Endpoints and ROADMs.  The use of this model does not guarantee\n      interworking of transceivers over a DWDM.  Optical path feasibility\n      and interoperability has to be determined by means outside the scope\n      of this document.  The purpose of this model is to program interface\n      parameters to consistently configure the mode of operation of\n      transceivers.\n\n  "Methodology for VNF Benchmarking Automation", Raphael Rosa, Christian\n  Rothenberg, Manuel Peuster, Holger Karl, 2019-11-04,\n  <draft-rosa-bmwg-vnfbench-05.txt>\n\n      This document describes a common methodology for the automated\n      benchmarking of Virtualized Network Functions (VNFs) executed on\n      general-purpose hardware.  Specific cases of automated benchmarking\n      methodologies for particular VNFs can be derived from this document.\n      Two open source reference implementations are reported as running\n      code embodiments of the proposed, automated benchmarking methodology.\n\n  "LISP Distinguished Name Encoding", Dino Farinacci, 2019-09-03,\n  <draft-farinacci-lisp-name-encoding-08.txt>\n\n      This draft defines how to use the AFI=17 Distinguished Names in LISP.\n\n  "LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2019-10-07,\n  <draft-farinacci-lisp-geo-08.txt>\n\n      This draft describes how Geo-Coordinates can be used in the LISP\n      Architecture and Protocols.\n\n  "Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)", Naoki Matsuhira,\n  2019-12-02, <draft-matsuhira-me6a-07.txt>\n\n      This document specifies Multiple Ethernet - IPv6 mapped IPv6\n      address(ME6A) spefification.  ME6A is Ethernet mapped IPv6 address\n      with plane ID.  Unique allocation of plane id value enable duplicated\n      MAC address unique in IPv6 address space.  This address may use\n      Ethernet over IPv6 encapsulation.\n\n  "Routing Optimization with SDN in Data Center Networks", Qian Kong, Tao\n  Gao, Dajiang Wang, Zhenyu Wang, Jiayu Wang, Bingli Guo, Shanguo Huang,\n  2019-10-07, <draft-kong-sdnrg-routing-optimization-sdn-in-dc-07.txt>\n\n      With the open and standard programmatic interface and the flexibility\n      of controlling network, Software Defined Network (SDN) can obviously\n      simplify and integrate operation and business support systems. As a\n      consequence, to satisfy the rising switching demand in the data\n      center network, it is a good option to adopt SDN technology. In\n      addition, current architecture of data center network is far from\n      ideality, which results in the low utilization rate in bandwidth\n      resource. For example, mice flow cannot be well effectively served in\n      the conventional Wavelength Division Multiplexing (WDM) optical\n      network with at least 50GHz spectrum interval. From a data center\n      network perspective, it is necessary to further improve the resource\n      utilization efficiency and the flexibility of coping with different\n      traffic.\n      \n      This document described an optical data center interconnect, which\n      comprises both the fixed and flexible grid transceivers. A traffic\n      monitor is implemented in the SDN-based data center network to\n      evaluate the coming traffic demands and allocate appropriate spectrum\n      for the request. For instance, mice flow can be served by fixed grid\n      transceivers, well the elephant flows can be transmitted by the\n      flexi-grid transceiver using multiple subcarriers to form a\n      superchannel. Thus, spectrum efficiency is optimized and bandwidth\n      utilization is improved dramatically.\n\n  "Path Table based Routing Mechanism in Software-Defined Optical Transport\n  Networks (SD-OTN)", Li Xin, Yu Zhou, Dajiang Wang, Zhenyu Wang, Jiayu Wang,\n  Wenzhe Li, Shan Yin, Shanguo Huang, 2019-10-07,\n  <draft-li-sdnrg-path-table-routing-in-sd-otn-07.txt>\n\n      The dynamic establishment and removal of an end-to-end light-path\n      consume a lot of time which are also the main burden of control plane\n      in optical transport networks. With the frequent arrival and\n      departure of services, the control plane needs to handle a large\n      number of control and management messages to conduct path\n      computation, resource reservation and cross connection configuration.\n      This draft proposes a novel routing mechanism based on Path Table for\n      software-defined optical transport networks (SD-OTN). The Path Table\n      reserves partial activated established light-paths that can be\n      directly used by subsequent requests for subsequent services. This\n      new routing mechanism can reduce the network load and save routing\n      time for some services.\n\n  "OpenPGP Web Key Directory", Werner Koch, 2019-11-18,\n  <draft-koch-openpgp-webkey-service-09.txt>\n\n      This specification describes a service to locate OpenPGP keys by mail\n      address using a Web service and the HTTPS protocol.  It also provides\n      a method for secure communication between the key owner and the mail\n      provider to publish and revoke the public key.\n\n  "SSH Agent Protocol", Damien Miller, 2019-12-10,\n  <draft-miller-ssh-agent-04.txt>\n\n      This document describes a key agent protocol for use in the Secure\n      Shell (SSH) protocol.\n\n  "HTTP/2 "Dropped Frame" Frame", Matthew Kerwin, 2019-08-08,\n  <draft-kerwin-http2-nak-frame-02.txt>\n\n      This document defines an extension to the Hypertext Transfer Protocol\n      Version 2 (HTTP/2) that allows an endpoint to signal to its peer that\n      an unsupported extension frame was discarded.\n      \n      Note to Readers\n      \n      The issues list for this draft can be found at\n      <https://github.com/phluid61/internet-drafts/labels/\n      HTTP%2F2%20NAK%20Frame>\n      \n      The most recent (often unpublished) draft is at\n      <https://phluid61.github.io/internet-drafts/http2-nak-frame/>\n\n  "Hybrid Hierarchical Multi-Domain Service Function chaining", Guanglei Li,\n  Guanwen Li, Qi Xu, Hua-chun Zhou, Bohao Feng, Xu Feng, Zhigang Yu,\n  2019-09-23, <draft-li-sfc-hhsfc-07.txt>\n\n      This document describes a Hybrid Hierarchical Multi-Domain Service\n      Function Chaining (hhSFC) architecture that extends Service Function\n      Chaining (SFC) to multiple domains with different technology,\n      administration or ownership.\n      \n      The goals of Hybrid Hierarchical SFC are to reduce the complexity of\n      the control plane in a multi-domain scene and make the negotiation\n      between different domains possible.\n\n  "DoD Common Cryptographic MIB (CCMIB)", Jeffrey Sun, Mike Irani, Tom\n  Nguyen, rpurvis@mitre.org, Sean Turner, 2019-09-30,\n  <draft-turner-ccmib-04.txt>\n\n      This document defines a portion of the Management Information Base\n      (MIB) for use with network management protocols in the Internet\n      community.  In particular, it describes managed objects for key\n      management implementations including asymmetric keys, symmetric keys,\n      trust anchors, and cryptographic-related firmware.\n      \n      This profile applies to the capabilities, configuration, and\n      operation of all components of US National Security Systems (SP\n      800-59).  It is also appropriate for other US Government systems that\n      process high-value information.  It is made publicly available for\n      use by developers and operators of these and any other system\n      deployments.\n\n  "Fault Management for EVPN networks", Vengada Govindan, Mallik Mudigonda,\n  Ali Sajassi, Gregory Mirsky, Donald Eastlake, 2020-01-02,\n  <draft-gmsm-bess-evpn-bfd-04.txt>\n\n      This document specifies proactive, in-band network OAM mechanisms to\n      detect loss of continuity and miss-connection faults that affect\n      unicast and multi-destination paths (used by Broadcast, Unknown\n      Unicast and Multicast traffic) in an Ethernet VPN (EVPN) network.\n      The mechanisms specified in the draft are based on the widely adopted\n      Bidirectional Forwarding Detection (BFD) protocol.\n\n  "OpenPGP Message Format", Werner Koch, brian carlson, Ronald Tse, Derek\n  Atkins, Daniel Gillmor, 2019-09-06, <draft-ietf-openpgp-rfc4880bis-08.txt>\n\n      { Work in progress to update the OpenPGP specification from RFC4880 }\n      \n      This document specifies the message formats used in OpenPGP.  OpenPGP\n      provides encryption with public-key or symmetric cryptographic\n      algorithms, digital signatures, compression and key management.\n      \n      This document is maintained in order to publish all necessary\n      information needed to develop interoperable applications based on the\n      OpenPGP format.  It is not a step-by-step cookbook for writing an\n      application.  It describes only the format and methods needed to\n      read, check, generate, and write conforming packets crossing any\n      network.  It does not deal with storage and implementation questions.\n      It does, however, discuss implementation issues necessary to avoid\n      security flaws.\n\n  "Hierarchical PCE Determination", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei\n  Liu, Zhenqiang Li, 2020-01-06, <draft-chen-pce-h-discovery-06.txt>\n\n      This document presents extensions to the Path Computation Element\n      Communication Protocol (PCEP) for determining parent child relations\n      and exchanging the information between a parent and a child PCE in a\n      hierarchical PCE system.\n\n  "PCEP Link State Abstraction", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei\n  Liu, Zhenqiang Li, 2020-01-06, <draft-chen-pce-h-connect-access-06.txt>\n\n      This document presents extensions to the Path Computation Element\n      Communication Protocol (PCEP) for a child PCE to abstract its domain\n      information to its parent for supporting a hierarchical PCE system.\n\n  "Static PCEP Link State", Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu,\n  Zhenqiang Li, 2020-01-06, <draft-chen-pce-pcc-ted-06.txt>\n\n      This document presents extensions to the Path Computation Element\n      Communication Protocol (PCEP) for a PCC to advertise the information\n      about the links without running IGP and for a PCE to build a TED\n      based on the information received.\n\n  "Flow Classification in Information Centric Networking", Ilya Moiseenko,\n  David Oran, 2020-01-20, <draft-moiseenko-icnrg-flowclass-05.txt>\n\n      For the ubiquitous and highly important Internet protocols (TCP, UDP,\n      IP), flows are conventionally identified by the "5-tuple" of source\n      and destination IP addresses, source and destination port, and\n      protocol type in an IP packet.  Information Centric Networking (ICN)\n      is a new paradigm where network communications are accomplished by\n      requesting named content, instead of sending packets to destination\n      addresses.  This document describes mechanisms allowing ICN\n      forwarders, consumers, producers and other ICN nodes to encode,\n      decode, and process equivalence class identifiers (flows) at any\n      desired granularity of a routable name prefix and beyond the routable\n      name prefix.  This document is a product of the IRTF Information-\n      Centric Networking Research Group (ICNRG).\n\n  "ICN Ping Protocol Specification", Spyridon Mastorakis, Jim Gibson, Ilya\n  Moiseenko, Ralph Droms, David Oran, 2019-08-19,\n  <draft-mastorakis-icnrg-icnping-05.txt>\n\n      This document presents the design of an ICN Ping protocol.  It\n      includes the operations both on the client and the forwarder side.\n\n  "PCEP Extension for Distribution of Link-State and TE information for\n  Optical Networks", Young Lee, Haomian Zheng, Daniele Ceccarelli, Wei Wang,\n  Peter Park, Bin-Yeong Yoon, 2019-09-02,\n  <draft-lee-pce-pcep-ls-optical-08.txt>\n\n      In order to compute and provide optimal paths, Path Computation\n      Elements (PCEs) require an accurate and timely Traffic Engineering\n      Database (TED). Traditionally this Link State and TE information has\n      been obtained from a link state routing protocol (supporting traffic\n      engineering extensions).\n      \n      This document extends the Path Communication Element Communication\n      Protocol (PCEP) with Link-State and TE information for optical\n      networks.\n\n  "ICN Traceroute Protocol Specification", Spyridon Mastorakis, Jim Gibson,\n  Ilya Moiseenko, Ralph Droms, David Oran, 2019-08-19,\n  <draft-mastorakis-icnrg-icntraceroute-05.txt>\n\n      This document presents the design of an ICN Traceroute protocol.\n      This includes the operations both on the client and the forwarder\n      side.\n\n  "Mathematical Mesh: Platform Configuration", Phillip Hallam-Baker,\n  2019-10-23, <draft-hallambaker-mesh-platform-05.txt>\n\n      The Mathematical Mesh \'The Mesh\' is an end-to-end secure\n      infrastructure that facilitates the exchange of configuration and\n      credential data between multiple user devices.  This document\n      describes how Mesh profiles are stored for application access on\n      Windows, Linux and OSX platforms.\n      \n      This document is also available online at\n      http://prismproof.org/Documents/draft-hallambaker-mesh-platform.html\n      [1] .\n\n  "Guidelines for Autonomic Service Agents", Brian Carpenter, Laurent\n  Ciavaglia, Sheng Jiang, Peloso Pierre, 2020-01-09,\n  <draft-carpenter-anima-asa-guidelines-08.txt>\n\n      This document proposes guidelines for the design of Autonomic Service\n      Agents for autonomic networks, as a contribution to describing an\n      autonomic ecosystem.  It is based on the Autonomic Network\n      Infrastructure outlined in the ANIMA reference model, using the\n      Autonomic Control Plane and the Generic Autonomic Signaling Protocol.\n\n  "Formal SignWriting", Stephen Slevinski, 2019-08-30,\n  <draft-slevinski-formal-signwriting-07.txt>\n\n      Sutton SignWriting is the universal and complete solution for written\n      sign language, ISO 15924 script code "Sgnw".  It has been applied by\n      a wide and deep international community of sign language users.\n      Sutton SignWriting is an international standard for writing sign\n      languages by hand or with computers.  From education to research,\n      from entertainment to religion, SignWriting has proven useful because\n      people are using it to write signed languages.\n      \n      Formal SignWriting is one particular computerized design for Sutton\n      SignWriting that envisions a sign as a two part word.  Each word is\n      written as a string of characters that can be recognized and\n      processed by regular expressions.  The design has been optimized for\n      display, searching, sorting, text flow, and other character\n      processing.\n      \n      Where as American Sign Language is a natural language, Formal\n      SignWriting is a formal language.  A formal language is useful in\n      mathematics, computer science, and linguistics.\n      \n      This memo defines a conceptual character encoding map for the\n      Internet community.  It is published for reference, examination,\n      implementation, and evaluation.  Distribution of this memo is\n      unlimited.\n\n  "Compact Format of IKEv2 Payloads", Valery Smyslov, 2019-09-30,\n  <draft-smyslov-ipsecme-ikev2-compact-06.txt>\n\n      This document describes a method for reducing the size of the\n      Internet Key Exchange version 2 (IKEv2) messages by using an\n      alternative format for IKE payloads.  Standard format of many IKE\n      payloads contains a lot of redundancy.  This document takes advantage\n      of this fact and specifies a way to eliminate some redundancy by\n      using denser encoding.  Reducing size of IKEv2 messages is desirable\n      for low power consumption battery powered devices.  It also helps to\n      avoid IP fragmentation of IKEv2 messages.\n\n  "MISP core format", Alexandre Dulaunoy, Andras Iklody, 2020-01-22,\n  <draft-dulaunoy-misp-core-format-09.txt>\n\n      This document describes the MISP core format used to exchange\n      indicators and threat information between MISP (Malware Information\n      and threat Sharing Platform) instances.  The JSON format includes the\n      overall structure along with the semantic associated for each\n      respective key.  The format is described to support other\n      implementations which reuse the format and ensuring an\n      interoperability with existing MISP [MISP-P] software and other\n      Threat Intelligence Platforms.\n\n  "Inter Stateful Path Computation Element (PCE) Communication Procedures.",\n  Stephane Litkowski, Siva Sivabalan, Cheng Li, Haomian Zheng, 2020-01-11,\n  <draft-litkowski-pce-state-sync-07.txt>\n\n      The Path Computation Element Communication Protocol (PCEP) provides\n      mechanisms for Path Computation Elements (PCEs) to perform path\n      computations in response to Path Computation Clients (PCCs) requests.\n      The stateful PCE extensions allow stateful control of Multi-Protocol\n      Label Switching (MPLS) Traffic Engineering Label Switched Paths (TE\n      LSPs) using PCEP.\n      \n      A Path Computation Client (PCC) can synchronize an LSP state\n      information to a Stateful Path Computation Element (PCE).  The\n      stateful PCE extension allows a redundancy scenario where a PCC can\n      have redundant PCEP sessions towards multiple PCEs.  In such a case,\n      a PCC gives control on a LSP to only a single PCE, and only one PCE\n      is responsible for path computation for this delegated LSP.  The\n      document does not state the procedures related to an inter-PCE\n      stateful communication.\n      \n      There are some use cases, where an inter-PCE stateful communication\n      can bring additional resiliency in the design, for instance when some\n      PCC-PCE sessions fails.  The inter-PCE stateful communication may\n      also provide a faster update of the LSP states when such an event\n      occurs.  Finally, when, in a redundant PCE scenario, there is a need\n      to compute a set of paths that are part of a group (so there is a\n      dependency between the paths), there may be some cases where the\n      computation of all paths in the group is not handled by the same PCE:\n      this situation is called a split-brain.  This split-brain scenario\n      may lead to computation loops between PCEs or suboptimal path\n      computation.\n      \n      This document describes the procedures to allow a stateful\n      communication between PCEs for various use-cases and also the\n      procedures to prevent computations loops.\n\n  "Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense\n  Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the\n  application code of optical interface parameters in DWDM application",\n  Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze,\n  2019-11-04, <draft-ggalimbe-ccamp-flex-if-lmp-09.txt>\n\n      This experimental memo defines extensions to LMP(rfc4209) for\n      managing Optical parameters associated with Wavelength Division\n      Multiplexing (WDM) adding a set of parameters related to multicarrier\n      DWDM interfaces to be used in Spectrum Switched Optical Networks\n      (sson).\n\n  "Terminology for Constrained-Node Networks", Carsten Bormann, Mehmet Ersue,\n  Ari Keranen, Carles Gomez, 2019-09-02, <draft-bormann-lwig-7228bis-05.txt>\n\n      The Internet Protocol Suite is increasingly used on small devices\n      with severe constraints on power, memory, and processing resources,\n      creating constrained-node networks.  This document provides a number\n      of basic terms that have been useful in the standardization work for\n      constrained-node networks.\n\n  "BIER in BABEL", Zheng Zhang, Tony Przygienda, 2019-11-03,\n  <draft-zhang-bier-babel-extensions-02.txt>\n\n      BIER introduces a novel multicast architecture.  It does not require\n      a signaling protocol to explicitly build multicast distribution\n      trees, nor does it require intermediate nodes to maintain any per-\n      flow state.\n      \n      Babel defines a distance-vector routing protocol that operates in a\n      robust and efficient fashion both in wired as well as in wireless\n      mesh networks.  This document defines a way to carry necessary BIER\n      signaling information in Babel.\n\n  "Encapsulating IPsec ESP in UDP for Load-balancing", Xiaohu Xu, Shraddha\n  Hegde, Dacheng Zhang, Liang Xia, 2020-01-20,\n  <draft-xu-ipsecme-esp-in-udp-lb-03.txt>\n\n      IPsec Virtual Private Network (VPN) is widely used by enterprises to\n      interconnect their geographical dispersed branch office locations\n      across the Wide Area Network (WAN) or the Internet, especially in the\n      Software-Defined-WAN (SD-WAN) era.  In addition, IPsec is also\n      increasingly used by cloud providers to encrypt IP traffic traversing\n      data center interconnect WAN so as to meet the security and\n      compliance requirements, especially in financial cloud and\n      governmental cloud environments.  To fully utilize the bandwidth\n      available in the WAN or the Internet, load balancing of IPsec traffic\n      over Equal Cost Multi-Path (ECMP) and/or Link Aggregation Group (LAG)\n      is much attractive to those enterprises and cloud providers.  This\n      document defines a method to encapsulate IPsec Encapsulating Security\n      Payload (ESP) packets over UDP tunnels for improving load-balancing\n      of IPsec ESP traffic.\n\n  "Report on Problem Solving Experiment for Realization of Web-API-based\n  IoT", Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Hiroshi Masuda,\n  Shintaro Ogura, Koichi KUNITAKE, 2020-01-09, <draft-baba-iot-webapi-06.txt>\n\n      The University of Tokyo (UOT) is currently performing a demonstration\n      experiment in COMMA House, the experimental smart-house owned by UOT\n      and used as a connected house.  The things installed in the house\n      (Things) are operated using applications on smartphones and other\n      devices.  The various Things in the smart-house are operated online\n      via a Web API that has been created as a prototype.  This report is\n      an overview of the experimental demonstration, which is gradually\n      clarifying that Web API should be effective for solving issues for\n      IoT.\n\n  "Service Function Chaining Use Cases in Fog RAN", Carlos Bernardos, Akbar\n  Rahman, Alain Mourad, 2019-09-07, <draft-bernardos-sfc-fog-ran-06.txt>\n\n      Fog Radio Access Networks (RAN) refers to the part of the RAN that is\n      virtualized at the very edge of the network, even at the end-user\n      device.  Fog RAN support is considered critical for the 5G mobile\n      network architectures currently being developed in various research,\n      standardization and industry forums.  Since fog RAN builds on top of\n      virtualization and can involve several virtual functions running on\n      different virtualized resources, Service function chaining (SFC)\n      support for the fog RAN will be critical.  This document describes\n      the overall fog RAN approach and also gives some use cases.  Finally\n      it proposes some requirements to be considered in the development of\n      the SFC architecture and related protocols.\n\n  "Equal-Cost Multipath Considerations for BGP", Petr Lapukhov, Jeff\n  Tantsura, 2019-11-04, <draft-lapukhov-bgp-ecmp-considerations-03.txt>\n\n      BGP (Border Gateway Protocol) [RFC4271] employs tie-breaking logic to\n      select a single best path among multiple paths available, known as\n      BGP best path selection.  At the same time, it has become a common\n      practice to allow for "equal-cost multipath" (ECMP) selection and\n      programming of multiple next-hops in routing tables.  This document\n      summarizes some common considerations for the ECMP logic when BGP is\n      used as the routing protocol, with the intent of providing common\n      reference for otherwise unstandardized set of features.\n\n  "Thing-to-Thing Data Hub", Klaus Hartke, 2019-11-04,\n  <draft-hartke-t2trg-data-hub-05.txt>\n\n      A "Thing-to-Thing Data Hub" is a RESTful, hypermedia-driven Web\n      application that can be used in Thing-to-Thing communications to\n      share data items such as thing descriptions, configurations, resource\n      descriptions, or firmware updates at a central location.\n\n  "Adaptive IPv4 Address Space", Abraham Chen, Ramamurthy Ati, Abhay\n  Karandikar, David Crowe, 2019-12-01,\n  <draft-chen-ati-adaptive-ipv4-address-space-06.txt>\n\n      This document describes a solution to the Internet address depletion\n      issue through the use of an existing Option mechanism that is part of\n      the original IPv4 protocol. This proposal, named EzIP (phonetic for\n      Easy IPv4), outlines the IPv4 public address pool expansion and the\n      Internet system architecture enhancement considerations. EzIP may\n      expand an IPv4 address by a factor of 256M without affecting the\n      existing IPv4 based Internet, or the current private networks. It is\n      in full conformance with the IPv4 protocol, and supports not only\n      both direct and private network connectivity, but also their\n      interoperability. EzIP deployments may coexist with existing Internet\n      traffic and the IoT (Internet of Things) operations without\n      perturbing their setups, while offering end-users the freedom to\n      indepdently choose which service. EzIP may be implemented as a\n      software or firmware enhancement to Internet edge routers or private\n      network routing gateways, wherever needed, or simply installed as an\n      inline adjunct hardware module between the two, enabling a seamless\n      introduction. The 256M case detailed here establishes a complete\n      spherical layer of routers for interfacing between the Internet fabic\n      (core plus edge routers) and the end user premises. Incorporating\n      caching proxy technology in the gateway, a fairly large geographical\n      region may enjoy address expansion based on as little as one ordinary\n      IPv4 public address utilizing IP packets with degenerated EzIP\n      header. If IPv4 public pool allocations were reorganized, the\n      assignable pool could be multiplied 512M fold or even more. EzIP will\n      immediately resolve local IPv4 address shortages, while being\n      transparent to the rest of the Internet. Under the Dual-Stack\n      environment, these proposed interim facilities will relieve the IPv4\n      address shortage issue, while affording IPv6 more time to reach\n      maturity and to provide the availability levels required for\n      delivering a long-term general service.\n\n  "Mobility Capability Negotiation and Protocol Selection", Zhiwei Yan,\n  Guanggang Geng, Jong-Hyouk Lee, Anthony Chan, 2019-09-19,\n  <draft-yan-dmm-man-05.txt>\n\n      Based on different requirements, multiple mobility management\n      protocols have been developed.  Different protocols have different\n      functional requirements on the network element or the host and then a\n      scheme should be used in order to support the negotiation and\n      selection of adopted mobility management protocol when a host\n      accesses to a new network.  In this draft, this issue is analyzed.\n\n  "BGP Neighbor Discovery", Xiaohu Xu, Ketan Talaulikar, Kunyang Bi, Jeff\n  Tantsura, Nikos Triantafillis, 2019-11-26,\n  <draft-xu-idr-neighbor-autodiscovery-12.txt>\n\n      BGP is being used as the underlay routing protocol in some large-\n      scaled data centers (DCs).  Most popular design followed is to do\n      hop-by-hop external BGP (EBGP) session configurations between\n      neighboring routers on a per link basis.  The provisioning of BGP\n      neighbors in routers across such a DC brings its own operational\n      complexity.\n      \n      This document introduces a BGP neighbor discovery mechanism that\n      greatly simplifies BGP operations in such DC and other networks by\n      automatic setup of BGP sessions between neighbor routers using this\n      mechanism.\n\n  "Slipmux: Using an UART interface for diagnostics, configuration, and\n  packet transfer", Carsten Bormann, Tobias Kaupat, 2019-11-04,\n  <draft-bormann-t2trg-slipmux-03.txt>\n\n      Many research and maker platforms for Internet of Things\n      experimentation offer a serial interface.  This is often used for\n      programming, diagnostic output, as well as a crude command interface\n      ("AT interface").  Alternatively, it is often used with SLIP\n      (RFC1055) to transfer IP packets only.\n      \n      The present report describes how to use a single serial interface for\n      diagnostics, configuration commands and state readback, as well as\n      packet transfer.\n\n  "Hypertext Transfer Protocol (HTTP) over multicast QUIC", Lucas Pardue,\n  Richard Bradbury, Sam Hurst, 2019-08-08,\n  <draft-pardue-quic-http-mcast-05.txt>\n\n      This document specifies a profile of the QUIC protocol and the HTTP/3\n      mapping that facilitates the transfer of HTTP resources over\n      multicast IP using the QUIC transport as its framing and\n      packetisation layer.  Compatibility with the QUIC protocol\'s syntax\n      and semantics is maintained as far as practical and additional\n      features are specified where this is not possible.\n\n  "A Definition of the Term "Soon" for Use in Discussions with Working Group\n  Chairs and Area Directors", Adrian Farrel, 2019-10-08,\n  <draft-farrel-soon-06.txt>\n\n      Many discussions with IETF Area Directors and Working Group Chairs\n      utilize the word "Soon" to qualify a commitment to action.  This\n      document attempts to provide a definition of that term so that common\n      expectations may be realistically set.\n\n  "RFC Style Guide", Heather Flanagan, RFC Editor, 2019-10-01,\n  <draft-flanagan-7322bis-04.txt>\n\n      This document describes the fundamental and unique style conventions\n      and editorial policies currently in use for the RFC Series.  It\n      captures the RFC Editor\'s basic requirements and offers guidance\n      regarding the style and structure of an RFC.  Additional guidance is\n      captured on a website that reflects the experimental nature of that\n      guidance and prepares it for future inclusion in the RFC Style Guide.\n      This document obsoletes RFC 7322, "RFC Style Guide".\n\n  "Compressed BGP Update Message", Tony Przygienda, Avinash Lingala, Csaba\n  Mate, Jeff Tantsura, 2019-08-19,\n  <draft-przygienda-idr-compressed-updates-07.txt>\n\n      This document provides specification of an optional compressed BGP\n      update message format to allow family independent reduction in BGP\n      control traffic volume.\n\n  "User-Plane Protocols for Multiple Access Management Service", Jing Zhu,\n  SungHoon Seo, Satish Kanugovi, Shuping Peng, 2019-10-01,\n  <draft-zhu-intarea-mams-user-protocol-08.txt>\n\n      Today, a device can be simultaneously connected to multiple\n      communication networks based on different technology implementations\n      and network architectures like WiFi, LTE, and DSL. In such multi-\n      connectivity scenario, it is desirable to combine multiple access\n      networks or select the best one to improve quality of experience for\n      a user and improve overall network utilization and efficiency. This\n      document presents the u-plane protocols for a multi access\n      management services (MAMS) framework that can be used to flexibly\n      select the combination of uplink and downlink access and core\n      network paths having the optimal performance, and user plane\n      treatment for improving network utilization and efficiency and\n      enhanced quality of experience for user applications.\n\n  "Vehicular Neighbor Discovery for IP-Based Vehicular Networks", Jaehoon\n  Jeong, Yiwen Shen, Zhong Xiang, Sandra Cespedes, 2019-11-04,\n  <draft-jeong-ipwave-vehicular-neighbor-discovery-08.txt>\n\n      This document specifies a Vehicular Neighbor Discovery (VND) as an\n      extension of IPv6 Neighbor Discovery (ND) for IP-based vehicular\n      networks.  An optimized Address Registration and a multihop Duplicate\n      Address Detection (DAD) mechanism are performed for having operation\n      efficiency and also saving both wireless bandwidth and vehicle\n      energy.  Also, three new ND options for prefix discovery, service\n      discovery, and mobility information report are defined to announce\n      the network prefixes and services inside a vehicle (i.e., a vehicle\'s\n      internal network).\n\n  "DNS Name Autoconfiguration for Internet-of-Things Devices in IP-Based\n  Vehicular Networks", Jaehoon Jeong, Sejun Lee, J., PARK, 2019-11-04,\n  <draft-jeong-ipwave-iot-dns-autoconf-07.txt>\n\n      This document specifies an autoconfiguration scheme for device\n      discovery and service discovery in IP-based vehicular networks.\n      Through the device discovery, this document supports the global (or\n      local) DNS naming of Internet-of-Things (IoT) devices, such as\n      sensors, actuators, and in-vehicle units.  By this scheme, the DNS\n      name of an IoT device can be autoconfigured with the device\'s model\n      information in wired and wireless target networks (e.g., vehicle,\n      road network, home, office, shopping mall, and smart grid).  Through\n      the service discovery, IoT users (e.g., drivers, passengers, home\n      residents, and customers) in the Internet (or local network) can\n      easily identify each device for monitoring and remote-controlling it\n      in a target network.\n\n  "Signaling extensions for Media Channel sub-carriers configuration in\n  Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC)\n  Optical Line Systems.", Gabriele Galimberti, Domenico Fauci, Andrea\n  Zanardi, Lorenzo Galvagni, 2019-11-04,\n  <draft-ggalimbe-ccamp-flexigrid-carrier-label-08.txt>\n\n      This memo defines the signaling extensions for managing Spectrum\n      Switched Optical Network (SSON) parameters shared between the Client\n      and the Network and inside the Network in accordance to the model\n      described in RFC 7698.  The extensions are in accordance and\n      extending the parameters defined in ITU-T Recommendation\n      G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872].\n\n  "OSPF Extensions for Broadcast Inter-AS TE Link", Huaimo Chen, Mehmet Toy,\n  Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang, 2020-01-06,\n  <draft-chen-ospf-ias-lk-04.txt>\n\n      This document presents extensions to the Open Shortest Path First\n      (OSPF) for advertising broadcast inter-AS Traffic Engineering (TE)\n      links.\n\n  "ISIS Extensions for Broadcast Inter-AS TE Link", Huaimo Chen, Mehmet Toy,\n  Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang, 2020-01-06,\n  <draft-chen-isis-ias-lk-04.txt>\n\n      This document presents extensions to the ISIS protocol for\n      advertising broadcast inter-AS Traffic Engineering (TE) links.\n\n  "BGP Logical Link Discovery Protocol (LLDP) Peer Discovery", Acee Lindem,\n  Keyur Patel, Shawn Zandi, Jeffrey Haas, Xiaohu Xu, 2019-11-20,\n  <draft-acee-idr-lldp-peer-discovery-06.txt>\n\n      Link Layer Discovery Protocol (LLDP) or IEEE Std 802.1AB is\n      implemented in networking equipment from many vendors.  It is natural\n      for IETF protocols to avail this protocol for simple discovery tasks.\n      This document describes how BGP would use LLDP to discover directly\n      connected and 2-hop peers when peering is based on loopback\n      addresses.\n\n  "Virtual Hub-and-Spoke in BGP EVPNs", Keyur Patel, Ali Sajassi, John Drake,\n  Zhaohui Zhang, Wim Henderickx, 2019-09-02,\n  <draft-keyupate-bess-evpn-virtual-hub-02.txt>\n\n      Ethernet Virtual Private Network (EVPN) solution is becoming\n      pervasive for Network Virtualization Overlay (NVO) services in data\n      center (DC) applications and as the next generation virtual private\n      LAN services in service provider (SP) applications.\n      \n      The use of host IP default route and host unknown MAC route within a\n      DC is well understood in order to ensure that leaf nodes within a DC\n      only learn and store host MAC and IP addresses for that DC. All other\n      host MAC and IP addresses from remote DCs are learned and stored in\n      DC GW nodes thus alleviating leaf nodes from learning host MAC and IP\n      addresses from the remote DCs.\n      \n      This draft further optimizes the MAC and IP address learning at the\n      leaf nodes such that a leaf node within a DC only needs to learn and\n      store MAC and IP addresses associated with the sites directly\n      connected to it. A leaf node does not need to learn and store MAC and\n      IP addresses from any other leaf nodes thus reducing the number of\n      learned MACs and IP addresses per EVI substantially.\n      \n      The modifications provided by this draft updates and extends RFC7024\n      for BGP EVPN Address Family.\n\n  "SWORN: Secure Wake on Radio Nudging", Carsten Bormann, 2019-10-20,\n  <draft-bormann-t2trg-sworn-03.txt>\n\n      Normally off devices (RFC7228) would need to expend considerable\n      energy resources to be reachable at all times.  Instead, MAC layer\n      mechanisms are often employed that allow the last hop router of the\n      device to "wake" the device via radio when needed.  Activating these\n      devices even for a short time still does expend energy and thus\n      should be available to authorized correspondents only.\n      Traditionally, this has been achieved by heavy firewalling, allowing\n      only authorized hosts to reach the device at all.  This may be too\n      inflexible for an Internet of Things.\n      \n      The present report describes how to use a combination of currently\n      standardized (or in progress) technologies to securely effect this\n      authorization.\n\n  "Registries for Web Authentication (WebAuthn)", Jeff Hodges, Giridhar\n  Mandyam, Michael Jones, 2019-12-12,\n  <draft-hodges-webauthn-registries-04.txt>\n\n      This specification defines IANA registries for W3C Web Authentication\n      attestation statement format identifiers and extension identifiers.\n\n  "Deployments With Insertion of IPv6 Segment Routing Headers", Daniel Voyer,\n  Clarence Filsfils, Darren Dukes, Satoru Matsushima, John Leddy, Zhenbin Li,\n  Jim Guichard, 2019-11-19,\n  <draft-voyer-6man-extension-header-insertion-08.txt>\n\n      SRv6 is deployed in multiple provider networks.\n      \n      This document describes the usage of SRH insertion and deletion\n      within the SR domain and how security and end-to-end integrity is\n      guaranteed.\n\n  "The Hashed Token SASL Mechanism", Florian Schmaus, Christoph Egger,\n  2019-11-01, <draft-schmaus-kitten-sasl-ht-07.txt>\n\n      This document specifies the family of Hashed Token SASL mechanisms\n      which enable a proof-of-possession-based authentication scheme and\n      are meant to be used for quick re-authentication of a previous\n      session.  The Hashed Token SASL mechanism\'s authentication sequence\n      consists of only one round-trip.  The usage of short-lived,\n      exclusively ephemeral hashed tokens is achieving the single round-\n      trip property.  The SASL mechanism specified herin further provides\n      hash agility, mutual authentication and is secured by channel\n      binding.\n\n  "The \'payto\' URI scheme for payments", Florian Dold, Christian Grothoff,\n  2019-12-17, <draft-dold-payto-10.txt>\n\n      This document defines the \'payto\' Uniform Resource Identifier (URI)\n      scheme for designating targets for payments.\n      \n      A unified URI scheme for all payment target types allows applications\n      to offer user interactions with URIs that represent payment targets,\n      simplifying the introduction of new payment systems and applications.\n\n  "NEAT Sockets API", Thomas Dreibholz, 2020-01-23,\n  <draft-dreibholz-taps-neat-socketapi-06.txt>\n\n      This document describes a BSD Sockets-like API on top of the\n      callback-based NEAT User API.  This facilitates porting existing\n      applications to use a subset of NEAT\'s functionality.\n\n  "Specification of DNS over Dedicated QUIC Connections", Christian Huitema,\n  Melinda Shore, Allison Mankin, Sara Dickinson, Jana Iyengar, 2019-09-07,\n  <draft-huitema-quic-dnsoquic-07.txt>\n\n      This document describes the use of QUIC to provide transport privacy\n      for DNS.  The encryption provided by QUIC has similar properties to\n      that provided by TLS, while QUIC transport eliminates the head-of-\n      line blocking issues inherent with TCP and provides more efficient\n      error corrections than UDP.  DNS over QUIC (DNS/QUIC) has privacy\n      properties similar to DNS over TLS specified in RFC7858, and\n      performance similar to classic DNS over UDP.\n\n  "Neighbor Vehicle Discovery and Service in IP-Based Vehicular Networks",\n  Zhiwei Yan, Jong-Hyouk Lee, Jaehoon Jeong, 2019-11-17,\n  <draft-yan-ipwave-nd-05.txt>\n\n      For Cooperative Adaptive Cruise Control (C-ACC), platooning and other\n      typical use cases in ITS, direct IP communication between neighbor\n      vehicles poses the following two issues: 1) how to discover a\n      neighbor vehicle and the demanded service; and 2) how to discover the\n      link-layer address of the neighbor vehicle and selected server.  This\n      document presents a solution to these problems based on DNS-SD/mDNS\n      [RFC6762][RFC6763].\n\n  "Performance Measurement (PM) with Alternate Marking Method in Service\n  Function Chaining (SFC) Domain", Gregory Mirsky, Giuseppe Fioccola, Tal\n  Mizrahi, 2019-12-20, <draft-mirsky-sfc-pmamm-09.txt>\n\n      This document describes how the alternate marking method can be used\n      as the efficient performance measurement method taking advantage of\n      the actual data flows in a Service Function Chaining (SFC) domain.\n\n  "BFD for Multipoint Networks over Point-to-Multi-Point MPLS LSP", Gregory\n  Mirsky, 2019-11-26, <draft-mirsky-mpls-p2mp-bfd-08.txt>\n\n      This document describes procedures for using Bidirectional Forwarding\n      Detection (BFD) for multipoint networks to detect data plane failures\n      in Multiprotocol Label Switching (MPLS) point-to-multipoint (p2mp)\n      Label Switched Paths (LSPs).  It also describes the applicability of\n      LSP Ping, as in-band, and the control plane, as out-band, solutions\n      to bootstrap a BFD session in this environment.\n\n  "Bidirectional Forwarding Detection (BFD) in Segment Routing Networks Using\n  MPLS Dataplane", Gregory Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen,\n  2019-12-19, <draft-mirsky-spring-bfd-09.txt>\n\n      Segment Routing (SR) architecture leverages the paradigm of source\n      routing.  It can be realized in the Multiprotocol Label Switching\n      (MPLS) network without any change to the data plane.  A segment is\n      encoded as an MPLS label, and an ordered list of segments is encoded\n      as a stack of labels.  Bidirectional Forwarding Detection (BFD) is\n      expected to monitor any existing path between systems.  This document\n      defines how to use Label Switched Path Ping to bootstrap a BFD\n      session, control path in reverse direction of the SR-MPLS tunnel and\n      applicability of BFD Demand mode in the SR-MPLS domain.\n\n  "Loop avoidance using Segment Routing", Ahmed Bashandy, Clarence Filsfils,\n  Stephane Litkowski, Bruno Decraene, Pierre Francois, Peter Psenak,\n  2020-01-14, <draft-bashandy-rtgwg-segment-routing-uloop-08.txt>\n\n      This document presents a mechanism aimed at providing loop avoidance\n      in the case of IGP network convergence event.  The solution relies on\n      the temporary use of SR policies ensuring loop-freeness over the\n      post-convergence paths from the converging node to the destination.\n\n  "Service Redundancy using BFD", Sami Boutros, Ankur Dubey, Reshad Rahman,\n  2020-01-24, <draft-adubey-bfd-service-redundancy-03.txt>\n\n      In a data center, when multiple routing/service nodes are providing\n      single active redundancy for a set of L2, L3 and/or L4-L7 services.\n      Both non-revertive and revertive fail over modes are required for the\n      services.  This draft describes a method to achieve the non-revertive\n      and revertive fail over modes for services using Bidirectional\n      Forwarding Detection (BFD).\n\n  "Responder Initiated IP Addresses Update in MOBIKE", Valery Smyslov,\n  2019-11-27, <draft-smyslov-ipsecme-ikev2-r-mobike-05.txt>\n\n      IKEv2 Mobility and Multihoming Protocol (MOBIKE), defined in\n      [RFC4555] allows peers to update their IP addresses without re-\n      establishing IKE and IPsec Security Associations (SAs).  In the\n      MOBIKE protocol it is the Initiator of the IKE SA, who is responsible\n      for selecting new SA addresses and for initiating the IP addresses\n      update procedure.  This document presents an extension to the MOBIKE\n      protocol that allows the Responder to initiate IP address update.\n      The document updates [RFC4555].\n\n  "A Message Header to Identify Subscription Form Mail", John Levine,\n  2019-11-26, <draft-levine-mailbomb-header-02.txt>\n\n      Many organizations have web forms that provoke an e-mail confirmation\n      to the e-mail address provided in the form.  Malicious entities do\n      bulk form submissions with forged addresses, resulting in mail floods\n      to the holders of those addresses.  This document defines a message\n      header to identify mail sent in response to web forms, so that\n      recipient mail systems can better recognize and mitigate the mail\n      floods.\n\n  "BFD in Demand Mode over Point-to-Point MPLS LSP", Gregory Mirsky,\n  2019-12-22, <draft-mirsky-bfd-mpls-demand-06.txt>\n\n      This document describes procedures for using Bidirectional Forwarding\n      Detection (BFD) in Demand mode to detect data plane failures in\n      Multiprotocol Label Switching (MPLS) point-to-point Label Switched\n      Paths.\n\n  "pretty Easy privacy (pEp): Privacy by Default", Volker Birk, Hernani\n  Marques, Bernie Hoeneisen, 2019-11-04, <draft-birk-pep-05.txt>\n\n      The pretty Easy privacy (pEp) model and protocols describe a set of\n      conventions for the automation of operations traditionally seen as\n      barriers to the use and deployment of secure, privacy-preserving end-\n      to-end interpersonal messaging.  These include, but are not limited\n      to, key management, key discovery, and private key handling\n      (including peer-to-peer synchronization of private keys and other\n      user data across devices).  Human Rights-enabling principles like\n      Data Minimization, End-to-End and Interoperability are explicit\n      design goals.  For the goal of usable privacy, pEp introduces means\n      to verify communication between peers and proposes a trust-rating\n      system to denote secure types of communications and signal the\n      privacy level available on a per-user and per-message level.\n      Significantly, the pEp protocols build on already available security\n      formats and message transports (e.g., PGP/MIME with email), and are\n      written with the intent to be interoperable with already widely-\n      deployed systems in order to ease adoption and implementation.  This\n      document outlines the general design choices and principles of pEp.\n\n  "SFC OAM for path consistency", Ting Ao, Gregory Mirsky, Zhonghua Chen,\n  Kent Leung, 2019-12-01, <draft-ao-sfc-oam-path-consistency-07.txt>\n\n      Service Function Chain (SFC) defines an ordered set of service\n      functions (SFs) to be applied to packets and/or frames and/or flows\n      selected as a result of classification.  SFC Operation,\n      Administration and Maintenance can monitor the continuity of the SFC,\n      i.e., that all elements of the SFC are reachable to each other in the\n      downstream direction.  But SFC OAM must support verification that the\n      order of traversing these SFs corresponds to the state defined by the\n      SFC control plane or orchestrator, the metric referred in this\n      document as the path consistency of the SFC.  This document defines a\n      new SFC active OAM method to support SFC consistency check, i.e.\n      verification that all elements of the given SFC are being traversed\n      in the expected order.\n\n  "Controlled Return Path for Service Function Chain (SFC) OAM", Ting Ao,\n  Gregory Mirsky, Zhonghua Chen, 2019-12-01,\n  <draft-ao-sfc-oam-return-path-specified-05.txt>\n\n      This document defines an extension to the Service Function Chain\n      (SFC) Operation, Administration and Maintenance (OAM) that enables\n      control of the Echo Reply return path directing it over a Reverse\n      Service Function Path.  Enforcing the specific return path can be\n      used to verify the bidirectional connectivity of SFC and increase the\n      robustness of SFC OAM.\n\n  "SOCKS Protocol Version 6", Vladimir Olteanu, Dragos Niculescu, 2019-11-04,\n  <draft-olteanu-intarea-socks-6-08.txt>\n\n      The SOCKS protocol is used primarily to proxy TCP connections to\n      arbitrary destinations via the use of a proxy server.  Under the\n      latest version of the protocol (version 5), it takes 2 RTTs (or 3, if\n      authentication is used) before data can flow between the client and\n      the server.\n      \n      This memo proposes SOCKS version 6, which reduces the number of RTTs\n      used, takes full advantage of TCP Fast Open, and adds support for\n      0-RTT authentication.\n\n  "MPT Network Layer Multipath Library", Gabor Lencse, Szabolcs Szilagyi,\n  Ferenc Fejes, Marius Georgescu, 2019-12-12, <draft-lencse-tsvwg-mpt-05.txt>\n\n      Although several contemporary IT devices have multiple network\n      interfaces, communication sessions are restricted to use only one of\n      them at a time due to the design of the TCP/IP protocol stack: the\n      communication endpoint is identified by an IP address and a TCP or\n      UDP port number. The simultaneous use of these multiple interfaces\n      for a communication session would improve user experience through\n      higher throughput and improved resilience to network failures.\n      \n      MPT is a network layer multipath solution, which provides a tunnel\n      over multiple paths using the GRE-in-UDP specification, thus being\n      different from both MPTCP and Huawei\'s GRE Tunnel Bonding Protocol.\n      \n      MPT can also be used as a router, routing the packets among several\n      networks between the tunnel endpoints, thus establishing a multipath\n      site-to-site connection.\n      \n      The version of tunnel IP and the version of path IP are independent\n      from each other, therefore MPT can also be used for IPv6 transition\n      purposes.\n\n  "QUIC Interdomain Troubleshooting", Stephan Emile, Mathilde Cayla, Arnaud\n  Braud, Frederic Fieau, Alexandre Ferrieux, Marcus Ihlar, 2020-01-09,\n  <draft-stephan-quic-interdomain-troubleshooting-04.txt>\n\n      On-path network performance measurements methods currently deployed\n      contribute to the ossification of the Internet because they are\n      expensive to deploy and to maintain. This draft motivates the\n      exposure of QUIC header fields for on-path network measurements and\n      their specification in the QUIC core protocol as a solution to avoid\n      on-path network performance measurements to ossify the IP stack in\n      the future.\n\n  "Loop Protection in EVPN networks", Jorge Rabadan, Senthil Sathappan, Kiran\n  Nagaraj, Julio Bueno, Jose Crespo, 2019-08-05,\n  <draft-snr-bess-evpn-loop-protect-04.txt>\n\n      Ethernet Virtual Private Networks (EVPN) is becoming the de-facto\n      standard-based control plane solution for Data Center and layer-2\n      Service Provider applications. The risk of loops caused by backdoor\n      paths accidentally created within the same broadcast domain, is a\n      general common concern, especially among Service Providers in large\n      Layer-2 networks. While other layer-2 Ethernet technologies use\n      Spanning Tree based Protocols (xSTP) to provide a network-wide loop\n      protection, EVPN has the right tools to detect and protect the\n      network against loops in an efficient and effective way. This\n      document describes a mechanism to provide global loop protection in\n      EVPN networks.\n\n  "Problem Statement and Considerations for ROAs issued with Multiple\n  Prefixes", Zhiwei Yan, Randy Bush, Guanggang Geng, Jiankang Yao,\n  2019-09-10, <draft-yan-sidrops-roa-considerations-03.txt>\n\n      The address space holder needs to issue an ROA object when it\n      authorizes one or more ASes to originate routes to multiple prefixes.\n      During the process of ROA issuance, the address space holder needs to\n      specify an origin AS for a list of IP prefixes.  Besides, the address\n      space holder has a free choice to put multiple prefixes into a single\n      ROA or issue separate ROAs for each prefix based on the current\n      specification.  This memo analyzes and presents some operational\n      problems which may be caused by the misconfigurations of ROAs\n      containing multiple IP prefixes.  Some suggestions and considerations\n      also have been proposed.\n\n  "Linkset: Media Types and a Link Relation Type for Link Sets", Erik Wilde,\n  Herbert Van de Sompel, 2019-12-31, <draft-wilde-linkset-05.txt>\n\n      This specification defines two media types for representing sets of\n      links and a link relation type for referring to sets of links.  The\n      media types can be used to represents links in a standalone fashion,\n      in one case in the native format as used in the HTTP "Link" header\n      field, and in the other case in a JSON-based format.  The link\n      relation type can be used to point at a resource that provides a set\n      of links.\n\n  "LISP for the Mobile Network", Dino Farinacci, Padma Pillay-Esnault, Uma\n  Chunduri, 2019-09-09, <draft-farinacci-lisp-mobile-network-06.txt>\n\n      This specification describes how the LISP architecture and protocols\n      can be used in a LTE/5G mobile network to support session survivable\n      EID mobility.  A recommendation is provided to SDOs on how to\n      integrate LISP into the mobile network.\n\n  "HTTP Authentication with SASL", Rick van Rein, 2020-01-20,\n  <draft-vanrein-httpauth-sasl-03.txt>\n\n      Most application-level protocols standardise their authentication\n      exchanges under the SASL framework.  HTTP has taken another course,\n      and often ends up replicating the work to allow individual\n      mechanisms.  This specification adopts full SASL authentication into\n      HTTP.\n\n  "Reassignment of System Ports to the IESG", Mirja Kuehlewind, Sabrina\n  Tanamal, 2019-06-06, <draft-kuehlewind-system-ports-04.txt>\n\n      In the IANA Service Name and Transport Protocol Port Number Registry,\n      a large number of System Ports is currently assigned to individuals\n      or companies who have registered the port for the use with a certain\n      protocol before RFC6335 was published.  For some of these ports, RFCs\n      exist that describe the respective protocol; for others, RFCs are\n      under development that define, re-define, or assign the protocol used\n      for the respective port, e.g. in case of so-far unused UDP ports that\n      have been registered together with the respective TCP port.  In these\n      cases the IESG has the change control about the protocol used on the\n      port (as described in an RFC) but does not have the change control\n      about the port usage itself.  Currently, to transfer the change\n      control to the IESG, the original assignee has to be contacted to\n      initialize this transfer.  As it is not always possible to get in\n      touch with the original assignee, e.g. because of out-dated contact\n      information or other reasons, and the current practice of case-by-\n      case changes does not scale well, this document instructs IANA to\n      perform actions with the goal to reassigns all System Ports to the\n      IESG that have been assigned to individuals prior to the publication\n      of RFC6335.\n\n  "Guide for building an ECC pki", Robert Moskowitz, Henk Birkholz, Liang\n  Xia, Michael Richardson, 2019-08-13, <draft-moskowitz-ecdsa-pki-07.txt>\n\n      This memo provides a guide for building a PKI (Public Key\n      Infrastructure) using openSSL.  All certificates in this guide are\n      ECDSA, P-256, with SHA256 certificates.  Along with common End Entity\n      certificates, this guide provides instructions for creating IEEE\n      802.1AR iDevID Secure Device certificates.\n\n  "Signed HTTP Exchanges", Jeffrey Yasskin, 2019-11-04,\n  <draft-yasskin-http-origin-signed-responses-08.txt>\n\n      This document specifies how a server can send an HTTP exchange--a\n      request URL, content negotiation information, and a response--with\n      signatures that vouch for that exchange\'s authenticity.  These\n      signatures can be verified against an origin\'s certificate to\n      establish that the exchange is authoritative for an origin even if it\n      was transferred over a connection that isn\'t.  The signatures can\n      also be used in other ways described in the appendices.\n      \n      These signatures contain countermeasures against downgrade and\n      protocol-confusion attacks.\n\n  "Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol\n  (GRASP)", Brian Carpenter, Sheng Jiang, Bing Liu, 2020-01-09,\n  <draft-carpenter-anima-grasp-bulk-05.txt>\n\n      This document describes how bulk data may be transferred between\n      Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol\n      (GRASP).  Although not an equivalent of a file transfer protocol,\n      such a technique may be used for non-urgent transfer of data too\n      large to fit into a normal GRASP message.\n\n  "IPv6 Source Routing for ultralow Latency", Andreas Foglar, Mike Parker,\n  Theodoros Rokkas, 2020-01-20, <draft-foglar-ipv6-ull-routing-06.txt>\n\n      This Internet-Draft describes a hierarchical addressing scheme\n      for IPv6, intentionally very much simplified to allow for very\n      fast source routing experimentation using simple forwarding\n      nodes. Research groups evaluate achievable latency reduction\n      for special applications such as radio access networks,\n      industrial networks or other networks requiring very low\n      latency.\n\n  "Controller Based BGP Multicast Signaling", Zhaohui Zhang, Robert Raszuk,\n  Dante Pacella, Arkadiy Gulko, 2019-11-18,\n  <draft-zzhang-bess-bgp-multicast-controller-02.txt>\n\n      This document specifies a way that one or more centralized\n      controllers can use BGP to set up a multicast distribution tree in a\n      network.  In the case of labeled tree, the labels are assigned by the\n      controllers either from the controllers\' local label spaces, or from\n      a common Segment Routing Global Block (SRGB), or from each routers\n      Segment Routing Local Block (SRLB) that the controllers learn.  In\n      case of labeled unidirectional tree and label allocation from the\n      common SRGB or from the controllers\' local spaces, a single common\n      label can be used for all routers on the tree to send and receive\n      traffic with.  Since the controllers calculate the trees, they can\n      use sophisticated algorithms and constraints to achieve traffic\n      engineering.\n\n  "MISP galaxy format", Alexandre Dulaunoy, Andras Iklody, Deborah Servili,\n  2019-10-04, <draft-dulaunoy-misp-galaxy-format-07.txt>\n\n      This document describes the MISP galaxy format which describes a\n      simple JSON format to represent galaxies and clusters that can be\n      attached to MISP events or attributes.  A public directory of MISP\n      galaxies is available and relies on the MISP galaxy format.  MISP\n      galaxies are used to add further informations on a MISP event.  MISP\n      galaxy is a public repository [MISP-G] [MISP-G-DOC] of known malware,\n      threats actors and various other collections of data that can be used\n      to mark, classify or label data in threat information sharing.\n\n  "Simple Group Keying Protocol (SGKP)", Donald Eastlake, Dacheng Zhang,\n  2020-01-15, <draft-ietf-trill-group-keying-05.txt>\n\n      This document specifies a simple general group keying protocol that\n      provides for the distribution of shared secret keys to group members\n      and the management of such keys. It assumes that secure pairwise keys\n      can be created between any two group members.\n\n  "Registration Procedures for Private Enterprise Numbers (PENs)", Amanda\n  Baber, Paul Hoffman, 2019-10-25, <draft-pti-pen-registration-06.txt>\n\n      This document describes how Private Enterprise Numbers (PENs) are\n      registered by IANA.  It shows how to request a new PEN and how to\n      request an update to a current PEN.  It also gives a brief overview\n      of PEN uses.\n\n  "Elliptic curve 2y^2=x^3+x over field size 8^91+5", Dan Brown, 2019-10-03,\n  <draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-04.txt>\n\n      In elliptic curve cryptography, 2y^2=x^3+x/GF(8^91+5) hedges a\n      remote risk of potential weakness in other curves, if used in\n      multi-curve Diffie--Hellman, for example.  This curve features:\n      isomorphism to Miller curves from 1985; low Kolmogorov complexity\n      (little room for secretly embedded trapdoors of Gordon, Young--Yung,\n      or Teske); likeness to a Bitcoin curve; 34-byte keys; prime field;\n      5*64-bit field arithmetic; easy reduction, inversion, Legendre\n      symbol, and square root; Montgomery ladder or Edwards unified curve\n      arithmetic (Hisil--Carter--Dawson--Wong); multiplication by i\n      (Gallant--Lambert--Vanstone); and string-as-point encoding.\n\n  "Subscription to Multiple Stream Originators", Tianran Zhou, Guangying\n  Zheng, Eric Voit, Alexander Clemm, 2019-11-04,\n  <draft-zhou-netconf-multi-stream-originators-10.txt>\n\n      This document describes the distributed data export mechanism that\n      allows multiple data streams to be managed by using a single\n      subscription.  Specifically, device can decide to decompse one\n      subscription into multiple subscriptions to the line-cards.  So that\n      each line-card can directly push data to the collector without\n      passing through a broker for internal consolidation.  And the device\n      can indicate the subscription decomposition result to the receiver to\n      check the data integrity.\n\n  "A YANG Data Model for Ethernet TE Topology", Haomian Zheng, Aihua Guo,\n  Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2019-11-18,\n  <draft-zheng-ccamp-client-topo-yang-08.txt>\n\n      A transport network is a server-layer network to provide connectivity\n      services to its client.  In this draft the topology of Ethernet with\n      TE is described with YANG data model.\n\n  "A YANG Data Model for Client-layer Tunnel", Haomian Zheng, Aihua Guo,\n  Italo Busi, Yunbin Xu, Yang Zhao, Xufeng Liu, 2019-08-21,\n  <draft-zheng-ccamp-client-tunnel-yang-05.txt>\n\n      A transport network is a server-layer network to provide connectivity\n      services to its client.  In this draft the tunnel of client is\n      described, with the definition of client tunnel YANG model.\n\n  "BIER in IPv6 (BIERin6)", Zheng Zhang, Tony Przygienda, IJsbrand Wijnands,\n  Hooman Bidgoli, Mike McBride, 2020-01-08, <draft-zhang-bier-bierin6-04.txt>\n\n      BIER is a new architecture for the forwarding of multicast data\n      packets.  This document defines native IPv6 encapsulation for BIER\n      hop-by-hop forwarding or BIERin6 for short.\n\n  "Generic Application Programming Interface (API) for Sliding Window FEC\n  Codes", Vincent Roca, Jonathan Detchart, Cedric Adjih, Morten Pedersen,\n  2019-11-17, <draft-roca-nwcrg-generic-fec-api-07.txt>\n\n      This document introduces a generic Application Programming Interface\n      (API) for sliding window FEC codes.  This API is meant to be\n      compatible with any sliding window FEC code.  It defines the core\n      procedures and functions meant to control the codec (i.e.,\n      implementation of the FEC code).  However, it leaves out all upper\n      layer aspects that are the responsibility of the application or\n      protocol making use of the codec.  As a consequence, this is not an\n      API for a FEC Scheme since certain mechanisms that must be defined by\n      any FEC Scheme (e.g., signalling and FEC Payload IDs) are the\n      responsibility of the caller instead of being addressed by the codec.\n      A first goal of this document is to pave the way for a future open-\n      source implementation of such codes, another goal is to simplify the\n      development of content delivery protocols that rely on sliding window\n      FEC codes for robust transmissions.\n\n  "PCEP Extension for Stateful Inter-Domain Tunnels", Olivier Dugeon, Julien\n  Meuric, Young Lee, Daniele Ceccarelli, 2019-11-04,\n  <draft-dugeon-pce-stateful-interdomain-03.txt>\n\n      This document proposes to combine a Backward Recursive or\n      Hierarchical method in Stateful PCE with PCInitiate message to setup\n      independent paths per domain, and combine these different paths\n      together in order to operate them as end-to-end inter-domain paths\n      without the need of signaling session between inter-domain border\n      routers.  A new Stitching Label is defined, new Path Setup Types, a\n      new Association Type and a new PCEP Capability are considered for\n      that purpose.\n\n  "MAC move over Geneve encapsulation", Sami Boutros, Jerome Catrouillet,\n  Mohana Singamsetty, Parag Jain, 2019-09-19,\n  <draft-boutros-nvo3-mac-move-over-geneve-02.txt>\n\n      This document specifies a mechanism to signal Media Access Control\n      (MAC) addresses move over a Network Virtualization Overlays over\n      Layer 3 (NVO3) virtual tunnel.  Such notification is useful in\n      redundancy scenarios when a Layer 2 service that was active on a\n      Network Virtualization Edge (NVE) fails over to a standby NVE. This\n      notification can be used only when data plane mac learning is enabled\n      over the NVO3 tunnels.\n\n  "Geneve applicability for service function chaining", Sami Boutros, Dharma\n  Rajan, Philip Kippen, Pierluigi Rolando, Jim Guichard, Sam Aldrin,\n  2019-09-16, <draft-boutros-nvo3-geneve-applicability-for-sfc-04.txt>\n\n      This document describes the applicability of using Generic Network\n      Virtualization Encapsulation (Geneve), to carry the service function\n      path (SFP) information, and the network service header (NSH)\n      encapsulation. The SFP information will be carried in Geneve option\n      TLV(s).\n\n  "Echo Request/Reply for In-situ OAM Capabilities", Min Xiao, Gregory\n  Mirsky, Lei Bo, 2019-10-27, <draft-xiao-ippm-ioam-conf-state-05.txt>\n\n      This document describes an extension to the echo request/reply\n      mechanisms used in IPv6, SR-MPLS and SFC environments, which can be\n      used within an IOAM domain, allowing the IOAM encapsulating node to\n      acquire IOAM capabilities of each IOAM transit node and/or IOAM\n      decapsulating node.\n\n  "DHCPv6_PD, PDP and NDP Implementation in IoT Router (DANIR)", Dmytro\n  Shytyi, Alexandre Petrescu, 2019-09-18,\n  <draft-shytyi-v6ops-danir-04.txt,.pdf>\n\n      This document provides a description of the implementation of Dynamic\n      Host Configuration Protocol version 6 Prefix Delegation, Neighbour\n      Discovery Protocol and of the use of the Packet Data Protocol in an\n      Internet of Things Router.  This Internet of Things Router is\n      connected on a cellular network; it is a DHCPv6-PD Client and it\n      requests a /56 pool of prefixes from the server; the DHCPv6-PD server\n      is placed in the PGW and is a part of the cellular infrastructure.\n      After the pool of prefixes is delegated, the Internet of Things\n      Router derives sub-prefixes from the prefix pool; each one of these\n      sub-prefixes is aimed at one ingress interface.\n      \n      After the Internet of Things Router finishes the network prefix\n      assignment procedure, it advertises the network prefixes on the\n      ingress links by using the Neighbour Discovery protocol.  Finally,\n      when Hosts receive the sub-prefixes via Router Adverticement\n      messages, they configure the Global Unique Address with the Stateless\n      Address Auto-configuration protocol.\n\n  "EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols", Patrice\n  Brissette, Ali Sajassi, LucAndre Burdet, Daniel Voyer, 2019-11-04,\n  <draft-brissette-bess-evpn-l2gw-proto-05.txt>\n\n      The existing EVPN multi-homing load-balancing modes defined are\n      Single-Active and All-Active.  Neither of these multi-homing\n      mechanisms are appropriate to support access networks with Layer-2\n      Gateway protocols such as G.8032, MPLS-TP, STP, etc.  These Layer-2\n      Gateway protocols require a new multi-homing mechanism defined in\n      this draft.\n\n  "YANG Model for QoS Operational Parameters", Aseem Choudhary, Ing-Wher\n  Chen, 2019-10-31, <draft-asechoud-rtgwg-qos-oper-model-05.txt>\n\n      This document describes a YANG model for Quality of Service (QoS)\n      operational parameters.\n\n  "EVPN multi-homing port-active load-balancing", Patrice Brissette, Ali\n  Sajassi, Bin Wen, Eddie Leyton, Jorge Rabadan, 2019-10-31,\n  <draft-brissette-bess-evpn-mh-pa-04.txt>\n\n      The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables\n      the establishment of a logical link-aggregation connection with a\n      redundant group of independent nodes. The purpose of multi-chassis\n      LAG is to provide a solution to achieve higher network availability,\n      while providing different modes of sharing/balancing of traffic. EVPN\n      standard defines EVPN based MC-LAG with single-active and all-active\n      multi-homing load-balancing mode. The current draft expands on\n      existing redundancy mechanisms supported by EVPN and introduces\n      support of port-active load-balancing mode. In the current document,\n      port-active load-balancing mode is also referred to as per interface\n      active/standby.\n\n  "YANG Data Model for SRv6 Base and Static", Kamran Raza, Sonal Agarwal,\n  Xufeng Liu, Zhibo Hu, Iftekhar Hussain, Himanshu Shah, Daniel Voyer, Hani\n  Elmalky, Satoru Matsushima, Katsuhiro Horiba, Ahmed Abdelsalam, Jaganbabu\n  Rajamanickam, 2019-10-30, <draft-raza-spring-srv6-yang-05.txt>\n\n      This document describes a YANG data model for Segment Routing IPv6\n      (SRv6) base.  The model serves as a base framework for configuring\n      and managing an SRv6 subsystem and expected to be augmented by other\n      SRv6 technology models accordingly.  Additionally, this document also\n      specifies the model for the SRv6 Static application.\n      \n      The YANG modules in this document conform to the Network Management\n      Datastore Architecture (NMDA).\n\n  "Extension of Probabilistic Routing Protocol using History of Encounters\n  and Transitivity for Information Centric Network", Yun Chung, Min Kang,\n  Dong Seo, Young-Han Kim, 2019-11-04,\n  <draft-chung-dtn-extension-prophet-icn-05.txt,.pdf>\n\n      This document proposes extension of probabilistic routing protocol\n      using history of encounters and transitivity (PRoPHET) for\n      information centric network.\n\n  "AsciiRFC: Authoring Internet-Drafts And RFCs Using AsciiDoc", Ronald Tse,\n  Nick Nicholas, Paolo Brasolin, 2018-04-17, <draft-ribose-asciirfc-08.txt>\n\n      This document describes an AsciiDoc syntax extension called AsciiRFC,\n      designed for authoring IETF Internet-Drafts and RFCs.\n      \n      AsciiDoc is a human readable document markup language which affords\n      more granular control over markup than comparable schemes such as\n      Markdown.\n      \n      The AsciiRFC syntax is designed to allow the author to entirely focus\n      on text, providing the full power of the resulting RFC XML through\n      the AsciiDoc language, while abstracting away the need to manually\n      edit XML, including references.\n      \n      This document itself was written and generated into RFC XML v2\n      (RFC7749) and RFC XML v3 (RFC7991) directly through asciidoctor-rfc,\n      an AsciiRFC generator.\n\n  "Relative JSON Pointers", Geraint Luff, Henry Andrews, 2019-09-18,\n  <draft-handrews-relative-json-pointer-02.txt>\n\n      JSON Pointer is a syntax for specifying locations in a JSON document,\n      starting from the document root.  This document defines an extension\n      to the JSON Pointer syntax, allowing relative locations from within\n      the document.\n\n  "JSON Schema: A Media Type for Describing JSON Documents", Austin Wright,\n  Henry Andrews, Ben Hutton, Greg Dennis, 2019-09-17,\n  <draft-handrews-json-schema-02.txt>\n\n      JSON Schema defines the media type "application/schema+json", a JSON-\n      based format for describing the structure of JSON data.  JSON Schema\n      asserts what a JSON document must look like, ways to extract\n      information from it, and how to interact with it.  The "application/\n      schema-instance+json" media type provides additional feature-rich\n      integration with "application/schema+json" beyond what can be offered\n      for "application/json" documents.\n\n  "JSON Schema Validation: A Vocabulary for Structural Validation of JSON",\n  Austin Wright, Henry Andrews, Ben Hutton, 2019-09-17,\n  <draft-handrews-json-schema-validation-02.txt>\n\n      JSON Schema (application/schema+json) has several purposes, one of\n      which is JSON instance validation.  This document specifies a\n      vocabulary for JSON Schema to describe the meaning of JSON documents,\n      provide hints for user interfaces working with JSON data, and to make\n      assertions about what a valid document must look like.\n\n  "JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON", Henry\n  Andrews, Austin Wright, 2019-09-17,\n  <draft-handrews-json-schema-hyperschema-02.txt>\n\n      JSON Schema is a JSON-based format for describing JSON data using\n      various vocabularies.  This document specifies a vocabulary for\n      annotating JSON documents with hyperlinks.  These hyperlinks include\n      attributes describing how to manipulate and interact with remote\n      resources through hypermedia environments such as HTTP, as well as\n      determining whether the link is usable based on the instance value.\n      The hyperlink serialization format described in this document is also\n      usable independent of JSON Schema.\n\n  "A Unified Stateful/Stateless Configuration Service for IPv6", Fred\n  Templin, 2020-01-01, <draft-templin-6man-dhcpv6-ndopt-09.txt>\n\n      IPv6 Neighbor Discovery (IPv6ND) specifies a control message set for\n      nodes to discover neighbors, routers, prefixes and other services on\n      the link.  It also supports a manner of StateLess Address\n      AutoConfiguration (SLAAC), while the Dynamic Host Configuration\n      Protocol for IPv6 (DHCPv6) specifies a separate stateful service.\n      This document presents IPv6ND extensions for providing a unified\n      stateful/stateless configuration service.\n\n  "Efficient Layer 2 Multicast with Point-to-Point Pseudowires", Weiqiang\n  Cheng, Jie Dong, 2019-11-18, <draft-cheng-pals-p2p-pw-multicast-01.txt>\n\n      Multicast services such as Evolved Multimedia Broadcast/Multicast\n      Service (eMBMS) become more and more popular in mobile networks.  In\n      mobile transport network, it is important for the operators to\n      provide efficient transport of multicast services with existing\n      network devices.  This document describes a mechanism of using point-\n      to-point Pseudowires (PW) [RFC3985] to achieve efficient layer 2\n      multicast transportation in mobile transport networks.The document\n      gives a multicast method by utilizing a Point-to-Point (P2P) path\n      between nodes in a packet transport network , according to the\n      destination IP address.  With it, the PTN nodes can replicate and\n      forward the service message, which are received from the multicast\n      server, to the plurality of multicast clients corresponding to the\n      destination IP address.\n\n  "Ground-Based LISP for the Aeronautical Telecommunications Network",\n  Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras,\n  Victor Moreno, Fabio Maino, Balaji Venkatachalapathy, 2020-01-08,\n  <draft-haindl-lisp-gb-atn-04.txt>\n\n      This document describes the use of the LISP architecture and\n      protocols to address the requirements of the worldwide Aeronautical\n      Telecommunications Network with Internet Protocol Services, as\n      articulated by the International Civil Aviation Organization.\n      \n      The ground-based LISP overlay provides mobility and multi-homing\n      services to the IPv6 networks hosted on commercial aircrafts, to\n      support Air Traffic Management communications with Air Traffic\n      Controllers and Air Operation Controllers.  The proposed architecture\n      doesn\'t require support for LISP protocol in the airborne routers,\n      and can be easily deployed over existing ground infrastructures.\n\n  "A Persistent Web IDentifier (PWID) URN Namespace", Eld Zierau, 2019-09-06,\n  <draft-pwid-urn-specification-09.txt>\n\n      This document specifies a Uniform Resource Name (URN) for Persistent\n      Web IDentifiers for web material in web archives using the \'pwid\'\n      namespace identifier.\n      \n      The main purpose of the standard is to support specification of\n      references that are not covered by other reference techniques: to\n      support references to material in web archives with restricted\n      access.  Furthermore, it supports persistent technology agnostic\n      references to web archives in general, in a form that can work as an\n      algorithmic basis for finding web archive resources in general.  An\n      additional important benefit is that the standard can be used for\n      specifying web collections, which can then form a persistent\n      computational basis for the extract of the archived collection parts.\n      \n      The PWID URN is designed to meet requirements for proper referencing\n      needed by researchers.  Therefore, it is designed as general, global,\n      sustainable, humanly readable, technology agnostic, persistent and\n      precise web references for web materials in web archives.\n\n  "HTTP Live Streaming 2nd Edition", Roger Pantos, 2019-09-23,\n  <draft-pantos-hls-rfc8216bis-05.txt>\n\n      This document obsoletes RFC 8216.  It describes a protocol for\n      transferring unbounded streams of multimedia data.  It specifies the\n      data format of the files and the actions to be taken by the server\n      (sender) and the clients (receivers) of the streams.  It describes\n      version 8 of this protocol.\n\n  "Multiple Access Management Services", Satish Kanugovi, Florin Baboescu,\n  Jing Zhu, Julius Mueller, SungHoon Seo, 2019-05-31,\n  <draft-kanugovi-intarea-mams-framework-04.txt,.pdf>\n\n      In multiconnectivity scenarios, the end-user devices can\n      simultaneously connect to multiple networks based on different access\n      technologies and network architectures like WiFi, LTE, DSL.  Both the\n      quality of experience of the users and the overall network\n      utilization and efficiency may be improved through the smart\n      selection and combination of access and core network paths that can\n      dynamically adapt to changing network conditions.  This document\n      presents a unified problem statement and introduces a solution for\n      managing multiconnectivity.  The solution has been developed by the\n      authors based on their experiences in multiple standards bodies\n      including the IETF and 3GPP, but is not an Internet Standard and does\n      not represent the consensus opinion of the IETF.  This document\n      describes the requirements, solution principles, and an architectural\n      framework that aims to provide best performance while being easy to\n      implement in a wide variety of multiconnectivity deployments.  It\n      specifies the protocol multi-access management to: 1) flexibly select\n      the best combination of access and core network paths for uplink and\n      downlink; as well as 2) determine the user plane treatment and\n      traffic distribution over the selected links ensuring network\n      efficiency and application performance.\n\n  "Registry Maintenance Notifications for the Extensible Provisioning\n  Protocol (EPP)", Tobias Sattler, Roger Carney, Jody Kolker, 2019-09-26,\n  <draft-sattler-epp-registry-maintenance-10.txt>\n\n      This document describes an Extensible Provision Protocol (EPP)\n      mapping for domain name registry\'s maintenance notifications.\n\n  "A Decent LISP Mapping System (LISP-Decent)", Dino Farinacci, Colin\n  Cantrell, 2019-09-03, <draft-farinacci-lisp-decent-04.txt>\n\n      This draft describes how the LISP mapping system designed to be\n      distributed for scale can also be decentralized for management and\n      trust.\n\n  "Health Check Response Format for HTTP APIs", Irakli Nadareishvili,\n  2019-12-31, <draft-inadarei-api-health-check-04.txt>\n\n      This document proposes a service health check response format for\n      HTTP APIs.\n\n  "BIER Prefix Redistribute", Zheng Zhang, Wu Bo, Zhaohui Zhang, IJsbrand\n  Wijnands, 2019-09-23, <draft-zwzw-bier-prefix-redistribute-03.txt>\n\n      This document defines a BIER proxy function to interconnect different\n      underlay routing protocol areas in a network.  And a new BIER proxy\n      range sub-TLV is also defined to convey BIER BFR-id information\n      across the routing areas.\n\n  "Deterministic Networking Application in Ring Topologies", Yuanlong Jiang,\n  Norman Finn, Jeong-dong Ryoo, Balazs Varga, Liang Geng, 2020-01-07,\n  <draft-jiang-detnet-ring-05.txt>\n\n      Deterministic Networking (DetNet) provides a capability to carry data\n      flows for real-time applications with extremely low data loss rates\n      and bounded latency.  This document describes how DetNet can be used\n      in ring topologies to support Point-to-Point (P2P) and Point-to-\n      Multipoint (P2MP) real-time services.\n\n  "Simple Group Keying Protocol TRILL Use Protfiles", Donald Eastlake,\n  Dacheng Zhang, 2020-01-19, <draft-ietf-trill-link-gk-profiles-04.txt>\n\n      This document specifies use profiles for the application of the\n      simple group keying protocol (SGKP) to multi-destination TRILL\n      Extended RBridge Channel message security (RFC 7978) and TRILL over\n      IP packet security (draft-ietf-trill-over-ip).\n\n  "Extended Socket APIs to control subflow priority in Multipath TCP", Samar\n  Shailendra, Hemant Rath, Arpan Pal, Abhijit Mondal, 2019-08-04,\n  <draft-samar-mptcp-socketapi-03.txt>\n\n      This document provides the extended Socket APIs to control subflow\n      priority for Multipath TCP. It also describes an additional data\n      structure for MPTCP to make the subflow priority persistent across\n      subflow disconnection.\n\n  "Application-Layer TLS", Owen Friel, Richard Barnes, Max Pritikin, Hannes\n  Tschofenig, Mark Baugher, 2019-11-04, <draft-friel-tls-atls-04.txt>\n\n      This document specifies how TLS and DTLS can be used at the\n      application layer for the purpose of establishing secure end-to-end\n      encrypted communication security.\n      \n      Encodings for carrying TLS and DTLS payloads are specified for HTTP\n      and CoAP to improve interoperability.  While the use of TLS and DTLS\n      is straight forward we present multiple deployment scenarios to\n      illustrate the need for end-to-end application layer encryption and\n      the benefits of reusing a widely deployed and readily available\n      protocol.  Application software architectures for building, and\n      network architectures for deploying application layer TLS are\n      outlined.\n\n  "Random Linear Network Coding (RLNC)-Based Symbol Representation", Janus\n  Heide, Shirley Shi, Kerim Fouli, Muriel Medard, Vince Chook, 2019-09-09,\n  <draft-heide-nwcrg-rlnc-03.txt>\n\n      This document describes a symbol representation for Random Linear\n      Network Coding (RLNC) schemes used for reliable data transfer.\n      Specifically, the following features are discussed and incorporated:\n      both block RLNC and a sliding window RLNC, varying data frame sizes,\n      and one or multiple symbols associated with a single symbol\n      representation header.\n\n  "LURK Extension version 1 for (D)TLS 1.2 Authentication", Daniel Migault,\n  Ioana Boureanu, 2020-01-02, <draft-mglt-lurk-tls12-02.txt>\n\n      This document describes the LURK Extension \'tls12\' which enables\n      interactions between a LURK Client and a LURK Server in a context of\n      authentication with (D)TLS 1.2.\n\n  "IPv4+ The Extended Protocol Based On IPv4", ZiQiang Tang, 2020-01-18,\n  <draft-tang-ipv4plus-04.txt>\n\n      This document specifies version 4+ of the Internet Protocol\n      (IPv4+). IPv4 is very successful,simple and elegant.\n      continuation and expansion of the IPv4 is necessary. Existing\n      systems, devices only need to upgrade the software to support\n      IPv4+, without the need to update new hardwares,saving\n      investment costs. Ipv4+ is also an interstellar Protocol,\n      so the Internet will evolve into a star Internet.\n\n  "QUIC-LB: Generating Routable QUIC Connection IDs", Martin Duke, Nick\n  Banks, 2019-11-04, <draft-duke-quic-load-balancers-06.txt>\n\n      QUIC connection IDs allow continuation of connections across address/\n      port 4-tuple changes, and can store routing information for stateless\n      or low-state load balancers.  They also can prevent linkability of\n      connections across deliberate address migration through the use of\n      protected communications between client and server.  This creates\n      issues for load-balancing intermediaries.  This specification\n      standardizes methods for encoding routing information and proposes an\n      optional protocol called QUIC-LB to exchange the parameters of that\n      encoding.  This framework also enables offload of other QUIC\n      functions to trusted intermediaries, given the explicit cooperation\n      of the QUIC server.\n\n  "IANA Registration of Trustword Lists: Guide, Template and IANA\n  Considerations", Bernie Hoeneisen, Hernani Marques, 2020-01-09,\n  <draft-birk-pep-trustwords-05.txt>\n\n      This document specifies the IANA Registration Guidelines for\n      Trustwords, describes corresponding registration procedures, and\n      provides a guideline for creating Trustword list specifications.\n      \n      Trustwords are common words in a natural language (e.g., English),\n      which hexadecimal strings are mapped to.  Such a mapping makes\n      verification processes like fingerprint comparisons more practical,\n      and less prone to misunderstandings.\n\n  "Information-centric Routing for Opportunistic Wireless Networks", Paulo\n  Mendes, Rute Sofia, Vassilis Tsaoussidis, Carlos Borrego, 2019-09-12,\n  <draft-mendes-icnrg-dabber-03.txt>\n\n      This draft describes the Data reAchaBility BasEd Routing (DABBER)\n      protocol, which has been developed to extend the reached of Named\n      Data Networking based routing approaches to opportunistic wireless\n      networks. By "opportunistic wireless networks" it is meant multi-hop\n      wireless networks where finding an end-to-end path between any pair\n      of nodes at any moment in time may be a challenge. The goal is to\n      assist in better defining opportunities for the transmission of\n      Interest packets towards the most suitable data source, based on\n      metrics that provide information about: i) the availability of\n      different data sources; ii) the availability and centrality of\n      neighbor nodes; iii) the time lapse between forwarding Interest\n      packets and receiving the corresponding data packets. The document\n      presents an architectural overview of DABBER followed by\n      specification options related to the dissemination of name-prefix\n      information to support the computation of next hops, and the ranking\n      of forwarding options based on the best set of neighbors to ensure a\n      short time-to-completion.\n\n  "Unified Identifier in IPv6 Segment Routing Networks", Weiqiang Cheng,\n  Gregory Mirsky, Shaofu Peng, Liu Aihua, XiaoLan Wan, Cheng Wei, Shay,\n  2019-11-04, <draft-mirsky-6man-unified-id-sr-04.txt>\n\n      Segment Routing architecture leverages the paradigm of source\n      routing.  It can be realized in a network data plane by prepending\n      the packet with a list of instructions, a.k.a. segments.  A segment\n      can be encoded as a Multi-Protocol Label Switching (MPLS) label, IPv4\n      address, or IPv6 address.  Segment Routing can be applied in MPLS\n      data plane by encoding segments in MPLS label stack.  It also can be\n      applied to IPv6 data plane by encoding a list of segment identifiers\n      in IPv6 Segment Routing Extension Header (SRH).  This document\n      extends the use of the SRH to unified identifiers encoded as MPLS\n      label or IPv4 address, to compress the SRH, and support support more\n      detailed network programming and interworking between SR-MPLS and\n      SRv6 domains.\n\n  "Hybrid Two-Step Performance Measurement Method", Gregory Mirsky, Wang\n  Lingqiang, Guo Zhui, 2019-10-08, <draft-mirsky-ippm-hybrid-two-step-04.txt>\n\n      Development of, and advancements in, automation of network operations\n      brought new requirements for measurement methodology.  Among them is\n      the ability to collect instant network state as the packet being\n      processed by the networking elements along its path through the\n      domain.  This document introduces a new hybrid measurement method,\n      referred to as hybrid two-step, as it separates the act of measuring\n      and/or calculating the performance metric from the act of collecting\n      and transporting network state.\n\n  "Synchronizing Internet Clock frequency protocol (sic)", Jose\n  Alvarez-Hamelin, David Samaniego, Alfredo Ortega, Ruediger Geib,\n  2019-10-28, <draft-alavarez-hamelin-tictoc-sic-04.txt>\n\n      Synchronizing Internet Clock Frequency specifies a new secure method\n      to synchronize difference clocks on the Internet, assuring smoothness\n      (i.e., frequency stability) and robustness to man-in-the-middle\n      attacks.  In 90% of all cases, Synchronized Internet Clock Frequency\n      is highly accurate, with a Maximum Time Interval Error less than 25\n      microseconds by a minute.  Synchronized Internet Clock Frequency is\n      based on a regular packet exchange and works with commodity terminal\n      hardware.\n\n  "Extension for Stateful PCE to allow Optional Processing of PCEP Objects",\n  Cheng Li, Haomian Zheng, Stephane Litkowski, 2020-01-10,\n  <draft-dhody-pce-stateful-pce-optional-05.txt>\n\n      This document introduces a mechanism to mark some of the Path\n      Computation Element (PCE) Communication Protocol (PCEP) objects as\n      optional during PCEP messages exchange for the Stateful PCE model to\n      allow relaxing some constraints.  The introduction of relaxation in\n      this document updates RFC8231.\n\n  "Optimized Service Function Chaining", Ramin Khalili, Zoran Despotovic,\n  Artur Hecker, Debashish Purkayastha, Akbar Rahman, Dirk Trossen,\n  2019-08-30, <draft-khalili-sfc-optimized-chaining-03.txt>\n\n      This draft investigates possibilities to use so-called \'transport-\n      derived service function forwarders\' (tSFFs) that uses existing\n      transport information for explicit service path information. The\n      draft discusses two such possibilities, focusing on realization of\n      efficient chaining over single transport networks. In the first one,\n      the transport network is SDN-based. The second one introduces and\n      explains a specific service request routing (SRR) function to support\n      URL-level routing of service requests.\n\n  "Multilinear Galois Mode (MGM)", Stanislav Smyshlyaev, Vladislav Nozdrunov,\n  Vasily Shishkin, Smyshliaeva Ekaterina, 2019-12-12,\n  <draft-smyshlyaev-mgm-16.txt>\n\n      Multilinear Galois Mode (MGM) is an authenticated encryption with\n      associated data (AEAD) block cipher mode based on EtM principle.  MGM\n      is defined for use with 64-bit and 128-bit block ciphers.\n      \n      MGM has been standardized in Russia.  It is used as an AEAD mode for\n      the GOST block cipher algorithms in many protocols, e.g.  TLS 1.3 and\n      IPsec.  This document provides a reference for MGM to enable review\n      of the mechanisms in use and to make MGM available for use with any\n      block cipher.\n\n  "Using Identity as Raw Public Key in Transport Layer Security (TLS) and\n  Datagram Transport Layer Security (DTLS)", HAIGUANG Wang, Yanjiang Yang,\n  Xin Kang, Zhaohui Cheng, 2019-10-10,\n  <draft-wang-tls-raw-public-key-with-ibc-11.txt,.pdf>\n\n      This document specifies the use of identity as a raw public key in\n      Transport Layer Security (TLS) and Datagram Transport Layer Security\n      (DTLS).  The TLS protocol procedures are kept unchanged, but\n      signature algorithms are extended to support Identity-based signature\n      (IBS).  A typical Identity-based signature algorithm, the ECCSI\n      signature algorithm defined in RFC 6507, is supported in the current\n      version.\n\n  "Blockchain Transaction Protocol for Constraint Nodes", Pascal Urien,\n  2019-09-04, <draft-urien-core-blockchain-transaction-protocol-03.txt>\n\n      The goal of the blockchain transaction protocol for constraint nodes\n      is to enable the generation of blockchain transactions by constraint\n      nodes, according to the following principles:\n      - transactions are triggered by Provisioning-Messages that include\n      the needed blockchain parameters.\n      - binary encoded transactions are returned in Transaction-Messages,\n      which include sensors/actuators data. Constraint nodes, associated\n      with blockchain addresses, compute the transaction signature.\n\n  "Shared Brotli Compressed Data Format", Jyrki Alakuijala, Thai Duong,\n  Evgenii Kliuchnikov, Robert Obryk, Zoltan Szabadka, Lode Vandevenne,\n  2019-08-21, <draft-vandevenne-shared-brotli-format-04.txt>\n\n      This specification defines a data format for shared brotli\n      compression, which adds support for shared dictionaries, large\n      window, patching and a container format to brotli [RFC7932].\n      \n      Shared dictionaries and large window support allow significant\n      compression gains compared to regular brotli, and patching allows\n      smaller patches of binary files.\n\n  "BGP Link-State Extensions for BGP-only Fabric", Ketan Talaulikar, Clarence\n  Filsfils, krishnaswamy ananthamurthy, Shawn Zandi, Gaurav Dawra, Muhammad\n  Durrani, 2019-09-09, <draft-ketant-idr-bgp-ls-bgp-only-fabric-03.txt>\n\n      BGP is used as the only routing protocol in some networks today.  In\n      such networks, it is useful to get a detailed view of the nodes and\n      underlying links in the topology along with their attributes similar\n      to one available when using link state routing protocols.  Such a\n      view of a BGP-only fabric enables use cases like traffic engineering\n      and forwarding of services along paths other than the BGP best path\n      selection.\n      \n      This document defines extensions to the BGP Link-state address-family\n      (BGP-LS) and the procedures for advertisement of the topology in a\n      BGP-only network.  It also describes a specific use-case for traffic\n      engineering based on Segment Routing.\n\n  "Segment Routing for Resource Partitioned Virtual Networks", Jie Dong,\n  Stewart Bryant, Takuya Miyasaka, Yongqing Zhu, Fengwei Qin, Zhenqiang Li,\n  2019-12-16, <draft-dong-spring-sr-for-enhanced-vpn-06.txt>\n\n      This document describes the mechanism to associate Segment Routing\n      Identifiers (SIDs) with network resource attributes.  The resource-\n      aware SIDs retain their original functionality, with the additional\n      semantics of identifying the set of network resources available for\n      the packet processing action.  These SIDs can be used to build SID\n      lists with reserved network resources, which can be used for many\n      network scenarios.  One typical use case is to provide SR virtual\n      networks with required network topology and resource attributes.  The\n      proposed mechanism is applicable to both segment routing with MPLS\n      data plane (SR-MPLS) and segment routing with IPv6 data plane (SRv6).\n\n  "A YANG Data Model for In-Situ OAM", Tianran Zhou, Jim Guichard, Frank\n  Brockners, Srihari Raghavan, 2020-01-01, <draft-zhou-ippm-ioam-yang-05.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in user packets while the\n      packets traverse a path between two points in the network.  This\n      document defines a YANG module for the IOAM function.\n\n  "Geneve encapsulation for In-situ OAM Data", Frank Brockners, Shwetha\n  Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy,\n  Stephen Youell, Tal Mizrahi, Petr Lapukhov, Barak Gafni, Aviv Kfir, Mickey\n  Spiegel, 2019-09-11, <draft-brockners-ippm-ioam-geneve-03.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in the packet while the packet\n      traverses a path between two points in the network.  This document\n      outlines how IOAM data fields are encapsulated in Geneve.\n\n  "VXLAN-GPE Encapsulation for In-situ OAM Data", Frank Brockners, Shwetha\n  Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy,\n  Stephen Youell, Tal Mizrahi, Aviv Kfir, Barak Gafni, Petr Lapukhov, Mickey\n  Spiegel, 2019-11-04, <draft-brockners-ippm-ioam-vxlan-gpe-03.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in the packet while the packet\n      traverses a path between two points in the network.  This document\n      outlines how IOAM data fields are encapsulated in VXLAN-GPE.\n\n  "EVPN All Active Usage Enhancement", Donald Eastlake, Zhenbin Li, Haibo\n  Wang, 2020-01-15, <draft-eastlake-bess-enhance-evpn-all-active-04.txt>\n\n      A principal feature of EVPN is the ability to support multihoming\n      from a customer equipment (CE) to multiple provider edge equipment\n      (PE) active with all-active links. This draft specifies an\n      improvement to load balancing such links.\n\n  "Bidirectional Forwarding Detection (BFD) for Segment Routing Policies for\n  Traffic Engineering", Zafar Ali, Ketan Talaulikar, Clarence Filsfils,\n  Nagendra Kumar, Carlos Pignataro, 2019-10-30,\n  <draft-ali-spring-bfd-sr-policy-04.txt>\n\n      Segment Routing (SR) allows a headend node to steer a packet flow\n      along any path using a segment list which is referred to as a SR\n      Policy.  Intermediate per-flow states are eliminated thanks to source\n      routing.  The header of a packet steered in an SR Policy is augmented\n      with the ordered list of segments associated with that SR Policy.\n      Bidirectional Forwarding Detection (BFD) is used to monitor different\n      kinds of paths between node.  BFD mechanisms can be also used to\n      monitor the availability of the path indicated by a SR Policy and to\n      detect any failures.  Seamless BFD (S-BFD) extensions provide a\n      simplified mechanism which is suitable for monitoring of paths that\n      are setup dynamically and on a large scale.\n      \n      This document describes the use of Seamless BFD (S-BFD) mechanism to\n      monitor the SR Policies that are used for Traffic Engineering (TE) in\n      SR deployments.\n\n  "Multipath Extensions for QUIC (MP-QUIC)", Quentin Coninck, Olivier\n  Bonaventure, 2019-08-29, <draft-deconinck-quic-multipath-03.txt>\n\n      This document specifies extensions to the QUIC protocol to enable,\n      other than connection migration, simultaneous usage of multiple paths\n      for a single connection.  Those extensions remain compliant with the\n      current single-path QUIC design.  They allow devices to benefit from\n      multiple network paths while preserving the privacy features of QUIC.\n\n  "IPv6 Point-to-Point Links", Jordi Palet, 2019-11-04,\n  <draft-palet-v6ops-p2p-links-04.txt>\n\n      This document describes different alternatives for configuring IPv6\n      point-to-point links, considering the prefix size, numbering choices\n      and prefix pool to be used.\n\n  "TLS/DTLS 1.3 Profiles for the Internet of Things", Hannes Tschofenig,\n  Thomas Fossati, 2019-11-04, <draft-tschofenig-uta-tls13-profile-02.txt>\n\n      This document is a companion to RFC 7925 and defines TLS/DTLS 1.3\n      profiles for Internet of Things devices.\n\n  "Service Function discovery in fog environments", Carlos Bernardos, Alain\n  Mourad, 2019-09-07, <draft-bernardos-sfc-discovery-03.txt>\n\n      Service function chaining (SFC) allows the instantiation of an\n      ordered set of service functions and subsequent "steering" of traffic\n      through them.  Service functions provide an specific treatment of\n      received packets, therefore they need to be known so they can be used\n      in a given service composition via SFC.  This document discusses the\n      need for service function discovery mechanisms and propose some\n      solutions for sfc-aware nodes to discover available service functions\n      in fog environments.\n\n  "EVPN VXLAN Bypass VTEP", Donald Eastlake, Zhenbin Li, Shunwan Zhuang,\n  2019-11-04, <draft-eastlake-bess-evpn-vxlan-bypass-vtep-04.txt>\n\n      A principal feature of EVPN is the ability to support multihoming\n      from a customer equipment (CE) to multiple provider edge equipment\n      (PE) with all-active links. This draft specifies a mechanism to\n      simplify PEs used with VXLAN tunnels and enhance VXLAN Active-Active\n      reliability.\n\n  "BGP EVPN Flood Traffic Optimization at EVPN Gateways", satyamoh@cisco.com,\n  Mrinmoy Ghosh, Ali Sajassi, Sandy Breeze, Jim Uttaro, 2019-11-02,\n  <draft-mohanty-bess-evpn-bum-opt-01.txt>\n\n      In EVPN, the Broadcast, Unknown Unicast and Multicast (BUM) traffic\n      is sent to all the routers participating in the EVPN instance.  In a\n      multi-homing scenario, when more than one PEs share the same Ethernet\n      Segment, i.e. there are more than one PEs in a redundancy group, only\n      the PE that is the Designated-Forwarder (DF) for the ES will forward\n      that packet on the access interface whereas all non-DF PEs will drop\n      the packet.  In deployments such as EVPN Gateways (EVPN GW) or Data\n      Center Interconnect (DCI) routers, this can be quite wasteful.  This\n      is especially true if there are significantly more EVPN GW or DCI PEs\n      all participating in the same sets of ES and vES.  This draft\n      explores the problem and provides solutions for the same.\n\n  "Origin Validation Policy Considerations for Dropping Invalid Routes",\n  Kotikalapudi Sriram, Oliver Borchert, Doug Montgomery, 2019-10-22,\n  <draft-sriram-sidrops-drop-invalid-policy-04.txt>\n\n      Deployment of Resource Public Key Infrastructure (RPKI) and Route\n      Origin Authorizations (ROAs) is expected to occur gradually over\n      several or many years.  During the incremental deployment period,\n      network operators would wish to have a meaningful policy for dropping\n      Invalid routes.  Their goal is to balance (A) dropping Invalid routes\n      so hijacked routes can be eliminated, versus (B) tolerance for\n      missing or erroneously created ROAs for customer prefixes.  This\n      document considers a Drop Invalid if Still Routable (DISR) policy\n      that is based on these considerations.  The key principle of DISR\n      policy is that an Invalid route can be dropped if a Valid or NotFound\n      route exists for a subsuming less specific prefix.\n\n  "Traffic Accounting in Segment Routing Networks", Zafar Ali, Clarence\n  Filsfils, Ketan Talaulikar, Siva Sivabalan, Martin Horneffer, Robert\n  Raszuk, Stephane Litkowski, Daniel Voyer, 2019-08-08,\n  <draft-ali-spring-sr-traffic-accounting-03.txt>\n\n      Capacity planning is the continuous art of forecasting traffic\n      load and failures to evolve the network topology, its capacity,\n      and its routing to meet a defined Service-Level Agreement (SLA).\n      This document takes a holistic view of network capacity planning\n      and identifies the role of traffic accounting in network\n      operation and capacity planning, without creating any additional\n      states in the SR fabric.\n\n  "OAuth 2.0 Assisted Token", Jacob Ideskog, Travis Spencer, 2019-11-24,\n  <draft-ideskog-assisted-token-01.txt>\n\n      This document extends the OAuth 2.0 framework to include an\n      additional authorization flow for single page applications called the\n      assisted token flow.  It enables OAuth clients written in scripting\n      languages, like JavaScript, to request user authorization using a\n      simplified method compared to other flows.  Communication does not\n      rely on redirection of the user agent, but instead leverages HTML\'s\n      iframe element, child windows, and the postMessage interface.  This\n      communication is done using an additional endpoint, the assisted\n      token endpoint.\n\n  "Optional Security Is Not An Option", Brian Trammell, 2019-10-17,\n  <draft-trammell-optional-security-not-02.txt>\n\n      This document explores the common properties of optional security\n      protocols and extensions, and notes that due to the base-rate fallacy\n      and general issues with coordinated deployment of protocols under\n      uncertain incentives, optional security protocols have proven\n      difficult to deploy in practice.  This document defines the problem,\n      examines efforts to add optional security for routing, naming, and\n      end-to-end transport, and extracts guidelines for future efforts to\n      deploy optional security protocols based on successes and failures to\n      date.\n\n  "The Delegation_Only DNSKEY flag", Paul Wouters, Wes Hardaker, 2019-11-04,\n  <draft-pwouters-powerbind-03.txt>\n\n      This document introduces a new DNSKEY flag called DELEGATION_ONLY\n      that indicates that the particular zone will never sign zone data\n      across a label.  That is, every label (dot) underneath is considered\n      a zone cut and must have its own (signed) delegation.  Additionally,\n      it indicates the zone is expecting its parent to never bypass or\n      override the zone.  DNSSEC Validating Resolvers can use this bit to\n      mark any data that violates the DELEGATION_ONLY policy as BOGUS.\n\n  "ICANN Registrar Interfaces", Gustavo Lozano, Eduardo Alvarez, 2019-09-23,\n  <draft-icann-registrar-interfaces-03.txt>\n\n      This document describes the interfaces provided by ICANN to\n      Registrars and Data Escrow Agents in order to fulfill the data escrow\n      requirements of the Registrar Accreditation Agreement and the\n      Registrar Data Escrow Specifications.\n\n  "DHCP Options for 0-RTT TCP Converters", Mohamed Boucadair, Christian\n  Jacquenet, Tirumaleswar Reddy.K, 2019-10-07,\n  <draft-boucadair-tcpm-dhc-converter-03.txt>\n\n      Because of the lack of important TCP extensions, e.g., Multipath TCP\n      support at the server side, some service providers now consider a\n      network-assisted model that relies upon the activation of a dedicated\n      function called Transport Converters.  For example, network-assisted\n      Multipath TCP deployment models are designed to facilitate the\n      adoption of Multipath TCP for the establishment of multi-path\n      communications without making any assumption about the support of\n      Multipath TCP by the remote servers.  Transport Converters located in\n      the network are responsible for establishing multi-path\n      communications on behalf of endpoints, thereby taking advantage of\n      Multipath TCP capabilities to achieve different goals that include\n      (but are not limited to) optimization of resource usage (e.g.,\n      bandwidth aggregation), of resiliency (e.g., primary/backup\n      communication paths), and traffic offload management.\n      \n      This document focuses on the explicit deployment scheme where the\n      identity of the Transport Converters is explicitly configured on\n      connected hosts.  This document specifies DHCP (IPv4 and IPv6)\n      options to configure hosts with Converters parameters.\n\n  "Optimization of RWA Problem through OSNR", Shan Yin, Shanguo Huang, Shuang\n  Zhou, Xiangkai Meng, Rong Ma, 2019-11-21, <draft-yin-rwa-osnr-04.txt>\n\n      This documentary provides a kind of routing optimization method. In\n      the basic of RWA solution method, both the output power of the route\n      and the OSNR value of the optical signal noise ratio are considered.\n      The selected optimal route has a lower bit error rate and the whole\n      communication network performance is improved.\n\n  "OSPF Flooding Reduction in Massively Scale Data Centers (MSDCs)", Xiaohu\n  Xu, Luyuan Fang, Jeff Tantsura, Shaowen Ma, 2019-10-14,\n  <draft-xu-lsr-ospf-flooding-reduction-in-msdc-03.txt>\n\n      OSPF is one of the used underlay routing protocol for MSDC (Massively\n      Scalable Data Center) networks.  For a given OSPF router within the\n      CLOS topology, it would receive multiple copies of exactly the same\n      LSA from multiple OSPF neighbors.  In addition, two OSPF neighbors\n      may send each other the same LSA simultaneously.  The unnecessary\n      link-state information flooding wastes the precious process resource\n      of OSPF routers greatly due to the presence of too many OSPF\n      neighbors for each OSPF router within the CLOS topology.  This\n      document proposes extensions to OSPF so as to reduce the OSPF\n      flooding within such MSDC networks.  The reduction of the OSPF\n      flooding is much beneficial to improve the scalability of MSDC\n      networks.  These modifications are applicable to both OSPFv2 and\n      OSPFv3.\n\n  "DLEP IEEE 802.1Q Aware Credit Window Extension", David Wiggins, Lou\n  Berger, 2019-11-19, <draft-berger-manet-dlep-ether-credit-extension-03.txt>\n\n      This document defines an extension to the Dynamic Link Exchange\n      Protocol (DLEP) that enables a Ethernet IEEE 802.1Q aware credit-\n      window scheme for destination-specific and shared flow control.\n\n  "JSON Canonicalization Scheme (JCS)", Anders Rundgren, Bret Jordan, Samuel\n  Erdtman, 2020-01-20, <draft-rundgren-json-canonicalization-scheme-17.txt>\n\n      Cryptographic operations like hashing and signing need the data to be\n      expressed in an invariant format so that the operations are reliably\n      repeatable.  One way to address this is to create a canonical\n      representation of the data.  Canonicalization also permits data to be\n      exchanged in its original form on the "wire" while cryptographic\n      operations performed on the canonicalized counterpart of the data in\n      the producer and consumer end points, generate consistent results.\n      \n      This document describes the JSON Canonicalization Scheme (JCS).  The\n      JCS specification defines how to create a canonical representation of\n      JSON data by building on the strict serialization methods for JSON\n      primitives defined by ECMAScript, constraining JSON data to the\n      I-JSON subset, and by using deterministic property sorting.\n\n  "SR Policy Implementation and Deployment Considerations", Clarence\n  Filsfils, Ketan Talaulikar, Przemyslaw Krol, Martin Horneffer, Paul Mattes,\n  2019-10-09, <draft-filsfils-spring-sr-policy-considerations-04.txt>\n\n      Segment Routing (SR) allows a headend node to steer a packet flow\n      along any path.  Intermediate per-flow states are eliminated thanks\n      to source routing.  SR Policy framework enables the instantiation and\n      the management of necessary state on the headend node for flows along\n      a source routed paths using an ordered list of segments associated\n      with their specific SR Policies.  This document describes some of the\n      implementation and deployment aspects that are useful for\n      operationalizing the SR Policy architecture.\n\n  "RSCA method with Dividing Frequency Slots Area in Space Division\n  Multiplexing Elastic Optical Networks", Shanguo Huang, Shan Yin, Shuang\n  Zhou, 2019-11-21, <draft-huang-rsca-sdm-eon-03.txt>\n\n      This documentary provides a routing, spectrum and core assignment\n      method with the dividing frequency slots area for space division\n      multiplexing elastic optical networks. This effective RSCA method to\n      solve this problem better. The proposed method utilizes the Frequency\n      Slots Area (FSA) concept and first-last fit policy of frequency slots\n      assignment to have less spectrum fragments, lower crosstalk, smaller\n      traffic blocking probability and higher spectrum resource utilization.\n\n  "IMAP Service Extension for Client Identity", Deion Yu, 2019-11-19,\n  <draft-yu-imap-client-id-03.txt>\n\n      This document defines an Internet Message Access Protocol (IMAP)\n      service extension called "CLIENTID" which provides a method for\n      clients to indicate an identity to the server.\n      \n      This identity is an additional token that may be used for security\n      and/or informational purposes, and with it a server may optionally\n      apply heuristics using this token.\n\n  "Large-Scale Deterministic IP Network", Li Qiang, Xuesong Geng, Bingyang\n  Liu, Toerless Eckert, Liang Geng, Guangpeng Li, 2019-09-02,\n  <draft-qiang-detnet-large-scale-detnet-05.txt>\n\n      This document presents the overall framework and key method for\n      Large-scale Deterministic Network (LDN).  LDN can provide bounded\n      latency and delay variation (jitter) without requiring precise time\n      synchronization among nodes, or per-flow state in transit nodes.\n\n  "Segment routing for SDWAN paths over hybrid networks", Linda Dunbar,\n  Mehmet Toy, 2019-11-04, <draft-dunbar-sr-sdwan-over-hybrid-networks-06.txt>\n\n      This document describes a method for end-to-end (E2E) SDWAN paths to\n      traverse specific list of underlay network segments, some of which\n      can be private networks which include SR enabled segments, some of\n      which  can be the public IP networks that do not support SR, to\n      achieve the desired optimal E2E quality.\n      \n      The method described in this draft uses the principle of segment\n      routing to enforce a SDWAN path\'s head-end selected route traversing\n      through a list of specific nodes of multiple network segments\n      without requiring the nodes in each network segment to have the\n      intelligence (or maintaining states) of selecting next hop or next\n      domain.\n\n  "Hybrid Information-Centric Networking", Luca Muscariello, Giovanna\n  Carofiglio, Jordan Auge, Michele Papalini, 2019-10-30,\n  <draft-muscariello-intarea-hicn-03.txt>\n\n      This document describes the hybrid information-centric networking\n      (hICN) architecture for IPv6.  The specifications describe a way to\n      implement information-networking functionalities into IPv6.  The\n      objective is to use IPv6 without creating overlays with a new packet\n      format as an additional encapsulation.  The intent of the present\n      design is to introduce some IPv6 routers in the network with\n      additional packet processing operations to implement ICN functions.\n      Moreover, the current design is tightly integrated into IPv6 to allow\n      easy interconnection to IPv6 networks with the additional design\n      objective to exploit existing IPv6 protocols as much as possible as\n      they are, or extend them where needed.\n\n  "General Security Considerations for Cryptoassets Custodians", Masashi\n  Sato, Masaki Shimaoka, Hirotaka Nakajima, 2019-11-04,\n  <draft-vcgtf-crypto-assets-security-considerations-05.txt>\n\n      This document discusses the technical and operational risks of\n      cryptoassets custodians and its security controls to avoid the\n      unintended transactions for its customers.\n\n  "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version\n  1.2", Stanislav Smyshlyaev, Dmitry Belyavsky, Markku-Juhani Saarinen,\n  2019-11-28, <draft-smyshlyaev-tls12-gost-suites-07.txt>\n\n      This document specifies a set of cipher suites for the Transport\n      Layer Security (TLS) protocol Version 1.2 to support the Russian\n      cryptographic standard algorithms.\n\n  "Limited Domains and Internet Protocols", Brian Carpenter, Bing Liu,\n  2019-11-30, <draft-carpenter-limited-domains-12.txt>\n\n      There is a noticeable trend towards network requirements, behaviours\n      and semantics that are specific to a particular set of requirements\n      applied within a limited region of the Internet.  Policies, default\n      parameters, the options supported, the style of network management\n      and security requirements may vary between such limited regions.\n      This document reviews examples of such limited domains (also known as\n      controlled environments), notes emerging solutions, and includes a\n      related taxonomy.  It then briefly discusses the standardization of\n      protocols for limited domains.  Finally, it shows the needs for a\n      precise definition of "limited domain membership" and for mechanisms\n      to allow nodes to join a domain securely and to find other members,\n      including boundary nodes.\n      \n      This document is the product of the research of the authors.  It has\n      been produced through discussions and consultation within the IETF,\n      but is not the product of IETF conensus.\n\n  "The Per-Path Service Instruction (PPSI) Option", Ron Bonica, Yuji Kamite,\n  Luay Jalil, Chris Lenart, Ning So, Fengman Xu, Greg Presbury, Gang Chen,\n  Yongqing Zhu, Yifeng Zhou, 2019-11-20,\n  <draft-bonica-6man-vpn-dest-opt-08.txt>\n\n      SRm6 encodes Per-Path Service Instructions (PPSI) in a new IPv6\n      option, called the PPSI Option.  This document describes the PPSI\n      Option.\n\n  "A Massive Data Migration Framework", Can Yang, Yu Pan, Cong Chen, Ge Chen,\n  Yukai Wei, 2019-11-26,\n  <draft-yangcan-ietf-data-migration-standards-03.txt,.pdf>\n\n      This document describes a standardized framework for implementing the\n      massive data migration between traditional databases and big-data\n      platforms on the cloud via Internet, especially for an instance of\n      Hadoop data architecture.  The main goal of the framework is to\n      provide more concise and friendly interfaces for users more easily\n      and quickly migrate the massive data from a relational database to a\n      distributed platform for a variety of requirements, in order to make\n      full use of distributed storage resource and distributed computing\n      capability to solve the bottleneck problems of both storage and\n      computing performance in traditional enterprise-level applications.\n      This document covers the fundamental architecture, data elements\n      specification, operations, and interface related to massive data\n      migration.\n\n  "Bundled HTTP Exchanges", Jeffrey Yasskin, 2019-09-26,\n  <draft-yasskin-wpack-bundled-exchanges-02.txt>\n\n      Bundled exchanges provide a way to bundle up groups of HTTP\n      request+response pairs to transmit or store them together.  They can\n      include multiple top-level resources with one identified as the\n      default by a manifest, provide random access to their component\n      exchanges, and efficiently store 8-bit resources.\n\n  "DNS Web Service Discovery", Phillip Hallam-Baker, 2019-10-23,\n  <draft-hallambaker-web-service-discovery-03.txt>\n\n      This document describes a standardized approach to discovering Web\n      Service Endpoints from a DNS name.  Services are advertised using the\n      DNS SRV and TXT records and the HTTP Well Known Service conventions.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-web-service-\n      discovery.html [1] .\n\n  "BGP FlowSpec Payload Matching", Anurag Khare, John Scudder, Luay Jalil,\n  Michael Gallagher, Kirill Kasavchenko, 2019-12-07,\n  <draft-khare-idr-bgp-flowspec-payload-match-05.txt>\n\n      The rise in frequency, volume, and pernicious effects of DDoS attacks\n      has elevated them from fare for the specialist to generalist press.\n      Numerous reports detail the taxonomy of DDoS types, the varying\n      motivations of their attackers, as well as the resulting business and\n      reputation loss of their targets.\n      \n      BGP FlowSpec (RFC 5575, "Dissemination of Flow Specification Rules")\n      can be used to rapidly disseminate filters that thwart attacks, being\n      particularly effective against the volumetric type.  Operators can\n      use existing FlowSpec components to match on pre-defined packet\n      header fields.  However recent enhancements to forwarding plane\n      filter implementations allow matches at arbitary locations within the\n      packet header and, to some extent, the payload.  This capability can\n      be used to detect highly amplified attacks whose attack signature\n      remains relatively constant while values in the packet header vary,\n      as well as the burgeoning variety of tunneled traffic.\n      \n      We define a new FlowSpec component, "Flexible Match Conditions", with\n      similar matching semantics to those of existing components.  This\n      component will allow the operator to define bounded match conditions\n      using bit offsets and a variety of match types.\n\n  "PCEP extension to support Segment Routing Policy Candidate Paths", Mike\n  Koldychev, Siva Sivabalan, Colby Barth, Cheng Li, Hooman Bidgoli,\n  2019-10-30, <draft-barth-pce-segment-routing-policy-cp-04.txt>\n\n      This document introduces a mechanism to specify a Segment Routing\n      (SR) policy, as a collection of SR candidate paths.  An SR policy is\n      identified by <headend, color, end-point> tuple.  An SR policy can\n      contain one or more candidate paths where each candidate path is\n      identified in PCEP via an PLSP-ID.  This document proposes extension\n      to PCEP to support association among candidate paths of a given SR\n      policy.  The mechanism proposed in this document is applicable to\n      both MPLS and IPv6 data planes of SR.\n\n  "Anchorless mobility management through hICN (hICN-AMM): Deployment\n  options", Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele\n  Papalini, 2020-01-06,\n  <draft-auge-dmm-hicn-mobility-deployment-options-03.txt>\n\n      A novel mobility management approach is described in\n      [I-D.auge-dmm-hicn-mobility], that leverages routable location-\n      independent identifiers (IDs) and an Information-Centric Networking\n      (ICN) communication model integrated in IPv6, also referred to as\n      Hybrid ICN (hICN) [I-D.muscariello-intarea-hicn].\n      \n      Such approach belongs to the category of pure ID-based mobility\n      management schemes whose objective is (i) to overcome the limitations\n      of traditional locator-based solutions like Mobile IP, (ii) to remove\n      the need for a global mapping system as the one required by locator-\n      identifier separation solutions like LISP\n      [I-D.ietf-lisp-introduction] or ILA [I-D.herbert-intarea-ila].\n      \n      ID-based networking as proposed by ICN architectures allows to\n      disentangle forwarding operations from changes of network location,\n      hence removing tunnels and user plane or control plane anchors.  In\n      virtue of its anchorless property, we denote this approach as hICN-\n      AMM (hICN Anchorless Mobility Management) hereinafter.\n      \n      This document discusses hICN-AMM deployment options and related\n      tradeoffs in terms of cost/benefits.  Particular attention is devoted\n      to the insertion in the recently proposed 5G Service Based\n      Architecture under study at 3GPP where an hICN-AMM solution might\n      present a more efficient alternative to the traditional tunnel-based\n      mobility architecture through GTP-U.\n\n  "PIM Backup Designated Router Procedure", mankamana mishra, Joseph Goh,\n  Gyan Mishra, 2019-10-24, <draft-mankamana-pim-bdr-03.txt>\n\n      On a multi-access network, one of the PIM routers is elected as a\n      Designated Router (DR).  On the last hop LAN, the PIM DR is\n      responsible for tracking local multicast listeners and forwarding\n      traffic to these listeners if the group is operating in PIM-SM.  In\n      this document, we propose a mechanism to elect backup DR on a shared\n      LAN.  A backup DR on LAN would be useful for faster convergence.\n      This draft introduces the concept of a Backup Designated Router (BDR)\n      and the procedure to implement it.\n\n  "PCE Controlled ID Space", Cheng Li, Mach Chen, Jie Dong, Zhenbin Li, Aijun\n  Wang, Weiqiang Cheng, Chao Zhou, 2020-01-11,\n  <draft-li-pce-controlled-id-space-04.txt>\n\n      The Path Computation Element Communication Protocol (PCEP) provides\n      mechanisms for Path Computation Elements (PCEs) to perform path\n      computations in response to Path Computation Clients (PCCs) requests.\n      The Stateful PCE extensions allow stateful control of Multiprotocol\n      Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths\n      (LSPs) using PCEP.  Furthermore, PCEP can be used for computing paths\n      in SR networks.\n      \n      Stateful PCE provide active control of MPLS-TE LSPs via PCEP, for a\n      model where the PCC delegates control over one or more locally\n      configured LSPs to the PCE.  Further, stateful PCE could also create\n      and delete PCE-initiated LSPs itself.  A PCE-based central controller\n      (PCECC) simplify the processing of a distributed control plane by\n      integrating with elements of Software-Defined Networking (SDN).\n      \n      In some use cases, such as PCECC or Binding Segment Identifier (SID)\n      for Segment Routing (SR), there are requirements for a stateful PCE\n      to make allocation of labels, SIDs, etc.  These use cases require PCE\n      aware of various identifier spaces where to make allocations on\n      behalf of PCC.  This document describes a mechanism for PCC to inform\n      the PCE of the identifier space under its control via PCEP.  The\n      identifier could be MPLS label, SID or any other to-be-defined\n      identifier to be allocated by a PCE.\n\n  "Anchorless mobility through hICN", Jordan Auge, Giovanna Carofiglio, Luca\n  Muscariello, Michele Papalini, 2020-01-06,\n  <draft-auge-dmm-hicn-mobility-03.txt>\n\n      This document first discusses the use of locators and identifiers in\n      mobility management architectures, and their implication on various\n      anchorless properties.  A new architecture is then proposed that is\n      purely based on identifiers, and more specifically names as defined\n      in Hybrid-ICN (hICN) [I-D.muscariello-intarea-hicn].  The document\n      then focuses on two main cases: the end-point sends data (data\n      producer) or the end-point receives data (data consumer).  These two\n      cases are taken into account entirely to provide anchorless mobility\n      management in hICN.\n\n  "IGP Extensions for Segment Routing based Enhanced VPN", Jie Dong, Zhibo\n  Hu, Stewart Bryant, 2019-11-04, <draft-dong-lsr-sr-enhanced-vpn-02.txt>\n\n      Enhanced VPN (VPN+) is an enhancement to VPN services to support the\n      needs of new applications, particularly including the applications\n      that are associated with 5G services.  These applications require\n      better isolation and have more stringent performance requirements\n      than that can be provided with traditional overlay VPNs.  An enhanced\n      VPN may be used for 5G transport network slicing, and will also be of\n      use in more generic scenarios.  This document specifies the IGP\n      mechanisms with necessary extensions to build a set of Segment\n      Routing (SR) based virtual networks with customized topology and\n      resource attributes in the network.  These virtual networks could be\n      used as the underlay of enhanced VPN service.  The proposed mechanism\n      is applicable to both Segment Routing with MPLS data plane (SR-MPLS)\n      and segment routing with IPv6 data plane (SRv6).\n\n  "PCEP Extensions for Associated Bidirectional Segment Routing (SR) Paths",\n  Cheng Li, Mach Chen, Weiqiang Cheng, Zhenbin Li, Jie Dong, Rakesh Gandhi,\n  Quan Xiong, 2019-08-19, <draft-li-pce-sr-bidir-path-06.txt>\n\n      The Path Computation Element Communication Protocol (PCEP) provides\n      mechanisms for Path Computation Elements (PCEs) to perform path\n      computations in response to Path Computation Clients (PCCs) requests.\n      The Stateful PCE extensions allow stateful control of Multiprotocol\n      Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths\n      (LSPs) using PCEP.  Furthermore, PCEP can be used for computing paths\n      in Segment Routing (SR) TE networks.\n      \n      This document defines PCEP extensions for grouping two reverse\n      unidirectional SR Paths into an Associated Bidirectional SR Path when\n      using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as\n      well as when using a Stateless PCE.\n\n  "Rights for restricted content", Lutz Donnerhacke, 2019-09-07,\n  <draft-donnerhacke-linktax-04.txt>\n\n      Links are omnipresent in the Internet to provide access to other\n      resources.  There is no mechanism to express differences in law\n      systems, access limitations, or arbitrary rules defined by the owner\n      of the linked resource.  Therefore links do depend on and enforce a\n      communist sharing ideology, which ignores the content owner rights.\n      \n      Links may point to resources far away from the originating page,\n      hiding this fact from the customer.  It takes the data transport\n      services for free, internet transit providers on the way from the\n      content source to the customers are not extra payed for this effort.\n      In many cases, the remote company generates huge amount of money from\n      the customers worldwide not shared with the transit providers.\n      \n      In order to get the rights of all involved parties balanced, a new\n      type of connection initiation is proposed: The Right.\n\n  "Sliding Window Random Linear Code (RLC) Forward Erasure Correction (FEC)\n  Schemes for QUIC", Vincent Roca, Francois Michel, Ian Swett, Marie-Jose\n  Montpetit, 2019-11-04, <draft-roca-nwcrg-rlc-fec-scheme-for-quic-02.txt>\n\n      This document specifies Sliding Window Random Linear Code (RLC)\n      Forward Erasure Correction (FEC) Schemes for the QUIC transport\n      protocol, in order to recover from packet losses.\n\n  "Identification of Overlay Operations, Administration, and Maintenance\n  (OAM)", Gregory Mirsky, 2019-08-27, <draft-mirsky-rtgwg-oam-identify-03.txt>\n\n      This document analyzes how the presence of Operations,\n      Administration, and Maintenance (OAM) control command and/or special\n      data is identified in some overlay networks and an impact on the\n      choice of identification may have on OAM functionality.\n\n  "TLS 1.3 Authentication and Integrity only Cipher Suites", Nancy\n  Cam-Winget, Jack Visoky, 2020-01-03,\n  <draft-camwinget-tls-ts13-macciphersuites-05.txt>\n\n      There are use cases, specifically in Internet of Things (IoT) and\n      constrained environments that do not require confidentiality, though\n      mutual authentication during tunnel establishment and message\n      integrity is still mandated.  This document defines the use of HMAC\n      only cipher suites for TLS 1.3.\n\n  "TEAP Update and Extensions for Bootstrapping", Eliot Lear, Owen Friel,\n  Nancy Cam-Winget, Dan Harkins, 2019-11-03,\n  <draft-lear-eap-teap-brski-05.txt>\n\n      In certain environments, in order for a device to establish any layer\n      three communications, it is necessary for that device to be properly\n      credentialed.  This is a relatively easy problem to solve when a\n      device is associated with a human being and has both input and\n      display functions.  It is less easy when the human, input, and\n      display functions are not present.  To address this case, this memo\n      specifies extensions to the Tunnel Extensible Authentication Protocol\n      (TEAP) method that leverages Bootstrapping Remote Secure Key\n      Infrastructures (BRSKI) in order to provide a credential to a device\n      at layer two.  The basis of this work is that a manufacturer will\n      introduce the device and the local deployment through cryptographic\n      means.  In this sense the same trust model as BRSKI is used.\n\n  "Asymmetric Manifest Based Integrity", Jake Holland, Kyle Rose, 2019-09-26,\n  <draft-jholland-mboned-ambi-04.txt>\n\n      This document defines Asymmetric Manifest-Based Integrity (AMBI).\n      AMBI allows each receiver or forwarder of a stream of multicast\n      packets to check the integrity of the contents of each packet in the\n      data stream.  AMBI operates by passing cryptographically verifiable\n      hashes of the data packets inside manifest messages, and sending the\n      manifests over authenticated out-of-band communication channels.\n\n  "pretty Easy privacy (pEp): Contact and Channel Authentication through\n  Handshake", Hernani Marques, Bernie Hoeneisen, 2020-01-08,\n  <draft-marques-pep-handshake-04.txt>\n\n      In interpersonal messaging end-to-end encryption means for public key\n      distribution and verification of its authenticity are needed; the\n      latter to prevent man-in-the-middle (MITM) attacks.\n      \n      This document proposes a new method to easily verify a public key is\n      authentic by a Handshake process that allows users to easily\n      authenticate their communication channel.  The new method is targeted\n      to Opportunistic Security scenarios and is already implemented in\n      several applications of pretty Easy privacy (pEp).\n\n  "LISP Data-Plane Telemetry", Dino Farinacci, Said Ouissal, Erik Nordmark,\n  2019-12-16, <draft-farinacci-lisp-telemetry-03.txt>\n\n      This draft specs a JSON formatted RLOC-record for telemetry data\n      which decapsulating xTRs include in RLOC-probe Map Reply messages.\n\n  "BGP-LS Extensions for Advertising Path MTU", Yongqing Zhu, Zhibo Hu, Gang\n  Yan, Junda Yao, 2020-01-06, <draft-zhu-idr-bgp-ls-path-mtu-02.txt>\n\n      BGP Link State (BGP-LS) describes a mechanism by which link-state and\n      TE information can be collected from networks and shared with\n      external components using the BGP routing protocol.  The centralized\n      controller (PCE/SDN) completes the service path calculation based on\n      the information transmitted by the BGP-LS and delivers the result to\n      the Path Computation Client (PCC) through the PCEP or BGP protocol.\n      \n      Segment Routing (SR) leverages the source routing paradigm, which can\n      be directly applied to the MPLS architecture with no change on the\n      forwarding plane and applied to the IPv6 architecture, with a new\n      type of routing header, called SRH.  The SR uses the IGP protocol as\n      the control protocol.  Compared to the MPLS tunneling technology, the\n      SR does not require additional signaling.  Therefore, the SR does not\n      support the negotiation of the Path MTU.  Since Multiple labels or\n      SRv6 SIDs are pushed in the packets, it is more likely that the\n      packet size exceeds the path mtu of SR tunnel.\n      \n      This document specify the extension to BGP Link State (BGP-LS) to\n      carry maximum transmission unit (MTU) messages of link.  The PCE/SDN\n      calculates the Path MTU while completing the service path calculation\n      based on the information transmitted by the BGP-LS.\n\n  "Segment Routing Path MTU in BGP", Cheng Li, Yongqing Zhu, Ahmed El Sawaf,\n  Zhenbin Li, 2019-11-03, <draft-li-idr-sr-policy-path-mtu-03.txt>\n\n      Segment Routing is a source routing paradigm that explicitly\n      indicates the forwarding path for packets at the ingress node.  An SR\n      policy is a set of candidate SR paths consisting of one or more\n      segment lists with necessary path attributes.  However, the path\n      maximum transmission unit (MTU) information for SR path is not\n      available in the SR policy since the SR does not require signaling.\n      This document defines extensions to BGP to distribute path MTU\n      information within SR policies.\n\n  "Monitoring BGP Parameters Using BMP", Shunwan Zhuang, Yunan Gu, Haibo\n  Wang, 2019-11-04, <draft-zhuang-grow-monitoring-bgp-parameters-01.txt>\n\n      The BGP Monitoring Protocol (BMP) [RFC7854] is designed to monitor\n      BGP [RFC4271] running status, such as BGP peer relationship\n      establishment and termination and route updates.  Without BMP, manual\n      query is required if you want to know about BGP running status.\n      \n      This document provides the use cases that the BMP station can get the\n      optional parameters that are supported by the monitored network\n      device and default configure parameters of the monitored network\n      device via BMP.\n\n  "Study Report on a Framework for Cloud Inter-connection toward the\n  Realization of IoT", Hiroyuki BABA, Izaya Miyake, Jun Matsumura, Yoshiki\n  Ishida, 2020-01-09, <draft-baba-iot-interconnection-03.txt>\n\n      This paper describes issues for solutions through cloud inter-\n      connection to structural problems, which are called as "silo effects"\n      found in cloud-connected electric home appliances, housing equipment\n      and sensors in the face of increasingly accelerated connection of\n      them.  Specifically, this paper explains an inter-connection\n      agreement considered to be required for enhancement of cloud inter-\n      connection, what performance guarantee as well as IoT supervising and\n      management should be, necessity of inter-connection HUB which is able\n      to provide inter-connection amongst the preponderance of private\n      cloud groups, and the necessity of a mechanism to avoid threats that\n      cause danger to users when we make the inter-connection.\n\n  "Security Policy Translation in Interface to Network Security Functions",\n  Jaehoon Jeong, Jinhyuk Yang, Chaehong Chung, Jinyong Kim, 2019-11-04,\n  <draft-yang-i2nsf-security-policy-translation-05.txt>\n\n      This document proposes a scheme of security policy translation (i.e.,\n      Security Policy Translator) in Interface to Network Security\n      Functions (I2NSF) Framework.  When I2NSF User delivers a high-level\n      security policy for a security service, Security Policy Translator in\n      Security Controller translates it into a low-level security policy\n      for Network Security Functions (NSFs).  For this security policy\n      translation, this document specifies the mapping between a high-level\n      security policy based on the Consumer-Facing Interface YANG data\n      model and a low-level security policy based on the NSF-Facing\n      Interface YANG data model.  Also, it describes an architecture of a\n      security policy translator along with an NSF database, and the\n      process of security policy translation with the NSF database.\n\n  "Design Discussion of Route Leaks Solution Methods", Kotikalapudi Sriram,\n  2019-08-05, <draft-sriram-idr-route-leak-solution-discussion-02.txt>\n\n      This document captures the design rationale of the route leaks\n      solution document (see draft-ietf-idr-route-leak-detection-\n      mitigation, draft-ietf-grow-route-leak-detection-mitigation).  The\n      designers needed to balance many competing factors, and this document\n      provides insights into the design questions and their resolution.\n\n  "pretty Easy privacy (pEp): Mapping of Privacy Rating", Hernani Marques,\n  Bernie Hoeneisen, 2020-01-08, <draft-marques-pep-rating-03.txt>\n\n      In many Opportunistic Security scenarios end-to-end encryption is\n      automatized for Internet users.  In addition, it is often required to\n      provide the users with easy means to carry out authentication.\n      \n      Depending on several factors, each communication channel to different\n      peers may have a different Privacy Status, e.g., unencrypted,\n      encrypted and encrypted as well as authenticated.  Even each message\n      from/to a single peer may have a different Privacy Status.\n      \n      To display the actual Privacy Status to the user, this document\n      defines a Privacy Rating scheme and its mapping to a traffic-light\n      semantics.  A Privacy Status is defined on a per-message basis as\n      well as on a per-identity basis.  The traffic-light semantics (as\n      color rating) allows for a clear and easily understandable\n      presentation to the user in order to optimize the User Experience\n      (UX).\n      \n      This rating system is most beneficial to Opportunistic Security\n      scenarios and is already implemented in several applications of\n      pretty Easy privacy (pEp).\n\n  "Resource Reservation Protocol for IP Transport QoS", Lin Han, Yingzhen Qu,\n  Lijun Dong, Renwei Li, Thomas Nadeau, Kevin Smith, Jeff Tantsura,\n  2019-10-15, <draft-han-tsvwg-ip-transport-qos-03.txt>\n\n      IP is designed for use in Best Effort Networks, which are networks\n      that provide no guarantee that data is delivered, or that delivery\n      meets any specified quality of service parameters.  However there are\n      new applications requiring IP to provide deterministic services in\n      terms of bandwidth and latency, such as network based AR/VR\n      (Augmented Reality and Virtual Reality), industrial internet.  This\n      document proposes a solution in IPv6 that can be used by transport\n      layer protocols to guarantee certain level of service quality.  This\n      new service is fined-grained and could apply to individual or\n      aggregated TCP/UDP flow(s).\n\n  "Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane",\n  Chandrasekar R, Vishnu Beeram, Harish Sitaraman, 2020-01-09,\n  <draft-chandra-mpls-rsvp-shared-labels-np-03.txt>\n\n      Segment Routed RSVP-TE tunnels provide the ability to use a shared\n      MPLS forwarding plane at every hop of the Label Switched Path (LSP).\n      The shared forwarding plane is realized with the use of \'Traffic\n      Engineering (TE) link labels\' that get shared by LSPs traversing\n      these TE links.  This paradigm helps significantly reduce the\n      forwarding plane state required to support a large number of LSPs on\n      a Label Switching Router (LSR).  These tunnels require the ingress\n      Label Edge Router (LER) to impose a stack of labels.  If the ingress\n      LER cannot impose the full label stack, it can use the assistance of\n      one or more delegation hops along the path of the LSP to impose parts\n      of the label stack.\n      \n      The procedures for a Point of Local Repair (PLR) to provide local\n      protection against link failures using facility backup for Segment\n      Routed RSVP-TE tunnels are well defined and do not require specific\n      protocol extensions.  This document defines the procedures for a PLR\n      to provide local protection against transit node failures using\n      facility backup for these tunnels.  The procedures defined in this\n      document include protection against delegation hop failures.\n\n  "LISP Control Plane for SRv6 Endpoint Mobility", Alberto Rodriguez-Natal,\n  Vina Ermagan, Fabio Maino, Darren Dukes, Pablo Camarillo, Clarence\n  Filsfils, 2020-01-23, <draft-rodrigueznatal-lisp-srv6-03.txt>\n\n      This document describes the use of the LISP Control Plane to support\n      endpoint mobility and Location/ID separation in Segment Routing v6\n      (SRv6) deployments.\n\n  "Building blocks for Slicing in Segment Routing Network", Zafar Ali,\n  Clarence Filsfils, Pablo Camarillo, Daniel Voyer, 2019-11-03,\n  <draft-ali-spring-network-slicing-building-blocks-02.txt>\n\n      This document describes how to build network slice using the\n      Segment Routing based technology. It explains how the existing\n      building blocks specified for the Segment Routing can be used for\n      this purpose.\n\n  "Terminology for Cryptoassets", Hirotaka Nakajima, Masanori Kusunoki,\n  Keiichi Hida, Yuji Suga, Tatsuya Hayashi, 2019-12-31,\n  <draft-nakajima-crypto-asset-terminology-03.txt>\n\n      This document provides terminology used in cryptoassets.\n\n  "A YANG Data Model for Network Bridge Management", Vladimir Vassilev,\n  2020-01-05, <draft-vassilev-netmod-network-bridge-03.txt>\n\n      This document introduces new YANG model of a network bridge.\n\n  "Flexible Session Protocol", Jun-an, Gao, 2019-10-17,\n  <draft-gao-flexible-session-protocol-03.txt>\n\n      FSP is a connection-oriented transport layer protocol that provides\n      mobility and multihoming support by introducing the concept of \'upper\n      layer thread ID\', which is associated with some shared secret that is\n      applied with some secure hash or authenticated encryption algorithm\n      to protect authenticity of the origin of the FSP packets. It is able\n      to provide following services to the upper layer application:\n      \n      o  Stream-oriented send-receive with native message boundary\n      support\n      o  Ubiquitous authenticated encryption\n      \n      o  0-RTT multiplication of connections\n      \n      o  On-the-wire compression\n\n  "SRv6 Mobility Use-Cases", Pablo Camarillo, Clarence Filsfils, Hani\n  Elmalky, Satoru Matsushima, Daniel Voyer, Anna Cui, Bart Peirens,\n  2019-08-15, <draft-camarilloelmalky-springdmm-srv6-mob-usecases-02.txt>\n\n      This document describes the SRv6 use-cases in the mobile network in\n      association with different mobile generations (3G, 4G, and 5G).  It\n      also highlights potential interworking with SR-MPLS in relevant use-\n      cases.\n\n  "Transport Network aware Mobility for 5G", Uma Chunduri, Renwei Li, Sridhar\n  Bhaskaran, John Kaippallimalil, Jeff Tantsura, Luis Contreras, Praveen\n  Muley, 2019-11-04, <draft-clt-dmm-tn-aware-mobility-05.txt>\n\n      This document specifies a framework and a mapping function for 5G\n      mobile user plane with transport network slicing, integrated with\n      Mobile Radio Access and a Virtualized Core Network.  The integrated\n      approach is specified in a way to fit into the 5G core network\n      architecture defined in [TS23.501].\n      \n      It focuses on an optimized mobile user plane functionality with\n      various transport services needed for some of the 5G traffic needing\n      low and deterministic latency, real-time, mission-critical services.\n      This document describes, how this objective is achieved agnostic to\n      the transport underlay used (IPv6, MPLS, IPv4) in various deployments\n      and with a new transport network underlay routing, called Preferred\n      Path Routing (PPR).\n\n  "BGP-LS Advertisement of Segment Routing Service Segments", Gaurav Dawra,\n  Clarence Filsfils, Ketan Talaulikar, Francois Clad, daniel.bernier@bell.ca,\n  Jim Uttaro, Bruno Decraene, Hani Elmalky, Xiaohu Xu, Jim Guichard, Cheng\n  Li, 2020-01-07, <draft-dawra-idr-bgp-ls-sr-service-segments-03.txt>\n\n      BGP Link-State (BGP-LS) enables distribution of topology information\n      from the network to a Path Computation Engine (PCE) or any\n      controller/application in general so it can learn the network\n      topology.  Service functions are deployed as, physical or virtualized\n      elements along with network elements or on servers in data centers.\n      The advertisement of such attached service capabilities along with\n      the network nodes that they are attached to or associated with\n      enables their discovery and the programming of service paths that use\n      these service functions.  Segment Routing (SR) brings in the concept\n      of segments which can be topological or service instructions.  SR\n      Policies enable the setup of paths which are a mix of topological and\n      service segments.\n      \n      This document specifies the extensions to BGP-LS for discovery and\n      advertisement of service segments to enable the setup of service\n      programming paths using Segment Routing.\n\n  "BGP Automated Session Setup", Robert Raszuk, 2019-12-11,\n  <draft-raszuk-idr-bgp-auto-session-setup-01.txt>\n\n      This document proposes a solution for BGP deployments in some\n      specific environments to automatically establish BGP sessions without\n      need for manual peer configuration.\n\n  "Implementation notes for RFC7991, "The \'xml2rfc\' Version 3 Vocabulary"",\n  Henrik Levkowetz, 2019-10-15,\n  <draft-levkowetz-xml2rfc-v3-implementation-notes-10.txt>\n\n      This memo documents issues and observations found while implementing\n      RFC 7991.  Individual notes are organised into separate sections,\n      depending on their character.\n\n  "Extensions to OSPF for Advertising Prefix Administrative Tags", Acee\n  Lindem, Peter Psenak, 2020-01-20, <draft-acee-lsr-ospf-admin-tags-04.txt>\n\n      It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be\n      able to associate tags with prefixes.  Previously, OSPFv2 and OSPFv3\n      were relegated to a single tag for AS External and Not-So-Stubby-Area\n      (NSSA) prefixes.  With the flexible encodings provided by OSPFv2\n      Prefix Attribute Advertisement and OSPFv3 Extended LSAs, multiple\n      administrative tags may advertised for all types of prefixes.  These\n      administrative tags can be used for many applications including route\n      redistribution policy, selective prefix prioritization, selective IP\n      Fast-ReRoute (IPFRR) prefix protection, and many others.\n      \n      The ISIS protocol supports a similar mechanism that is described in\n      RFC 5130.\n\n  "YANG Data Model for IS-IS SRv6", Zhibo Hu, Dan Ye, Yingzhen Qu, Jiajia\n  Dong, 2019-11-03, <draft-hu-isis-srv6-yang-02.txt>\n\n      This document defines a YANG data model that can be used to configure\n      and manage IS-IS SRv6 [I-D.ietf-lsr-isis-srv6-extensions].\n\n  "Distributing OpenPGP Key Fingerprints with Signed Keylist Subscriptions",\n  R. McCain, Micah Lee, Nat Welch, 2019-09-02, <draft-mccain-keylist-05.txt>\n\n      This document specifies a system by which an OpenPGP client may\n      subscribe to an organization\'s public keylist to keep its keystore\n      up-to-date with correct keys from the correct keyserver(s), even in\n      cases where the keys correspond to multiple (potentially\n      uncontrolled) domains.  Ensuring that all members or followers of an\n      organization have their colleagues\' most recent PGP public keys is\n      critical to maintaining operational security.  Without the most\n      recent keys\' fingerprints and a source of trust for those keys (as\n      this document specifies), users must manually update and sign each\n      others\' keys -- a system that is untenable in larger organizations.\n      This document proposes a experimental format for the keylist file as\n      well as requirements for clients who wish to implement this\n      experimental keylist subscription functionality.\n\n  "The Decentralized Identifier (DID) in the DNS", Alexander Mayrhofer,\n  Dimitrij Klesev, Markus Sabadello, 2019-08-26,\n  <draft-mayrhofer-did-dns-02.txt>\n\n      This document specifies the use of the URI Resource Record Type to\n      publish Decentralized Identifiers (DIDs) in the DNS.\n\n  "Access Extensions for the Access Node Control Protocol", Hongyu Li, Thomas\n  Haag, Birgit Witschurke, 2019-09-23,\n  <draft-lihawi-ancp-protocol-access-extension-03.txt>\n\n      The purpose of this document is to specify extensions to ANCP (Access\n      Node Control Protocol) (RFC6320) to support PON as described in\n      RFC6934 and some other DSL Technologies including G.fast.  This\n      document updates RFC6320 by modifications to terminologies, flows and\n      specifying new TLV types.\n      \n      This document updates RFC6320 by modifications to terminologies,\n      flows and specifying new TLV types.\n\n  "YANG Data Model for Configuration Interface of Control-Plane and\n  User-Plane separation BNG", Daniel Huang, Sujun Hu, Fengwei Qin,\n  2019-09-10, <draft-cuspdt-rtgwg-cu-separation-yang-model-04.txt>\n\n      This document defines the YANG data model for management of Control-\n      Plane and User-Plane separation of BNGs (Broadband Network Gateways).\n\n  "IPv6-based discovery and association of Virtualization Infrastructure\n  Manager (VIM) and Network Function Virtualization Orchestrator (NFVO)",\n  Carlos Bernardos, Alain Mourad, 2019-08-26,\n  <draft-bernardos-intarea-vim-discovery-02.txt>\n\n      Virtualized resources do not need to be limited to those available in\n      traditional data centers, where the infrastructure is stable, static,\n      typically homogeneous and managed by a single admin entity.\n      Computational capabilities are becoming more and more ubiquitous,\n      with terminal devices getting extremely powerful, as well as other\n      types of devices that are close to the end users at the edge (e.g.,\n      vehicular onboard devices for infotainment, micro data centers\n      deployed at the edge, etc.).  It is envisioned that these devices\n      would be able to offer storage, computing and networking resources to\n      nearby network infrastructure, devices and things (the fog paradigm).\n      These resources can be used to host functions, for example to\n      offload/complement other resources available at traditional data\n      centers, but also to reduce the end-to-end latency or to provide\n      access to specialized information (e.g., context available at the\n      edge) or hardware.\n      \n      This document describes mechanisms allowing dynamic discovery of\n      virtualization resources and orchestrators in IPv6-based networks.\n      In the current version, mechanisms based on piggybacking options on\n      IPv6 neighbor discovery are explored.  New IPv6 neighbor discovery\n      options are defined.  Additional mechanisms will be explored in\n      future releases of this document.\n\n  "RFC Editor Model (Version 2)", Olaf Kolkman, Joel Halpern, Robert Hinden,\n  2019-10-04, <draft-ietf-iasa2-rfc6635bis-04.txt>\n\n      The RFC Editor model described in this document divides the\n      responsibilities for the RFC Series into three functions: the RFC\n      Series Editor, the RFC Production Center, and the RFC Publisher.\n      Internet Architecture Board (IAB) oversight via the RFC Series\n      Oversight Committee (RSOC) is described, as is the relationship\n      between the IETF Administration Limited Liability Company and the\n      RSOC.  This document reflects the experience gained with "RFC Editor\n      Model (Version 1)", documented in RFC 5620; and obsoletes RFC 6635 to\n      replace all references to the IASA and related structures with those\n      defined by the IASA 2.0 Model.\n      \n      [RFC Editor: Please remove the following paragraph prior to\n      publication.]\n      \n      The IASA2 WG requests that the IAB publish this replacement for RFC\n      6635.\n\n  "DNS TIMEOUT Resource Record", Tom Pusateri, Tim Wattenberg, 2019-11-04,\n  <draft-pusateri-dnsop-update-timeout-04.txt>\n\n      This specification defines a new DNS TIMEOUT resource record (RR)\n      that associates a lifetime with one or more zone resource records.\n      It is intended to be used to transfer resource record lifetime state\n      between a zone\'s primary and secondary servers and to store lifetime\n      state during server software restarts.\n\n  "ECC Brainpool Curves for Transport Layer Security (TLS) Version 1.3",\n  Leonie Bruckert, Johannes Merkle, Manfred Lochter, 2019-09-26,\n  <draft-bruckert-brainpool-for-tls13-07.txt,.pdf>\n\n      ECC Brainpool curves were an option for authentication and key\n      exchange in the Transport Layer Security (TLS) protocol version 1.2,\n      but were deprecated by the IETF for use with TLS version 1.3 because\n      they had little usage.  However, these curves have not been shown to\n      have significant cryptographical weaknesses, and there is some\n      interest in using several of these curves in TLS 1.3.\n      \n      This document provides the necessary protocol mechanisms for using\n      ECC Brainpool curves in TLS 1.3.  This approach is not endorsed by\n      the IETF.\n\n  "BGP Topology Discovery Requirements", Randy Bush, Keyur Patel, 2019-10-21,\n  <draft-ymbk-lsvr-discovery-req-03.txt>\n\n      For wide scale routing protocols to build their topology and\n      reachability databases they need to discover the encapsulation data\n      on a link, link IP layer 3 attributes, attributes for IP layer 3 and\n      above protocols on that link, and link liveness.  We refer to this as\n      neighbor discovery.  BGP-LS and its enhancements provide an API to\n      present much of these data to BGP protocols, but do not directly\n      collect these data.  This document explores the needs and criteria\n      for the data needed.\n\n  "Congestion Control based on Forward path Status", jungnam.gwock, SangHyun\n  Lee, 2019-08-27, <draft-gwock-rmcat-ccfs-02.txt>\n\n      This document describes CCFS(Congestion Control based on Forward path\n      Status), a rate adaptation scheme for interactive real-time media\n      applications, such as video conferencing. CCFS classifies the forward\n      paths\'s status as throttled, competing, probing and default which is\n      managed based on estimated parameters - bottleneck bandwidth, queue\n      delay and loss ratio. Considering only forward path status minimizes\n      influence of backward path\'s network events such as congestion. It is\n      also free from compatibility issues because it defines generalized\n      feedback message.\n\n  "Extended Procedures for EVPN Optimized Ingress Replication", Wen Lin,\n  Selvakumar Sivaraj, Vishal Garg, Jorge Rabadan, 2019-11-01,\n  <draft-wsv-bess-extended-evpn-optimized-ir-02.txt>\n\n      [EVPN-AR] specifies an optimized ingress replication solution for\n      more efficient multicast and broadcast delivery in a Network\n      Virtualization Overlay (NVO) network for EVPN.\n      \n      This document extends the optimized ingress replication procedures\n      specified in [EVPN-AR] to overcome the limitation that an AR-\n      REPLICATOR may have.  An AR-REPLICATOR may be unable to retain the\n      source IP address or include the expected ESI label that is required\n      for EVPN split horizon filtering when replicating the packet on\n      behalf of its multihomed AR-LEAF.  Under this circumstance, the\n      extended procedures specified in this document allows the support of\n      EVPN multihoming on the AR-LEAFs as well as optimized ingress\n      replication for the rest of the EVPN overlay network.\n\n  "Asymmetric Extended Route Optimization (AERO)", Fred Templin, 2020-01-27,\n  <draft-templin-intarea-6706bis-20.txt>\n\n      This document specifies the operation of IP over tunnel virtual links\n      using Asymmetric Extended Route Optimization (AERO).  AERO interfaces\n      use an IPv6 link-local address format that supports operation of the\n      IPv6 Neighbor Discovery (ND) protocol and links ND to IP forwarding.\n      Prefix delegation/registration services are employed for network\n      admission and to manage the routing system.  Multilink operation,\n      mobility management, quality of service (QoS) signaling and route\n      optimization are naturally supported through dynamic neighbor cache\n      updates.  Standard IP multicasting services are also supported.  AERO\n      is a widely-applicable mobile internetworking service especially\n      well-suited to aviation services, mobile Virtual Private Networks\n      (VPNs) and many other applications.\n\n  "Clarifications and Implementation Guidelines for using TCP Encapsulation\n  in IKEv2", Valery Smyslov, 2019-12-17,\n  <draft-smyslov-ipsecme-tcp-guidelines-03.txt>\n\n      The Internet Key Exchange Protocol version 2 (IKEv2) defined in\n      [RFC7296] uses UDP transport for its messages.  [RFC8229] specifies a\n      way to encapsulate IKEv2 and ESP (Encapsulating Security Payload)\n      messages in TCP, thus making possible to use them in network\n      environments that block UDP traffic.  However, some nuances of using\n      TCP in IKEv2 are not covered by that specification.  This document\n      provides clarifications and implementation guidelines for [RFC8229].\n\n  "An Unreliable Datagram Extension to QUIC", Tommy Pauly, Eric Kinnear,\n  David Schinazi, 2019-11-04, <draft-pauly-quic-datagram-05.txt>\n\n      This document defines an extension to the QUIC transport protocol to\n      add support for sending and receiving unreliable datagrams over a\n      QUIC connection.\n      \n      Discussion of this work is encouraged to happen on the QUIC IETF\n      mailing list quic@ietf.org [1] or on the GitHub repository which\n      contains the draft: https://github.com/tfpauly/draft-pauly-quic-\n      datagram [2].\n\n  "Using HTTP/2 as a Transport for Arbitrary Bytestreams", Eric Kinnear,\n  Tommy Pauly, 2019-11-04, <draft-kinnear-httpbis-http2-transport-02.txt>\n\n      HTTP/2 provides multiplexing of HTTP requests over a single\n      underlying transport connection.  HTTP/2 Transport defines the use of\n      the bidirectional extended CONNECT handshake to negotiate the use of\n      application protocols using streams of an HTTP/2 connection as\n      transport.\n\n  "Independent Submission Editor Model", Nevil Brownlee, Robert Hinden,\n  2019-01-07, <draft-ietf-iasa2-rfc6548bis-02.txt>\n\n      This document describes the function and responsibilities of the RFC\n      Independent Submission Editor (ISE).  The Independent Submission\n      stream is one of the stream producers that create draft RFCs, with\n      the ISE as its stream approver.  The ISE is overall responsible for\n      activities within the Independent Submission stream, working with\n      draft editors and reviewers, and interacts with the RFC Production\n      Center and Publisher, and the RFC Series Editor (RSE).  The ISE is\n      appointed by the IAB, and also interacts with the IETF Administration\n      Limited Liability Company (LLC).\n      \n      This version obsoletes RFC 6548 to replace all references to the IASA\n      and related structures with those defined by the IASA 2.0 Model.\n      \n      [RFC Editor: Please remove the following paragraph prior to\n      publication.]\n      \n      The IASA2 WG requests that the IAB publish this replacement for RFC\n      6548.\n\n  "Login Security Policy Extensions Mapping for the Extensible Provisioning\n  Protocol (EPP)", James Gould, 2019-08-02,\n  <draft-gould-regext-login-security-policy-03.txt>\n\n      This document describes an Extensible Provisioning Protocol (EPP)\n      extension of the Registry Mapping to define the server policy of the\n      Login Security EPP extension.  The server policy of the Login\n      Security EPP extension includes the MAYs, SHOULDs, and options\n      implemented by the server.\n\n  "Using Multicast DNS to protect privacy when exposing ICE candidates",\n  Youenn Fablet, Jeroen Borst, Justin Uberti, Qingsi Wang, 2019-10-16,\n  <draft-ietf-rtcweb-mdns-ice-candidates-04.txt>\n\n      WebRTC applications collect ICE candidates as part of the process of\n      creating peer-to-peer connections.  To maximize the probability of a\n      direct peer-to-peer connection, client private IP addresses are\n      included in this candidate collection.  However, disclosure of these\n      addresses has privacy implications.  This document describes a way to\n      share local IP addresses with other clients while preserving client\n      privacy.  This is achieved by concealing IP addresses with\n      dynamically generated Multicast DNS (mDNS) names.\n\n  "Virtualization YANG Servise Model (VYSM)", Dmytro Shytyi, Laurent Beylier,\n  Luigi Iannone, 2019-09-05, <draft-shytyi-netmod-vysm-02.txt,.pdf>\n\n      This document provides a specification of the Virtual Network\n      Functions YANG Service Model (VYSM).  The VNF YANG Service Model\n      serves as a base framework for managing an universal Customer-\n      Premises Equipment (uCPE) NFV subsystem from the Orchestrator.\n\n  "Guide for building an EDDSA pki", Robert Moskowitz, Henk Birkholz, Michael\n  Richardson, 2019-08-19, <draft-moskowitz-eddsa-pki-02.txt>\n\n      This memo provides a guide for building a PKI (Public Key\n      Infrastructure) using openSSL.  Certificates in this guide can be\n      either ED25519 or ED448 certificates.  Along with common End Entity\n      certificates, this guide provides instructions for creating IEEE\n      802.1AR iDevID Secure Device certificates.\n\n  "Loading MUD URLs from QR codes", Michael Richardson, Jacques Latour,\n  2019-12-27, <draft-richardson-opsawg-securehomegateway-mud-02.txt>\n\n      This informational document details the mechanism used by the CIRA\n      Secure Home Gateway (SHG) to load MUD definitions for devices which\n      have no integrated MUD (RFC8520) support.\n      \n      The document describes extensions to the WiFi Alliance DPP QR code to\n      support the use of MUD URLs.\n\n  "A YANG Model for Network and VPN Service Performance Monitoring", Zitao\n  Wang, Qin WU, Roni Even, Bin Wen, Chang Liu, Honglei Xu, 2019-11-01,\n  <draft-www-bess-yang-vpn-service-pm-04.txt>\n\n      The data model defined in [RFC8345] introduces vertical layering\n      relationships between networks that can be augmented to cover\n      network/service topologies.  This document defines a YANG model for\n      both Network Performance Monitoring and VPN Service Performance\n      Monitoring that can be used to monitor and manage network performance\n      on the topology at higher layer or the service topology between VPN\n      sites.  This model is an augmentation to the network topology YANG\n      data model defined in [RFC8345].\n\n  "Commercial National Security Algorithm (CNSA) Suite Profile of Certificate\n  Management over CMS", Michael Jenkins, Lydia Zieglar, 2019-05-29,\n  <draft-jenkins-cnsa-cmc-profile-05.txt>\n\n      This document specifies a profile of the Certificate Management over\n      CMS (CMC) protocol for managing X.509 public key certificates in\n      applications that use the Commercial National Security Algorithm\n      (CNSA) Suite published by the United States Government.\n      \n      The profile applies to the capabilities, configuration, and operation\n      of all components of US National Security Systems that manage X.509\n      public key certificates over CMS.  It is also appropriate for all\n      other US Government systems that process high-value information.\n      \n      The profile is made publicly available here for use by developers and\n      operators of these and any other system deployments.\n\n  "The OPAQUE Asymmetric PAKE Protocol", Hugo Krawczyk, 2019-10-19,\n  <draft-krawczyk-cfrg-opaque-03.txt>\n\n      This draft describes the OPAQUE protocol, a secure asymmetric\n      password authenticated key exchange (aPAKE) that supports mutual\n      authentication in a client-server setting without reliance on PKI and\n      with security against pre-computation attacks upon server compromise.\n      Prior aPAKE protocols did not use salt and if they did, the salt was\n      transmitted in the clear from server to user allowing for the\n      building of targeted pre-computed dictionaries.  OPAQUE security has\n      been proven by Jarecki et al.  (Eurocrypt 2018) in a strong and\n      universally composable formal model of aPAKE security.  In addition,\n      the protocol provides forward secrecy and the ability to hide the\n      password from the server even during password registration.\n      \n      Strong security, versatility through modularity, good performance,\n      and an array of additional features make OPAQUE a natural candidate\n      for practical use and for adoption as a standard.  To this end, this\n      draft presents several optimized instantiations of OPAQUE and ways of\n      integrating OPAQUE with TLS.\n      \n      This draft presents a high-level description of OPAQUE highlighting\n      its components and modular design.  A detailed unambiguous\n      specification for standardization will be presented in future\n      revisions of this document, or separately.\n\n  "A YANG Data model for ECA Policy Management", Zitao Wang, Qin WU, Igor\n  Bryskin, Xufeng Liu, Benoit Claise, 2019-12-10,\n  <draft-wwx-netmod-event-yang-06.txt>\n\n      RFC8328 defines a policy-based management framework that allows\n      definition of a data model to be used to represent high-level,\n      possibly network-wide policies.  Policy discussed in RFC8328 are\n      classified into imperative policy and declarative policy, Event\n      Condition Action (ECA) policy is an typical example of imperative\n      policy.  This document defines a YANG data model for the ECA policy\n      management.  The ECA policy YANG provides the ability for the network\n      management function (within a network element) to control the\n      configuration and monitor state change and take simple and instant\n      action on the server when a trigger condition on the system state is\n      met.\n\n  "Extensible Provisioning Protocol (EPP) Unhandled Namespaces", James Gould,\n  Martin Casanova, 2019-09-24,\n  <draft-gould-casanova-regext-unhandled-namespaces-02.txt>\n\n      The Extensible Provisioning Protocol (EPP), as defined in RFC 5730,\n      includes a method for the client and server to determine the objects\n      to be managed during a session and the object extensions to be used\n      during a session.  The services are identified using namespace URIs.\n      How should the server handle service data that needs to be returned\n      in the response when the client does not support the required service\n      namespace URI, which is referred to as an unhandled namespace?  An\n      unhandled namespace is a significant issue for the processing of RFC\n      5730 poll messages, since poll messages are inserted by the server\n      prior to knowing the supported client services, and the client needs\n      to be capable of processing all poll messages.  This document defines\n      an operational practice that enables the server to return information\n      associated with unhandled namespace URIs that is compliant with the\n      negotiated services defined in RFC 5730.\n\n  "Defining the Role and Function of IETF Protocol Parameter Registry\n  Operators", Danny McPherson, Olaf Kolkman, John Klensin, Geoff Huston, IAB,\n  2019-10-18, <draft-ietf-iasa2-rfc6220bis-04.txt>\n\n      Many Internet Engineering Task Force (IETF) protocols make use of\n      commonly defined values that are passed in messages or packets.  To\n      ensure consistent interpretation of these values between independent\n      implementations, there is a need to ensure that the values and\n      associated semantic intent are uniquely defined.  The IETF uses\n      registry functions to record assigned protocol parameter values and\n      their associated semantic intentions.  For each IETF protocol\n      parameter, it is current practice for the IETF to delegate the role\n      of Protocol Parameter Registry Operator to a nominated entity.  This\n      document provides a description of, and the requirements for, these\n      delegated functions.  This document obsoletes RFC 6220 to replace all\n      references to the IASA and related structures with those defined by\n      the IASA 2.0 Model.\n\n  "Pros and Cons of IPv6 Transition Technologies for IPv4aaS", Gabor Lencse,\n  Jordi Palet, Lee Howard, Richard Patterson, Ian Farrer, 2020-01-06,\n  <draft-lmhp-v6ops-transition-comparison-04.txt>\n\n      Several IPv6 transition technologies have been developed to provide\n      customers with IPv4-as-a-Service (IPv4aaS) for ISPs with an IPv6-only\n      access and/or core network.  All these technologies have their\n      advantages and disadvantages, and depending on existing topology,\n      skills, strategy and other preferences, one of these technologies may\n      be the most appropriate solution for a network operator.\n      \n      This document examines the five most prominent IPv4aaS technologies\n      considering a number of different aspects to provide network\n      operators with an easy to use reference to assist in selecting the\n      technology that best suits their needs.\n\n  "Benchmarking Methodology for EVPN VPWS", sudhin jacob, Kishore\n  Tiruveedhula, 2019-12-12, <draft-kishjac-bmwg-evpnvpwstest-03.txt>\n\n      This document defines methodologies for benchmarking EVPN-VPWS\n      performance.EVPN-VPWS is defined in RFC 8214, and is being deployed\n      in Service Provider networks.Specifically this document defines the\n      methodologies for benchmarking EVPN-VPWS Scale convergence, Fail\n      over,Core isolation,high availability and longevity.\n\n  "Discovery of OSCORE Groups with the CoRE Resource Directory", Marco\n  Tiloca, Christian Amsuess, Peter van der Stok, 2019-11-04,\n  <draft-tiloca-core-oscore-discovery-04.txt>\n\n      Group communication over the Constrained Application Protocol (CoAP)\n      can be secured by means of Group Object Security for Constrained\n      RESTful Environments (Group OSCORE).  At deployment time, devices may\n      not know the exact OSCORE groups to join, the respective Group\n      Manager, or other information required to perform the joining\n      process.  This document describes how a CoAP endpoint can use\n      descriptions and links of resources registered at the CoRE Resource\n      Directory to discover OSCORE groups and to acquire information for\n      joining them through the respective Group Manager.  A given OSCORE\n      group may protect multiple application groups, which are separately\n      announced in the Resource Directory as sets of endpoints sharing a\n      pool of resources.  This approach is consistent with, but not limited\n      to, the joining of OSCORE groups based on the ACE framework for\n      Authentication and Authorization in constrained environments.\n\n  "The Mercure Protocol", Kevin Dunglas, 2019-08-27,\n  <draft-dunglas-mercure-04.txt>\n\n      Mercure is a protocol enabling the pushing of data updates to web\n      browsers and other HTTP clients in a fast, reliable and battery-\n      efficient way.  It is especially useful for publishing real-time\n      updates of resources served through web APIs to reactive web and\n      mobile apps.\n\n  "YANG Model for Transmission Control Protocol (TCP) Configuration", Michael\n  Scharf, Vishal Murgai, Mahesh Jethanandani, 2019-11-04,\n  <draft-scharf-tcpm-yang-tcp-03.txt>\n\n      This document specifies a YANG model for TCP on devices that are\n      configured by network management protocols.  The YANG model defines\n      groupings for fundamental parameters that can be modified in many TCP\n      implementations.  The model includes definitions from YANG Groupings\n      for TCP Client and TCP Servers (I-D.ietf-netconf-tcp-client-server).\n      The model is NMDA (RFC 8342) compliant.\n\n  "The RFC Series and RFC Editor", Russ Housley, Leslie Daigle, 2019-10-30,\n  <draft-ietf-iasa2-rfc4844-bis-05.txt>\n\n      This document describes the framework for an RFC Series and an RFC\n      Editor function that incorporate the principles of organized\n      community involvement and accountability that has become necessary as\n      the Internet technical community has grown, thereby enabling the RFC\n      Series to continue to fulfill its mandate.\n      \n      Cover Note:\n      \n      {{ RFC Editor: Please remove this cover note prior to publication. }}\n      \n      The IASA2 WG asks the IAB to publish this replacement for RFC 4844.\n      The document is changed for alignment with the new structure for the\n      IETF Administrative Support Activity (IASA), eliminating all\n      references to the IETF Administrative Oversight Committee (IAOC).\n\n  "Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress\n  Peer engineering Segment Identifiers (SIDs) with MPLS Data Planes",\n  Shraddha Hegde, Kapil Arora, Mukul Srivastava, Samson Ninan, 2019-11-02,\n  <draft-hegde-mpls-spring-epe-oam-03.txt,.pdf>\n\n      Egress Peer Engineering is an application of Segment Routing to solve\n      the problem of egress peer selection.  The SR-based BGP-EPE solution\n      allows a centralized (Software Defined Network, SDN)controller to\n      program any egress peer.  The EPE solution requires a node to program\n      PeerNodeSID, PeerAdjSID, PeerSetSID as described in\n      [I-D.ietf-spring-segment-routing-central-epe].  This document\n      provides new sub-TLVs for EPE SIDs that would be used in Target stack\n      TLV (Type 1) as defined in [RFC8029] for the EPE SIDs.\n\n  "Diffserv to QCI Mapping", Jerome Henry, Tim Szigeti, 2019-10-14,\n  <draft-henry-tsvwg-diffserv-to-qci-02.txt>\n\n      As communication devices become more hybrid, smart devices include\n      more media-rich communication applications, and the boundaries\n      between telecommunication and other applications becomes less clear.\n      Simultaneously, as the end-devices become more mobile, application\n      traffic transits more often between enterprise networks, the\n      Internet, and cellular telecommunication networks, sometimes using\n      simultaneously more than one path and network type.  In this context,\n      it is crucial that quality of service be aligned between these\n      different environments.  However, this is not always the case by\n      default, and cellular communication networks use a different QoS\n      nomenclature from the Internet and enterprise networks.  This\n      document specifies a set of 3rd Generation Partnership Project (3GPP)\n      Quality of Service (QoS) Class Identifiers (QCI) to Differentiated\n      Services Code Point (DSCP) mappings, to reconcile the marking\n      recommendations offered by the 3GPP with the recommendations offered\n      by the IETF, so as to maintain a consistent QoS treatment between\n      cellular networks and the Internet.  This mapping can be used by\n      enterprises or implementers expecting traffic to flow through both\n      types of network, and wishing to align the QoS treatment applied to\n      one network under their control with the QoS treatment applied to the\n      other network.\n\n  "Basic YANG Model for Steering Client Services To Server Tunnels", Igor\n  Bryskin, Vishnu Beeram, Tarek Saad, Xufeng Liu, Young Lee, Aihua Guo,\n  2020-01-12, <draft-bryskin-teas-service-tunnel-steering-model-04.txt>\n\n      This document describes a YANG data model for managing pools of\n      transport tunnels and steering client services on them.\n\n  "Motivations and Design Choices of the Flexible Session Protocol", Jun-an,\n  Gao, 2019-10-15, <draft-gao-fsp-motivations-02.txt>\n\n      This document introduces the motivation to design the Flexible\n      Session Protocol which supports mobility and multihoming at the\n      transport layer. FSP is to avoid the routing scalability problem in\n      the IPv6 internetwork.\n      \n      The document serves to explain choices of design goals of FSP as\n      well.\n\n  "Operations, Administration, and Maintenance for MPLS-SR over IP", Gregory\n  Mirsky, 2019-10-22, <draft-mirsky-mpls-oam-mpls-sr-ip-03.txt>\n\n      Segment routing uses source routing paradigm to traffic engineering\n      by specifying segments a packet traverses through the network.  MPLS\n      Segment Routing applies that paradigm to an MPLS data plane-based\n      networks.  SR-MPLS over IP uses MPLS label stack as a source routing\n      instruction set and uses IP encapsulation/tunneling such as MPLS-in-\n      UDP as defined in RFC 7510 to realize a source routing mechanism\n      across MPLS, IPv4, and IPv6 data planes.  This document describes\n      Operations, Administration, and Maintenance operations in SR-MPLS\n      over IP environment.\n\n  "DetNet QoS Policy", Quan Xiong, Yu jinghai, Peng Liu, Fengwei Qin,\n  2019-11-01, <draft-xiong-detnet-qos-policy-02.txt>\n\n      This document proposes a Quality of Service (QoS) policy to apply\n      Differentiated Services (DiffServ) model for Deterministic Networking\n      (DetNet) and defines a DetNet DiffServ mechanism including DetNet IP\n      and MPLS encapsulation.\n\n  "DetNet QoS Yang", Quan Xiong, Yufang Han, Fengwei Qin, Peng Liu,\n  2019-11-01, <draft-xiong-detnet-qos-yang-02.txt>\n\n      This document defines a YANG data model for Deterministic Networking\n      (DetNet) Quality of Service (QoS) based on the Differentiated\n      Services (DiffServ) model.\n\n  "Postcard-based On-Path Flow Data Telemetry", Haoyu Song, Tianran Zhou,\n  Zhenbin Li, Jongyoon Shin, Kyungtae Lee, 2019-10-29,\n  <draft-song-ippm-postcard-based-telemetry-06.txt>\n\n      The Postcard-Based Telemetry (PBT) allows network OAM applications to\n      directly collect and export telemetry data about any user packet at\n      each node on the forwarding path.  PBT has two variations, PBT-I and\n      PBT-M.  PBT-I requires inserting an instruction header to user\n      packets to guide the data collection.  An implementation of PBT-I is\n      the IOAM Direct Export option described in\n      [I-D.ioamteam-ippm-ioam-direct-export].  In contrast, PBT-M only\n      marks the user packets or configure the flow filter to invoke the\n      data collection and postcard export.  PBT complements IOAM trace\n      option by addressing several specific implementation and deployment\n      challenges.\n\n  "BATS Coding Scheme for Multi-hop Data Transport", Shenghao Yang, Xuan\n  Huang, Raymond Yeung, John Zao, 2019-11-16, <draft-yang-nwcrg-bats-02.txt>\n\n      This document describes a BATS coding scheme for communication\n      through multi-hop networks.  BATS code is a class of efficient linear\n      network coding scheme with a matrix generalization of fountain codes\n      as the outer code, and batch-based linear network coding as the inner\n      code.\n\n  "Tethering A BIER Router To A BIER incapable Router", Zhaohui Zhang, Nils\n  Warnke, IJsbrand Wijnands, Daniel Awduche, 2019-10-01,\n  <draft-zzhang-bier-tether-04.txt>\n\n      This document specifies optional procedures to optimize the handling\n      of Bit Index Explicit Replication (BIER) incapable routers, by\n      attaching (tethering) a BIER router to a BIER incapable router.\n\n  "Path Segment for SRv6 (Segment Routing in IPv6)", Cheng Li, Weiqiang\n  Cheng, Mach Chen, Dhruv Dhody, Zhenbin Li, Jie Dong, Rakesh Gandhi,\n  2019-11-04, <draft-li-spring-srv6-path-segment-04.txt>\n\n      Segment Routing (SR) allows for a flexible definition of end-to-end\n      paths by encoding paths as sequences of sub-paths, called "segments".\n      Segment routing architecture can be implemented over an MPLS data\n      plane as well as an IPv6 data plane.\n      \n      Further, Path Segment has been defined in order to identify an SR\n      path in SR-MPLS networks, and used for various use-cases such as end-\n      to-end SR Path Protection and Performance Measurement (PM) of an SR\n      path.  Similar to SR-MPLS, this document defines the Path Segment in\n      SRv6 networks in order to identify an SRv6 path.\n\n  "Enhanced Alternate Marking Method", Tianran Zhou, Giuseppe Fioccola,\n  Zhenbin Li, Shinyoung Lee, Mauro Cociglio, 2019-10-31,\n  <draft-zhou-ippm-enhanced-alternate-marking-04.txt>\n\n      This document defines data fields for the alternate marking with\n      enough space.  The main idea is that more information can be\n      considered within the alternate marking field to facilitate the\n      efficiency and ease the deployment.  The definition aims to be\n      general, even if for some protocols there can be dedicated solutions.\n\n  "PCEP Procedures and Protocol Extensions for Using PCE as a Central\n  Controller (PCECC) for SRv6", Mahendra Negi, Zhenbin Li, Xuesong Geng,\n  2019-08-22, <draft-dhody-pce-pcep-extension-pce-controller-srv6-02.txt>\n\n      The Path Computation Element (PCE) is a core component of Software-\n      Defined Networking (SDN) systems.  It can compute optimal paths for\n      traffic across a network and can also update the paths to reflect\n      changes in the network or traffic demands.\n      \n      PCE was developed to derive paths for MPLS Label Switched Paths\n      (LSPs), which are supplied to the head end of the LSP using the Path\n      Computation Element Communication Protocol (PCEP).  But SDN has a\n      broader applicability than signaled (G)MPLS traffic-engineered (TE)\n      networks, and the PCE may be used to determine paths in a range of\n      use cases.  PCEP has been proposed as a control protocol for use in\n      these environments to allow the PCE to be fully enabled as a central\n      controller.\n      \n      A PCE-based central controller (PCECC) can simplify the processing of\n      a distributed control plane by blending it with elements of SDN and\n      without necessarily completely replacing it.  This document specifies\n      the procedures and PCEP protocol extensions when a PCE-based\n      controller is also responsible for configuring the forwarding actions\n      on the routers for Segment Routing in IPv6 (SRv6), in addition to\n      computing the SRv6 paths for packet flows and telling the edge\n      routers what instructions to attach to packets as they enter the\n      network.\n\n  "PCEP Procedures and Protocol Extensions for Using PCE as a Central\n  Controller (PCECC) for P2MP LSPs", Mahendra Negi, Zhenbin Li, Xuesong Geng,\n  2019-08-22, <draft-dhody-pce-pcep-extension-pce-controller-p2mp-02.txt>\n\n      The Path Computation Element (PCE) is a core component of Software-\n      Defined Networking (SDN) systems.  It can compute optimal paths for\n      traffic across a network and can also update the paths to reflect\n      changes in the network or traffic demands.\n      \n      The PCE has been identified as an appropriate technology for the\n      determination of the paths of point- to-multipoint (P2MP) TE Label\n      Switched Paths (LSPs).\n      \n      PCE was developed to derive paths for MPLS P2MP LSPs, which are\n      supplied to the head end (root) of the LSP using PCEP.  PCEP has been\n      proposed as a control protocol to allow the PCE to be fully enabled\n      as a central controller.\n      \n      A PCE-based central controller (PCECC) can simplify the processing of\n      a distributed control plane by blending it with elements of SDN and\n      without necessarily completely replacing it.  Thus, the P2MP LSP can\n      be calculated/setup/initiated and the label forwarding entries can\n      also be downloaded through a centralized PCE server to each network\n      devices along the P2MP path while leveraging the existing PCE\n      technologies as much as possible.\n      \n      This document specifies the procedures and PCEP protocol extensions\n      for using the PCE as the central controller for P2MP TE LSP.\n\n  "Architecture for Use of BGP as Central Controller", Huaimo Chen, Shunwan\n  Zhuang, Zhenbin Li, 2019-10-24, <draft-cth-rtgwg-bgp-control-03.txt>\n\n      BGP is a core part of a network including Software-Defined Networking\n      (SDN) system.  It has the traffic engineering information on the\n      network topology and can compute optimal paths for a given traffic\n      flow across the network.\n      \n      This document describes some reference architectures for BGP as a\n      central controller.  A BGP-based central controller can simplify the\n      operations on the network and use network resources efficiently for\n      providing services with high quality.\n\n  "SRv6 Compatibility with Legacy Devices", Hui Tian, Feng Zhao, Chongfeng\n  Xie, Tong Li, Jichun Ma, Shuping Peng, Zhenbin Li, Jim Guichard,\n  2020-01-08, <draft-peng-spring-srv6-compatibility-02.txt>\n\n      When deploying SRv6 on legacy devices, there are some compatibility\n      challenges that must be addressed such as the support for SRH\n      processing.\n      \n      This document identifies some of the major challenges, and provides\n      solutions that can mitigate those challenges and smooth the migration\n      towards SRv6 deployment.\n\n  "SR-TE Path Midpoint Protection", Zhibo Hu, Huaimo Chen, Junda Yao, Chris\n  Bowers, Yongqing Zhu, 2020-01-07,\n  <draft-hu-spring-segment-routing-proxy-forwarding-07.txt>\n\n      Segment Routing Traffic Engineering (SR-TE) supports the creation of\n      explicit paths using segment lists containing adjacency-SIDs, node-\n      SIDs, anycast-SIDs, and binding-SIDs.  When the segment list defining\n      an SR-TE path contains a node-SID, and the node fails, the network\n      may no longer be able to properly forward traffic on that SR-TE path.\n      [I-D.bashandy-rtgwg-segment-routing-ti-lfa] and\n      [I-D.hegde-spring-node-protection-for-sr-te-paths] describe a\n      mechanism that allows local repair actions on the direct neighbors of\n      the failed node to temporarily route traffic to the node immediately\n      following the failed node on the SR-TE path segment list.  However,\n      once the IGP shortest paths have converged, the local repair\n      mechanism is no longer sufficient to continue forwarding traffic\n      using the original segment list of the SR-TE path, since the non-\n      neighbors of the failed node will no longer have a route to reach the\n      failed node.  This document describes a mechanism that allows traffic\n      to continue to be forwarded on an SR-TE path for an extended period\n      of time after the failure of a node used in the path\'s segment list.\n\n  "EtherType Protocol Identification of In-situ OAM Data", Brian Weis, Frank\n  Brockners, Craig Hill, Shwetha Bhandari, Vengada Govindan, Carlos\n  Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Aviv\n  Kfir, Barak Gafni, Petr Lapukhov, Mickey Spiegel, 2019-09-11,\n  <draft-weis-ippm-ioam-eth-02.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in the packet while the packet\n      traverses a path between two points in the network.  This document\n      defines an EtherType that identifies IOAM data fields as being the\n      next protocol in a packet, and a header that encapsulates the IOAM\n      data fields.\n\n  "YANG Versioning Solution Overview", Robert Wilton, 2019-11-04,\n  <draft-verdt-netmod-yang-solutions-02.txt>\n\n      This document gives a brief overview of the different drafts that\n      comprise a full solution to the YANG versioning requirements draft.\n      The purpose of this draft is to help readers understand how the\n      discrete parts of the YANG versioning solution fit together during\n      working group development of the solution drafts.\n\n  "SRIFT: Segment Routing In Fat Trees", Zhaohui Zhang, Jeff Tantsura, Don\n  Fedyk, 2019-11-04, <draft-zzhang-rift-sr-02.txt>\n\n      This document specifies signaling procedures for Segment Routing\n      [RFC8402] with RIFT.  Each node\'s loopback address, Segment Routing\n      Global Block (SRGB) and Node Segment Identifier (SID), which must be\n      unique within the SR domain and are typically assigned by SR\n      controllers or management, are distributed southbound from the Top Of\n      Fabric (TOF) nodes via the Key-Value distribution mechanism, so that\n      each node can compute how to reach a node represented by the topmost\n      Node SIDs .  For an ingress node to send SR traffic to another node\n      via an explicit path, an SR controller signals the corresponding\n      label stack to the ingress node so that the ingress node can send\n      packets accordingly.\n\n  "Flowspec Indirection-id Redirect for SRv6", Gunter Van de Velde, Keyur\n  Patel, Zhenbin Li, Huaimo Chen, 2020-01-06,\n  <draft-ietf0-idr-srv6-flowspec-path-redirect-03.txt>\n\n      This document defines extensions to "FlowSpec Redirect to\n      indirection-id Extended Community" for SRv6.  This extended community\n      can trigger advanced redirection capabilities to flowspec clients for\n      SRv6.  When activated, this flowspec extended community is used by a\n      flowspec client to retrieve the corresponding next-hop and encoding\n      information within a localised indirection-id mapping table.\n      \n      The functionality detailed in this document allows a network\n      controller to decouple the BGP flowspec redirection instruction from\n      the operation of the available paths.\n\n  "In-situ Flow Information Telemetry", Haoyu Song, Fengwei Qin, Huanan Chen,\n  Jaewhan Jin, Jongyoon Shin, 2019-12-31,\n  <draft-song-opsawg-ifit-framework-10.txt>\n\n      As networks increase in scale and network operations become more\n      sophisticated, traditional Operation, Administration and Maintenance\n      (OAM) methods, which include proactive and reactive techniques,\n      running in active and passive modes, become more susceptible to\n      measurement accuracy and misconfiguration errors.  With the advent of\n      programmable data-plane, emerging on-path telemetry techniques\n      provide unprecedented flow insight and realtime notification of\n      network issues.\n      \n      This document enumerates the key deployment challenges for flow-\n      oriented on-path telemetry techniques, especially in carrier operator\n      networks.  To address these issues, a high-level framework, In-situ\n      Flow Information Telemetry (iFIT), is outlined. iFIT includes several\n      essential functional components that can be materialized and\n      assembled to implement a complete solution for on-path telemetry.\n      \n      This informational document aims to clarify the problem domain, and\n      summarize the best practices and sensible system design\n      considerations.  The iFIT framework helps to guide the analysis on\n      the current standard status and gaps, and motivate new works to\n      complete the ecosystem.  It also helps to inspire innovative network\n      telemetry applications supporting advanced network operations.  As a\n      reference and open framework, iFIT does not specify the\n      implementation of the components and the interfaces between the\n      components.  The compliance with iFIT framework is not mandatory for\n      telemetry applications either.\n\n  "YANG Data Model for OSPF SRv6", Zhibo Hu, Kamran Raza, Yingzhen Qu, Jiajia\n  Dong, 2019-11-04, <draft-hu-lsr-ospf-srv6-yang-01.txt>\n\n      This document defines a YANG data model that can be used to configure\n      and manage OSPFv3 SRv6 [I-D.li-ospf-ospfv3-srv6-extensions].\n\n  "CBOR Profile of X.509 Certificates", Shahid Raza, Joel Hoglund, Goeran\n  Selander, John Mattsson, Martin Furuhed, 2019-12-20,\n  <draft-raza-ace-cbor-certificates-03.txt>\n\n      This document specifies a CBOR encoding and profiling of X.509 public\n      key certificate suitable for Internet of Things (IoT) deployments.\n      The full X.509 public key certificate format and commonly used ASN.1\n      encoding is overly verbose for constrained IoT environments.\n      Profiling together with CBOR encoding reduces the certificate size\n      significantly with associated known performance benefits.\n      \n      The CBOR certificates are compatible with the existing X.509\n      standard, enabling the use of profiled and compressed X.509\n      certificates without modifications in the existing X.509 standard.\n\n  "YANG Data Models for the IP Flow Information Export (IPFIX) Protocol,\n  Packet Sampling (PSAMP) Protocol, and Bulk Data Export", Joey Boyd, Marta\n  Seda, 2019-11-04, <draft-boydseda-ipfix-psamp-bulk-data-yang-model-02.txt>\n\n      This document defines a flexible, modular YANG model for packet\n      sampling (PSAMP) and bulk data collection and export via the IPFIX\n      protocol.  This new model is an alternative to the model defined in\n      RFC 6728, "Configuration Data Model for the IP Flow Information\n      Export (IPFIX) and Packet Sampling (PSAMP) Protocols".  All\n      functionality modeled in RFC 6728 has been carried over to this new\n      model.\n      \n      The YANG data model in this document conforms to the Network\n      Management Datastore Architecture (NMDA) defined in RFC 8342.\n      \n      This document obsoletes RFC 6728 (if approved).\n\n  "OAM for Service Programming with Segment Routing", Zafar Ali, Clarence\n  Filsfils, Nagendra Kumar, Carlos Pignataro, Francois Clad,\n  faiqbal@cisco.com, Xiaohu Xu, 2019-11-01,\n  <draft-ali-spring-sr-service-programming-oam-02.txt>\n\n      This document defines the Operations, Administrations and Maintenance\n      (OAM) for service programming in SR-enabled MPLS and IP networks.\n\n  "Segment Routing Header encapsulation for In-situ OAM Data", Zafar Ali,\n  Rakesh Gandhi, Clarence Filsfils, Frank Brockners, Nagendra Kumar, Carlos\n  Pignataro, Cheng Li, Mach Chen, Gaurav Dawra, 2019-11-03,\n  <draft-ali-spring-ioam-srv6-02.txt>\n\n      OAM and PM information from the SR endpoints can be piggybacked in\n      the data packet.  The OAM and PM information piggybacking in the data\n      packets is also known as In-situ OAM (IOAM). IOAM records\n      operational and telemetry information in the data packet while the\n      packet traverses a path between two points in the network.  This\n      document defines how IOAM data fields are transported as part of the\n      Segment Routing with IPv6 data plane (SRv6) header.\n\n  "IPv6 Formal Anycast Addresses and Functional Anycast Addresses", Mark\n  Smith, 2019-11-03, <draft-smith-6man-form-func-anycast-addresses-01.txt>\n\n      Currently, IPv6 anycast addresses are chosen from within the existing\n      IPv6 unicast address space, with the addresses nominated as anycast\n      addresses through configuration.  An alternative scheme would be to\n      have a special class of addresses for use as anycast addresses.  This\n      memo proposes a distinct general anycast addressing class for IPv6,\n      and a more specific scheme for functional anycast addresses.\n\n  "Private Discovery", Bob Bradley, 2019-10-18,\n  <draft-bradley-dnssd-private-discovery-02.txt>\n\n      This document specifies a mechanism for advertising and discovering\n      in a private manner.\n\n  "Benchmarks and Methods for Multihomed EVPN", Alfred Morton, Jim Uttaro,\n  2019-11-04, <draft-morton-bmwg-multihome-evpn-03.txt>\n\n      Fundamental Benchmarking Methodologies for Network Interconnect\n      Devices of interest to the IETF are defined in RFC 2544.  Key\n      benchmarks applicable to restoration and multi-homed sites are in RFC\n      6894.  This memo applies these methods to Multihomed nodes\n      implemented on Ethernet Virtual Private Networks (EVPN).\n\n  "RPKI Route Origin Validation State Unverified", Oliver Borchert, Doug\n  Montgomery, 2019-08-26,\n  <draft-borchert-sidrops-rpki-state-unverified-02.txt>\n\n      In case operators decide not to evaluate BGP route prefixes according\n      to RPKI route origin validation (ROV), none of the available states\n      as specified in RFC 6811 do properly represent this decision. This\n      document introduces "Unverified" as well-defined validation state\n      which allows to properly identify route prefixes as not evaluated\n      according to RPKI route origin validation.\n\n  "BGPsec Validation State Unverified", Oliver Borchert, Doug Montgomery,\n  2019-08-26, <draft-borchert-sidrops-bgpsec-state-unverified-02.txt>\n\n      In case operators decide to delay BGPsec path validation, none of the\n      available states do properly represent this decision. This document\n      introduces "Unverified" as a well-defined validation state which\n      allows to properly identify a non-evaluated BGPsec routes as not\n      verified.\n\n  "Remote Attestation Procedures Architecture", Henk Birkholz, Monty Wiseman,\n  Hannes Tschofenig, Ned Smith, Michael Richardson, 2019-11-04,\n  <draft-birkholz-rats-architecture-03.txt>\n\n      An entity (a relying party) requires a source of truth and evidence\n      about a remote peer to assess the peer\'s trustworthiness.  The\n      evidence is typically a believable set of claims about its host,\n      software or hardware platform.  This document describes an\n      architecture for such remote attestation procedures (RATS).\n\n  "The Standards on a Cloud Service Framework and Protocol for Construction,\n  Migration, Deployment,and Publishing of Internet-Oriented Scalable Web\n  Software Systems in Non-Programming Mode", Can Yang, Shiying Pan, Haibo\n  Sun, Kemin Qu, Guoqiang Han, 2019-10-23,\n  <draft-yangcan-core-web-software-built-in-cloud-02.txt,.pdf>\n\n      This draft mainly focuses on the scalable architecture and publishing\n      protocol standard of REST-based SAAS cloud model Web software in non-\n      programming mode, stipulates the data structure pattern and data\n      exchange protocol for the construction and release of REST-based\n      scalable Web cloud service software systems.  Using the standardized\n      framework and protocol, users can easily and quickly design their own\n      software systems in the cloud, transfer and release data, which may\n      make conventional software development so ease to improve the\n      efficiency of complex database construction and server management.\n      Without having to write codes under the standard framework, users can\n      get consistent style background to create service, rapidly develop\n      web application systems with the function of standard data management\n      and data maintenance, and directly publish the software system to the\n      end users of the Internet for access and use.  And provide RESTful\n      APIs to facilitate external access to required service resources.\n      The framework can thus greatly shorten the software development life\n      cycle, and save a great deal of development cost and maintenance\n      overhead.\n\n  "Uberlay Interconnection of Multiple LISP overlays", Victor Moreno, Dino\n  Farinacci, Alberto Rodriguez-Natal, Marc Portoles-Comeras, Fabio Maino,\n  Sanjay Hooda, Satish Kondalam, 2019-11-18,\n  <draft-moreno-lisp-uberlay-02.txt>\n\n      This document describes the use of the Locator/ID Separation Protocol\n      (LISP) to interconnect multiple disparate and independent network\n      overlays by using a transit overlay.  The transit overlay is referred\n      to as the "uberlay" and provides connectivity and control plane\n      abstraction between different overlays.  Each network overlay may use\n      different control and data plane approaches and may be managed by a\n      different organization.  Structuring the network into multiple\n      network overlays enables the interworking of different overlay\n      approaches to data and control plane methods.  The different network\n      overlays are autonomous from a control and data plane perspective,\n      this in turn enables failure survivability across overlay domains.\n      This document specifies the mechanisms and procedures for the\n      distribution of control plane information across overlay sites and in\n      the uberlay as well as the lookup and forwarding procedures for\n      unicast and multicast traffic within and across overlays.  The\n      specification also defines the procedures to support inter-overlay\n      mobility of EIDs and their integration with the intra-overlay EID\n      mobility procedures defined in draft-ietf-lisp-eid-mobility.\n\n  "Realm Crossover for SASL and GSS-API via Diameter", Rick van Rein,\n  2020-01-21, <draft-vanrein-diameter-sasl-03.txt>\n\n      SASL and GSS-API are used for authentication in many application\n      protocols.  This specification extends them to allow credentials of a\n      home realm to be used against external services.  To this end, it\n      introduces end-to-end encryption for SASL that is safe to relay to\n      the client\'s home realm.\n\n  "Multiple Layer Resource Optimization for Optical as a Service", Hui Yang,\n  Kaixuan Zhan, Ao Yu, Qiuyan Yao, Jie Zhang, 2019-10-28,\n  <draft-multiple-layer-resource-optimization-02.txt>\n\n      We have established a neural network model optimized by adaptive\n      artificial fish swarm algorithm.  Then we propose a novel multi-path\n      pre-reserved resource allocation strategy to increase resource\n      utilization.  The results prove the effectiveness of our method.\n\n  "Multi-dimensional Resource Aggregation in 5G Optical Fronthaul Networks",\n  Hui Yang, Yiqian Liu, Jie Zhang, Ao Yu, Qiuyan Yao, 2019-10-29,\n  <draft-multi-dimensional-resource-aggregation-02.txt>\n\n      We propose a resource assignment scheme based on multi-dimensional\n      resource aggregation in 5G optical fronthaul networks.  This new\n      scheme can suit to the higher demand of flexible resource allocation\n      of the fronthaul in the new 5G scenario.\n\n  "Chacha derived AEAD algorithms in JSON Object Signing and Encryption\n  (JOSE)", Guillaume Amringer, 2020-01-09, <draft-amringer-jose-chacha-02.txt>\n\n      This document defines how to use the AEAD algorithms\n      "AEAD_XCHACHA20_POLY1305" and "AEAD_CHACHA20_POLY1305" from [RFC8439]\n      and [I-D.irtf-cfrg-xchacha] in JSON Object Signing and Encryption\n      (JOSE).\n\n  "Security Classes for IoT devices", Pascal Urien, 2019-11-22,\n  <draft-urien-lwig-security-classes-02.txt>\n\n      This draft attempts to define security classes for constraint IoT\n      devices. A device security is characterized by five Boolean security\n      attributes: one time programmable memory (OTP), firmware loader\n      (FLD), secure firmware loader (FLD-SEC), tamper resistant key (TRT-\n      KEY) and diversified key (DIV-KEY).\n      \n      This leads to the definition of 6 classes of devices, embedding or\n      not OTP resource, whose security increases with the class number (0\n      to 5). The suffix + indicates OTP availability.\n\n  "Considerations for Large Authoritative DNS Servers Operators", Giovane\n  Moura, Wes Hardaker, John Heidemann, Marco Davids, 2019-10-01,\n  <draft-moura-dnsop-authoritative-recommendations-06.txt>\n\n      This document summarizes recent research work exploring Domain Name\n      System (DNS) configurations and offers specific, tangible\n      considerations to operators for configuring authoritative servers.\n      \n      It is possible that the considerations presented in this document\n      could be applicable in a wider context, such as for any stateless/\n      short-duration, anycasted service.\n      \n      This document is not an IETF consensus document: it is published for\n      informational purposes.\n\n  "MessageVortex Protocol", Martin Gwerder, 2019-09-10,\n  <draft-gwerder-messagevortexmain-03.txt>\n\n      The MessageVortex (referred to as Vortex) protocol achieves different\n      degrees of anonymity, including sender, receiver, and third-party\n      anonymity, by specifying messages embedded within existing transfer\n      protocols, such as SMTP or XMPP, sent via peer nodes to one or more\n      recipients.\n      \n      The protocol outperforms others by decoupling the transport from the\n      final transmitter and receiver.  No trust is placed into any\n      infrastructure except for that of the sending and receiving parties\n      of the message.  The creator of the routing block has full control\n      over the message flow.  Routing nodes gain no non-obvious knowledge\n      about the messages even when collaborating.  While third-party\n      anonymity is always achieved, the protocol also allows for either\n      sender or receiver anonymity.\n\n  "Retransmit bit for SCTP DATA, I-DATA and SACK", Maksim Proshin,\n  2019-12-02, <draft-proshin-tsvwg-sctp-rtx-bit-02.txt>\n\n      This document defines a method which helps an SCTP sender to\n      understand when a received SACK acknowledges the original\n      transmission of a TSN or its retransmission.  It is done by\n      specifying a new bit, called Retransmit bit (R-bit), in the header of\n      DATA, I-DATA and SACK chunks.  The bit is used when a TSN is\n      retransmitted and returned back in the acknowledgement.  This\n      document updates [RFC4960] if approved.\n\n  "Multicast DF Election for EVPN based on bandwidth or quantity", Yisong\n  Liu, Mike McBride, 2019-11-26,\n  <draft-liu-bess-evpn-mcast-bw-quantity-df-election-01.txt>\n\n      Ethernet Virtual Private Network (EVPN, RFC7432) is becoming\n      prevalent in Data Centers, Data Center Interconnect (DCI) and\n      Service Provider VPN applications. When multi-homing from a CE to\n      multiple PEs, including links in an EVPN instance on a given\n      Ethernet Segment, in an all-active redundancy mode, [RFC7432]\n      describes a basic mechanism to elect a Designated Forwarder (DF),\n      and [RFC8584] improves basic DF election by a HRW algorithm. [I-\n      D.ietf-bess-evpn-per-mcast-flow-df-election] enhances the HRW\n      algorithm for the multicast flows to perform DF election at the\n      granularity of (ESI, VLAN, Mcast flow). This document specifies a\n      new algorithm, based on multicast bandwidth utilization and\n      multicast state quantity, in order for the multicast flows to elect\n      a DF.\n\n  "Stateful PCE for SR-MPLS Inter-domain", Quan Xiong, Gregory Mirsky,\n  fangwei hu, Weiqiang Cheng, 2019-10-23,\n  <draft-xiong-pce-stateful-pce-sr-inter-domain-02.txt>\n\n      This document proposes a solution to perform the Segment Routing with\n      MPLS data plane (SR-MPLS) inter-domain path computation and\n      initiation with stateful PCEs and the use of Path Segments.\n\n  "Flooding Topology Computation Algorithm", Huaimo Chen, Dean Cheng, Mehmet\n  Toy, Yi Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, Lei Liu, 2019-10-17,\n  <draft-cc-lsr-flooding-reduction-07.txt>\n\n      This document proposes an algorithm for a node to compute a flooding\n      topology, which is a subgraph of the complete topology per underline\n      physical network.  When every node in an area automatically\n      calculates a flooding topology by using a same algorithm and floods\n      the link states using the flooding topology, the amount of flooding\n      traffic in the network is greatly reduced.  This would reduce\n      convergence time with a more stable and optimized routing\n      environment.\n\n  "Stitching LSP Association", Quan Xiong, Gregory Mirsky, fangwei hu,\n  Weiqiang Cheng, 2019-10-23, <draft-hu-pce-stitching-lsp-association-02.txt>\n\n      The Path Computation Element Communication Protocol (PCEP) provides\n      mechanisms for Path Computation Elements (PCEs) to perform path\n      computations in response to Path Computation Clients (PCCs) requests.\n      [I-D.ietf-pce-association-group] proposed an association mechanism\n      for a set of LSPs.\n      \n      This document defines the stitching LSP association type and\n      stitching LSP association TLV for the inter-domain scenairo.\n\n  "YANG Packages", Robert Wilton, 2019-10-24,\n  <draft-rwilton-netmod-yang-packages-02.txt>\n\n      This document defines YANG packages, a versioned organizational\n      structure holding a set of related YANG modules, that collectively\n      define a YANG schema.  It describes how YANG instance data documents\n      are used to define YANG packages, and how the YANG library\n      information published by a server can be augmented with packages\n      related information.\n\n  "The practice of NFV decoupling test", louie long, Yang Song, Zhijun Tang,\n  2019-12-16, <draft-long-nfvrg-nfv-decoupling-test-02.txt>\n\n      This document mainly introduces the practice of NFV decoupling test.\n      Based on the product development situation of the current vendors,\n      the decoupling test is carried out between NFVI&VIM, VNFM&VNF and\n      NFVO.  Through a series of tests to explore some of the problems\n      encountered in the current stage of NFV decoupling testing, provide\n      ideas for the subsequent development of NFV products.\n\n  "Premium Domain Fee Report", Tobias Sattler, Roger Carney, 2019-09-26,\n  <draft-sattler-premium-domain-fee-report-03.txt>\n\n      This document describes the content of a Premium Domain Fee Report\n      based on the Report Structure and delivered by the Reporting\n      Repository.\n\n  "Domain Inventory Report", Tobias Sattler, 2019-10-15,\n  <draft-sattler-domain-inventory-report-04.txt>\n\n      This document describes the content of a Domain Inventory Report\n      based on the Report structure and delivered by the Reporting\n      Repository.\n\n  "Unavailable Domain Report", Tobias Sattler, Roger Carney, 2019-09-26,\n  <draft-sattler-unavailable-domain-report-03.txt>\n\n      This document describes the content of an Unavailable Domain Report\n      based on the Report Structure and delivered by the Reporting\n      Repository.\n\n  "Cryptographic Hyperlinks", Manu Sporny, 2019-11-18,\n  <draft-sporny-hashlink-04.txt>\n\n      When using a hyperlink to fetch a resource from the Internet, it is\n      often useful to know if the resource has changed since the data was\n      published.  Cryptographic hashes, such as SHA-256, are often used to\n      determine if published data has changed in unexpected ways.  Due to\n      the nature of most hyperlinks, the cryptographic hash is often\n      published separately from the link itself.  This specification\n      describes a data model and serialization formats for expressing\n      cryptographically protected hyperlinks.  The mechanisms described in\n      the document enables a system to publish a hyperlink in a way that\n      empowers a consuming application to determine if the resource\n      associated with the hyperlink has changed in unexpected ways.\n\n  "Generic Multi-Access (GMA) Convergence Encapsulation Protocols", Jing Zhu,\n  Satish Kanugovi, 2019-12-16, <draft-zhu-intarea-gma-05.txt>\n\n      Today, a device can be simultaneously connected to multiple\n      networks, e.g. Wi-Fi, LTE, 5G, and DSL. It is desirable to combine\n      them seamlessly to improve quality of experience. Such\n      optimization requires additional control information, e.g.\n      Sequence Number, in each (IP) data packet. This document presents\n      a new light-weight and flexible encapsulation protocol for this\n      need. The solution has been developed by the authors based on\n      their experiences in multiple standards bodies including the IETF\n      and 3GPP, is not an Internet Standard and does not represent the\n      consensus opinion of the IETF. This document will enable other\n      developers to build interoperable implementations.\n\n  "CoRE Resource Directory Extensions", Christian Amsuess, 2019-09-23,\n  <draft-amsuess-core-resource-directory-extensions-02.txt>\n\n      [ See Introduction ]\n\n  "Extended Security Considerations for the Automatic Certificate Management\n  Environment (ESecACME)", Tobias Fiebig, Kevin Borgolte, 2019-09-09,\n  <draft-fiebig-security-acme-01.txt>\n\n      Most Public Key Infrastructure X.509 (PKIX) certificates are issued\n      via the ACME protocol.  Recently, several attacks against domain\n      validation (DV) have been published, including IP-use-after-free and\n      (forced) on-path attacks.  These attacks can often be mitigated by\n      (selectively) requiring additional challenges, such as DNS\n      validation, proof of ownership of a prior certificate, and by being\n      more diligent in operating a certificate authority.  This document\n      provides a list of currently known attacks and describes mitigations\n      and operational procedures to prevent issuing a certificate to an\n      unauthorized party.\n\n  "Mathematical Mesh 3.0 Part VI: The Trust Mesh", Phillip Hallam-Baker,\n  2020-01-16, <draft-hallambaker-mesh-trust-04.txt>\n\n      This paper extends Shannon\'s concept of a \'work factor\' as applied to\n      evaluation of cryptographic algorithms to provide an objective\n      measure of the practical security offered by a protocol or\n      infrastructure design.  Considering the hypothetical work factor\n      based on an informed estimate of the probable capabilities of an\n      attacker with unknown resources provides a better indication of the\n      relative strength of protocol designs than the computational work\n      factor of the best-known attack.\n      \n      The social work factor is a measure of the trustworthiness of a\n      credential issued in a PKI based on the cost of having obtained the\n      credential through fraud at a certain point in time.  Use of the\n      social work factor allows evaluation of Certificate Authority based\n      trust models and peer to peer (Web of Trust) models to be evaluated\n      in the same framework.  The analysis demonstrates that both\n      approaches have limitations and that in certain applications, a\n      blended model is superior to either by itself.\n      \n      The final section of the paper describes a proposal to realize this\n      blended model using the Mathematical Mesh.\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html.\n\n  "Update to Additional Registered Clauses in SMTP Received Headers", John\n  Levine, 2019-07-30, <draft-levine-additional-registered-clauses-03.txt>\n\n      SMTP servers add Received: trace headers to mail messages to track\n      their progress This document updates the registration criteria for\n      Additional Registered Clauses in those headers to Expert Review, and\n      adds new clauses for Server Name Indication (SNI) and sending port\n      number (PORT).\n\n  "Reporting Repository", Neal McPherson, Tobias Sattler, 2019-10-15,\n  <draft-mcpherson-sattler-reporting-repository-03.txt>\n\n      This document describes a Reporting Repository used to provide\n      standardized Reports.\n\n  "Report Structure", Neal McPherson, Tobias Sattler, 2019-10-15,\n  <draft-mcpherson-sattler-report-structure-03.txt>\n\n      This document describes the default Report Structure for Reports\n      which can be provide via the Reporting Repository.\n\n  "Transaction Report", Neal McPherson, Tobias Sattler, 2019-10-15,\n  <draft-mcpherson-sattler-transaction-report-03.txt>\n\n      This document describes the content of a Transaction Report based on\n      the Report Structure and delivered by the Reporting Repository.\n\n  "Domain Drop List Report", Tobias Sattler, 2019-09-26,\n  <draft-sattler-domain-drop-list-report-02.txt>\n\n      This document describes the content of a Domain Drop List Report\n      based on the Report Structure and delivered by the Reporting\n      Repository.\n\n  "Contact Inventory Report", Tobias Sattler, 2019-10-15,\n  <draft-sattler-contact-inventory-report-03.txt>\n\n      This document describes the content of a Contact Inventory Report\n      based on the Report Structure and delivered by the Reporting\n      Repository.\n\n  "Probing IP Interfaces By Vendor Specific Identifiers", Manoj Nayak, Ron\n  Bonica, Rafik Puttur, 2019-08-17, <draft-nayak-intarea-probe-by-vfi-01.txt>\n\n      This document enhances the PROBE diagnostic tool so that it can\n      identify the probed interface by Vendor Specific Identifiers.\n      In order to achieve that goal, this document also extends the\n      Interface Identification Object.  The Interface Identification\n      Object is an ICMP Extension Object class.\n\n  "Network Slice Provision Models", Shunsuke Homma, Hidetaka Nishihara,\n  Takuya Miyasaka, A. Galis, Vishnu OV, Diego Lopez, Luis Contreras, Jose\n  Ordonez-Lucena, Pedro Martinez-Julia, Li Qiang, Reza Rokui, Laurent\n  Ciavaglia, Xavier de Foy, 2019-11-04,\n  <draft-homma-slice-provision-models-02.txt>\n\n      Network slicing is an approach to provide separate virtual network\n      based on service requirements, and it\'s a key feature of the 5G.\n      3GPP has standardized the specifications for network slicing in the\n      5GS, but there are still some problems for realization of end-to-end\n      network slices.  For complementing the lacks or expanding the\n      usability, several organizations are proceeding standardization.\n      However, the definitions and scopes of network slicing vary to some\n      degree from one organization to another.  This document provides\n      classification of provisioning models of network slice for clarifying\n      the differences on the definitions and scopes.\n\n  "Benchmarking Methodology for EVPN Multicasting", sudhin jacob, Vikram\n  Nagarajan, 2019-12-13, <draft-vikjac-bmwg-evpnmultest-03.txt>\n\n      This document defines methodologies for benchmarking IGMP proxy\n      performance over EVPN-VXLAN.  IGMP proxy over EVPN is defined in\n      draft-ietf-bess-evpn-IGMP-mld-proxy-02, and is being deployed in data\n      center networks.  Specifically this document defines the\n      methodologies for benchmarking IGMP proxy convergence, leave latency\n      Scale,Core isolation, high availability and longevity.\n\n  "Resource Discovery in Constrained RESTful Environments (CoRE) using the\n  Constrained RESTful Application Language (CoRAL)", Klaus Hartke,\n  2019-11-04, <draft-hartke-t2trg-coral-reef-03.txt>\n\n      This document explores how the Constrained RESTful Application\n      Language (CoRAL) might be used for two use cases in Constrained\n      RESTful Environments (CoRE): CoRE Resource Discovery, which allows a\n      client to discover the resources of a server given a host name or IP\n      address, and CoRE Resource Directory, which provides a directory of\n      resources on many servers.\n\n  "Receivers Guidance for Implementing Branded Indicators for Message\n  Identification (BIMI)", Alexander Brotman, Terry Zink, 2019-08-05,\n  <draft-brotman-ietf-bimi-guidance-01.txt>\n\n      This document is meant to assist receivers or other mailbox providers\n      by providing guidance to implementing Brand Indicators for Message\n      Identification (BIMI).  This document is a companion to the main BIMI\n      drafts which should first be consulted and reviewed.\n\n  "Credentials Provisioning and Management via EAP (EAP-CREDS)", Massimiliano\n  Pala, 2019-10-28, <draft-pala-eap-creds-05.txt>\n\n      With the increase number of devices, protocols, and applications that\n      rely on strong credentials (e.g., digital certificates, keys, or\n      tokens) for network access, the need for a standardized credentials\n      provisioning and management framework is paramount.  The 802.1x\n      architecture allows for entities (e.g., devices, applications, etc.)\n      to authenticate to the network by providing a communication channel\n      where different methods can be used to exchange different types of\n      credentials.  However, the need for managing these credentials (i.e.,\n      provisioning and renewal) is still a hard problem to solve.\n      \n      EAP-CREDS, if implemented in Managed Networks (e.g., Cable Modems),\n      could enable our operators to offer a registration and credentials\n      management service integrated in the home WiFi thus enabling\n      visibility about registered devices.  During initialization, EAP-\n      CREDS also allows for MUD files or URLs to be transferred between the\n      EAP Peer and the EAP Server, thus giving detailed visibility about\n      devices when they are provisioned with credentials for accessing the\n      networks.  The possibility provided by EAP-CREDS can help to secure\n      home or business networks by leveraging the synergies of the security\n      teams from the network operators thanks to the extended knowledge of\n      what and how is registered/authenticated.\n      \n      This specifications define how to support the provisioning and\n      management of authentication credentials that can be exploited in\n      different environments (e.g., Wired, WiFi, cellular, etc.) to users\n      and/or devices by using EAP together with standard provisioning\n      protocols.\n\n  "Performance Measurement Using TWAMP Light for Segment Routing Networks",\n  Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Mach Chen, Bart Janssens,\n  2019-12-05, <draft-gandhi-spring-twamp-srpm-05.txt>\n\n      Segment Routing (SR) leverages the source routing paradigm.  SR is\n      applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6\n      (SRv6) data planes.  This document specifies procedure for sending\n      and processing probe query and response messages for Performance\n      Measurement (PM) in Segment Routing networks.  The procedure uses the\n      mechanisms defined in RFC 5357 (Two-Way Active Measurement Protocol\n      (TWAMP) Light) and Simple Two-Way Active Measurement Protocol (STAMP)\n      for Delay Measurement, and also uses the mechanisms defined in this\n      document for Loss Measurement.  The procedure specified is applicable\n      to SR-MPLS and SRv6 data planes and are used for both links and\n      end-to-end SR Policies.\n\n  "A standard process to quarantine and restore IoT Devices", Michael\n  Richardson, Jacques Latour, 2019-08-19,\n  <draft-richardson-shg-un-quarantine-01.txt>\n\n      The Manufacturer Usage Description (MUD) is a tool to describe the\n      limited access that a single function device such as an Internet of\n      Things device might need.  The enforcement of the access control\n      lists described protects the device from attacks from the Internet,\n      and protects the Internets from compromised devices.\n      \n      This document details the process which occurs when a device is\n      detected to have violated the stated policy.  The goal of these steps\n      is to ensure that the device is correctly removed from operation,\n      fixed, and if possible, restored to safe operation.\n\n  "Illustrations for SRv6 Network Programming", Clarence Filsfils, Pablo\n  Camarillo, Zhenbin Li, Satoru Matsushima, Bruno Decraene, Dirk Steinberg,\n  David Lebrun, Robert Raszuk, John Leddy, 2019-08-15,\n  <draft-filsfils-spring-srv6-net-pgm-illustration-01.txt>\n\n      This document illustrates how SRv6 Network Programming\n      [I-D.ietf-spring-srv6-network-programming] can be used to create\n      interoperable and protected overlays with underlay optimization and\n      service programming.\n\n  "Performance Measurement Using UDP Path for Segment Routing Networks",\n  Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Stefano Salsano, Mach Chen,\n  2019-11-16, <draft-gandhi-spring-rfc6374-srpm-udp-03.txt>\n\n      Segment Routing (SR) leverages the source routing paradigm.  Segment\n      Routing (SR) is applicable to both Multiprotocol Label Switching\n      (SR-MPLS) and IPv6 (SRv6) data planes.  This document specifies\n      procedures for using UDP path for sending and processing probe query\n      and response messages for Performance Measurement (PM).  The\n      procedure uses the mechanisms defined in RFC 6374 for Performance\n      Delay and Loss Measurement.  The procedure specified is applicable to\n      SR-MPLS and SRv6 data planes for both links and end-to-end\n      measurement for SR Policies.\n\n  "IKEv2 Optional SA&TS Payloads in Child Exchange", Sandeep Kampati, Meduri\n  Bharath, Wei Pan, 2019-11-04,\n  <draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt-02.txt>\n\n      This document describes a method for reducing the size of the\n      Internet Key Exchange version 2 (IKEv2) exchanges at time of rekeying\n      IKE SAs and Child SAs by removing or making optional of SA & TS\n      payloads.  Reducing size of IKEv2 exchanges is desirable for low\n      power consumption battery powered devices.  It also helps to avoid IP\n      fragmentation of IKEv2 messages.\n\n  "Mathematical Mesh 3.0 Part II: Uniform Data Fingerprint.", Phillip\n  Hallam-Baker, 2020-01-06, <draft-hallambaker-mesh-udf-08.txt>\n\n      This document describes the naming and addressing schemes used in the\n      Mathematical Mesh.  The means of generating Uniform Data Fingerprint\n      (UDF) values and their presentation as text sequences and as URIs are\n      described.\n      \n      A UDF consists of a binary sequence, the initial eight bits of which\n      specify a type identifier code.  Type identifier codes have been\n      selected so as to provide a useful mnemonic indicating their purpose\n      when presented in Base32 encoding.\n      \n      Two categories of UDF are described.  Data UDFs provide a compact\n      presentation of a fixed length binary data value in a format that is\n      convenient for data entry.  A Data UDF may represent a cryptographic\n      key, a nonce value or a share of a secret.  Fingerprint UDFs provide\n      a compact presentation of a Message Digest or Message Authentication\n      Code value.\n      \n      A Strong Internet Name (SIN) consists of a DNS name which contains at\n      least one label that is a UDF fingerprint of a policy document\n      controlling interpretation of the name.  SINs allow a direct trust\n      model to be applied to achieve end-to-end security in existing\n      Internet applications without the need for trusted third parties.\n      \n      UDFs may be presented as URIs to form either names or locators for\n      use with the UDF location service.  An Encrypted Authenticated\n      Resource Locator (EARL) is a UDF locator URI presenting a service\n      from which an encrypted resource may be obtained and a symmetric key\n      that may be used to decrypt the content.  EARLs may be presented on\n      paper correspondence as a QR code to securely provide a machine-\n      readable version of the same content.  This may be applied to\n      automate processes such as invoicing or to provide accessibility\n      services for the partially sighted.\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html.\n\n  "Related Domains By DNS", Alexander Brotman, Stephen Farrell, 2019-09-18,\n  <draft-brotman-rdbd-03.txt>\n\n      This document describes a mechanism by which a DNS domain can\n      publicly document the existence or absence of a relationship with a\n      different domain, called "Related Domains By DNS", or "RDBD."\n\n  "Mathematical Mesh 3.0 Part III : Data At Rest Encryption (DARE)", Phillip\n  Hallam-Baker, 2020-01-16, <draft-hallambaker-mesh-dare-06.txt>\n\n      This document describes the Data At Rest Encryption (DARE) Envelope\n      and Container syntax.\n      \n      The DARE Envelope syntax is used to digitally sign, digest,\n      authenticate, or encrypt arbitrary content data.\n      \n      The DARE Container syntax describes an append-only sequence of\n      entries, each containing a DARE Envelope.  DARE Containers may\n      support cryptographic integrity verification of the entire data\n      container content by means of a Merkle tree.\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html.\n\n  "Extended Link Relationships", Jose Montoya, 2019-10-19,\n  <draft-montoya-xrel-01.txt>\n\n      This document defines XREL, a data format for describing extended\n      hypermedia relationships identified by Uniform Resource Locators.\n\n  "The Deprecation HTTP Header Field", Sanjay Dalal, Erik Wilde, 2019-12-19,\n  <draft-dalal-deprecation-header-02.txt>\n\n      The HTTP Deprecation response header field can be used to signal to\n      consumers of a URI-identified resource that the resource has been\n      deprecated.  Additionally, the deprecation link relation can be used\n      to link to a resource that provides additional context for the\n      deprecation, and possibly ways in which clients can find a\n      replacement for the deprecated resource.\n\n  "The IPv6 Compressed Routing Header (CRH)", Ron Bonica, Yuji Kamite,\n  Tomonobu Niwa, Andrew Alston, Daniam Henriques, Luay Jalil, Ning So,\n  Fengman Xu, Gang Chen, Yongqing Zhu, Yifeng Zhou, 2019-12-14,\n  <draft-bonica-6man-comp-rtg-hdr-10.txt>\n\n      This document defines two new IPv6 Routing header types.\n      Generically, they are called the Compressed Routing Header (CRH).\n      More specifically, the 16-bit version of the CRH is called the CRH-\n      16, while the 32-bit version of the CRH is called the CRH-32.  SRm6\n      nodes use the CRH to steer packets from segment to segment along SRm6\n      paths.\n\n  "OAM Capabilities for IPv6", Ron Bonica, Yuji Kamite, Ning So, Fengman Xu,\n  Gang Chen, Yongqing Zhu, Guangming Yang, Yifeng Zhou, 2019-09-16,\n  <draft-bonica-6man-oam-04.txt>\n\n      This document defines new IPv6 Operations and Management (OAM)\n      capabilities.  In order to support these new capabilities, this\n      document defines an IPv6 OAM Option and an ICMPv6 OAM message.\n\n  "The Per-Segment Service Instruction (PSSI) Option", Ron Bonica, Joel\n  Halpern, Yuji Kamite, Tomonobu Niwa, Luay Jalil, Ning So, Fengman Xu, Gang\n  Chen, Yongqing Zhu, Yifeng Zhou, 2019-11-20,\n  <draft-bonica-6man-seg-end-opt-06.txt>\n\n      SRm6 encodes Per-Segment Service Instructions (PSSI) in a new IPv6\n      option, called the PSSI Option.  This document describes the PSSI\n      Option.\n\n  "Scenarios and Requirements for Layer 2 Autonomic Control Planes", Brian\n  Carpenter, Bing Liu, 2019-10-02,\n  <draft-carpenter-anima-l2acp-scenarios-01.txt>\n\n      This document discusses scenarios and requirements for Autonomic\n      Control Planes (ACPs) constructed and secured at Layer 2.  These\n      would be alternatives to an ACP constructed and secured at the\n      network layer.  A secure ACP is required as the substrate for the\n      Generic Autonomic Signaling Protocol (GRASP) used by Autonomic\n      Service Agents.\n\n  "The MASQUE Protocol", David Schinazi, 2020-01-08,\n  <draft-schinazi-masque-02.txt>\n\n      This document describes MASQUE (Multiplexed Application Substrate\n      over QUIC Encryption).  MASQUE is a framework that allows\n      concurrently running multiple networking applications inside an\n      HTTP/3 connection.  For example, MASQUE can allow a QUIC client to\n      negotiate proxying capability with an HTTP/3 server, and subsequently\n      make use of this functionality while concurrently processing HTTP/3\n      requests and responses.\n      \n      This document is a straw-man proposal.  It does not contain enough\n      details to implement the protocol, and is currently intended to spark\n      discussions on the approach it is taking.  Discussion of this work is\n      encouraged to happen on the MASQUE IETF mailing list masque@ietf.org\n      (mailto:masque@ietf.org) or on the GitHub repository which contains\n      the draft: https://github.com/DavidSchinazi/masque-drafts\n      (https://github.com/DavidSchinazi/masque-drafts).\n\n  "YANG Data Model for FlexE Interface Management", Yuanlong Jiang, Xiang He,\n  Weiqiang Cheng, Junfang Wang, Yalei Han, 2019-11-04,\n  <draft-jiang-ccamp-flexe-yang-02.txt>\n\n      This document defines YANG data models for the configuration of Flex\n      Ethernet (FlexE) interfaces, including a FlexE group and its FlexE\n      clients. The YANG modules in this document conforms to the Network\n      Management Datastore Architecture (NMDA).\n\n  "A One-Path Congestion Metric for IPPM", Joanna Dang, Jianglong, Shinyoung\n  Lee, Hongbo, 2019-11-04, <draft-dang-ippm-congestion-02.txt>\n\n      This memo defines a metric for one path congestion across Internet\n      paths.  The traditional mode evaluates network congestion based on\n      the bandwidth utilization of the link.  However, there is a lack of\n      E2E path congestion that is truly service oriented.  So A Path\n      Congestion Metric is required.\n\n  "SDWAN WAN Ports Property Advertisement in BGP UPDATE", Linda Dunbar, Susan\n  Hares, 2019-11-21, <draft-dunbar-idr-sdwan-port-safi-06.txt>\n\n      The document describes how the SDWAN SAFI, which is assigned by IANA\n      in the First Come First Server range, is used for SDWAN edge nodes\n      to propagate its WAN port properties to its controller.\n      \n      In the context of this document, BGP Route Reflectors (RR) is the\n      component of the SDWAN Controller that receives the BGP UPDATE from\n      SDWAN edges and in turns propagate the information to a group of\n      authorized SDWAN edges reachable via overlay networks.\n\n  "Multi-Path Concurrent Measurement for IPPM", Joanna Dang, Jianglong,\n  Shinyoung Lee, 2019-11-04,\n  <draft-dang-ippm-multiple-path-measurement-02.txt>\n\n      This test method can test multi-paths concurrently from one edge node\n      to another edge node.  This document details Multi-Path Concurrent\n      Measurement (MPCM).\n\n  "A Bootstrapping Procedure to Discover and Authenticate DNS-over-(D)TLS and\n  DNS-over-HTTPS Servers", Tirumaleswar Reddy.K, Dan Wing, Michael\n  Richardson, Mohamed Boucadair, 2020-01-09,\n  <draft-reddy-dprive-bootstrap-dns-server-06.txt>\n\n      This document specifies mechanisms to automatically bootstrap\n      endpoints (e.g., hosts, Customer Equipment) to discover and\n      authenticate DNS-over-(D)TLS and DNS-over-HTTPS servers provided by a\n      local network.\n\n  "Transport parameters for 0-RTT connections", Nicolas Kuhn, Stephan Emile,\n  Gorry Fairhurst, 2019-12-23, <draft-kuhn-quic-0rtt-bdp-06.txt>\n\n      QUIC 0-RTT relies on the sharing of the "initial_max_data" transport\n      parameter between peers.  It indicates to the client the number of\n      bytes it is allowed to send in the first packet of the 0-RTT\n      connection.  This allows a faster startup of flows and enables\n      adaptated buffer sizes at the server.  The traffic that the client\n      sends, i.e. the egress trafic, is improved.  This memo proposes the\n      sharing of additional transport parameters to provide a faster\n      startup of flows and a better buffer management for the data that the\n      client receives, i.e. the ingress traffic.\n\n  "Bidirectional Forwarding Detection (BFD) for EVPN Ethernet Segment\n  Failover Use Case", Zheng Zhang, Yubao Wang, Gregory Mirsky, 2019-10-24,\n  <draft-zwm-bess-es-failover-01.txt>\n\n      This document introduces a method for fast switchover of Designated\n      Forwarder for Ethernet Segment failover by using Bidirectional\n      Forwarding Detection protocol.\n\n  "SRv6 Path Egress Protection", Zhibo Hu, China Telecom, Huaimo Chen, Peng\n  Wu, Mehmet Toy, Chang Cao, Lei Liu, Xufeng Liu, 2020-01-24,\n  <draft-hu-rtgwg-srv6-egress-protection-06.txt>\n\n      This document describes protocol extensions for protecting the egress\n      node of a Segment Routing for IPv6 (SRv6) path or tunnel.\n\n  "BGP Provisioned IPsec Tunnel Configuration", Jun Hu, 2019-09-04,\n  <draft-hujun-idr-bgp-ipsec-01.txt>\n\n      This document defines a method of using BGP to provide IPsec tunnel\n      configuration along with NLRI, it uses and extends tunnel\n      encapsulation attribute as specified in [I-D.ietf-idr-tunnel-encaps]\n      for IPsec tunnel.\n\n  "Extended Bidirectional Forwarding Detection", Gregory Mirsky, Min Xiao,\n  2019-10-10, <draft-mirmin-bfd-extended-02.txt>\n\n      This document describes a mechanism to extend the capabilities of\n      Bidirectional Forwarding Detection (BFD).  These extensions enable\n      BFD to measure performance metrics like packet loss and packet delay.\n      Also, a method to perform lightweight on-demand authentication is\n      defined in this specification.\n\n  "Proxy IP->MAC Advertisement in EVPNs", Ryan Bickhart, Wen Lin, John Drake,\n  Jorge Rabadan, Alton Lo, 2020-01-24,\n  <draft-rbickhart-evpn-ip-mac-proxy-adv-01.txt>\n\n      This document specifies procedures for EVPN PEs connected to a common\n      multihomed site to generate proxy EVPN type 2 IP->MAC advertisements\n      on behalf of other PEs to facilitate preservation of ARP/ND state\n      across link or node failures.\n\n  "LOOPS (Localized Optimizations on Path Segments) Problem Statement and\n  Opportunities for Network-Assisted Performance Enhancement", Li Yizhou,\n  Xingwang Zhou, Mohamed Boucadair, Jianglong Wang, 2020-01-06,\n  <draft-li-tsvwg-loops-problem-opportunities-04.txt>\n\n      In various network deployments, end to end forwarding paths are\n      partitioned into multiple segments.  For example, in some cloud-based\n      WAN communications, stitching multiple overlay tunnels are used for\n      traffic policy enforcement matters such as to optimize traffic\n      distribution or to select paths exposing a lower latency.  Likewise,\n      in satellite communications, the communication path is decomposed\n      into two terrestrial segments and a satellite segment.  Such long-\n      haul paths are naturally composed of multiple network segments with\n      various encapsulation schemes.  Packet loss may show different\n      characteristics on different segments.\n      \n      Traditional transport protocols (e.g., TCP) respond to packet loss\n      slowly especially in long-haul networks: they either wait for some\n      signal from the receiver to indicate a loss and then retransmit from\n      the sender or rely on sender\'s timeout which is often quite long.\n      Non-congestive loss may make the TCP sender over-reduce the sending\n      rate unnecessarily.  With the increase of end-to-end transport\n      encryption (e.g., QUIC), traditional PEP (performance enhancing\n      proxy) techniques such as TCP splitting are no longer applicable.\n      \n      LOOPS (Local Optimizations on Path Segments) is a network-assisted\n      performance enhancement over path segment and it aims to provide\n      local in-network recovery to achieve better data delivery by making\n      packet loss recovery faster and by avoiding the senders over-reducing\n      their sending rate.  In an overlay network scenario, LOOPS can be\n      performed over a variety of the existing, or purposely created,\n      tunnel-based path segments.\n\n  "Using Commercial National Security Algorithm Suite Algorithms in\n  Secure/Multipurpose Internet Mail Extensions", Michael Jenkins, 2019-11-26,\n  <draft-jenkins-cnsa-smime-profile-03.txt>\n\n      The United States Government has published the NSA Commercial\n      National Security Algorithm (CNSA) Suite, which defines cryptographic\n      algorithm policy for national security applications.  This document\n      specifies the conventions for using the United States National\n      Security Agency\'s CNSA Suite algorithms in Secure/Multipurpose\n      Internet Mail Extensions (S/MIME) as specified in RFC 8551.  It\n      applies to the capabilities, configuration, and operation of all\n      components of US National Security Systems that employ S/MIME\n      messaging.  US National Security Systems are described in NIST\n      Special Publication 800-59.  It is also appropriate for all other US\n      Government systems that process high-value information.  It is made\n      publicly available for use by developers and operators of these and\n      any other system deployments.\n\n  "Considerations for Benchmarking Network Performance in Containerized\n  Infrastructures", Sun Kj, Hyunsik Yang, ykpark@dcn.ssu.ac.kr, Young-Han\n  Kim, Wangbong Lee, 2019-11-04, <draft-dcn-bmwg-containerized-infra-03.txt>\n\n      This draft describes considerations for benchmarking network\n      performance in containerized infrastructures.  In the containerized\n      infrastructure, Virtualized Network Functions(VNFs) are deployed on\n      operating-system-level virtualization platform by abstracting the\n      user namespace as opposed to virtualization using a hypervisor.\n      Leveraging this, the system configurations and networking scenarios\n      for benchmarking will be partially changed by the way in which the\n      resource allocation and network technologies specified for\n      containerized VNFs.  In this draft, we compare the state of the art\n      in a container networking architecture with networking on VM-based\n      virtualized systems, and provide several test scenarios for\n      benchmarking network performance in containerized infrastructures.\n\n  "Encapsulation for BIER in Non-MPLS IPv6 Networks", Jingrong Xie, Liang\n  Geng, Mike McBride, Rajiv Asati, Senthil Dhanaraj, 2020-01-13,\n  <draft-xie-bier-ipv6-encapsulation-05.txt>\n\n      This document proposes a BIER IPv6 (BIERv6) encapsulation for Non-\n      MPLS IPv6 Networks using the IPv6 Destination Option extension\n      header.  This document updates [RFC8296].\n\n  "Composite Keys and Signatures For Use In Internet PKI", Mike Ounsworth,\n  Massimiliano Pala, 2020-01-16, <draft-ounsworth-pq-composite-sigs-02.txt>\n\n      With the widespread adoption of post-quantum cryptography will come\n      the need for an entity to possess multiple public keys on different\n      cryptographic algorithms.  Since the trustworthiness of individual\n      post-quantum algorithms is at question, a multi-key cryptographic\n      operation will need to be performed in such a way that breaking it\n      requires breaking each of the component algorithms individually.\n      This requires defining new structures for holding composite public\n      keys and composite signature data.\n      \n      This document defines the structures CompositePublicKey,\n      CompositeSignatureValue, and CompositeParams, which are sequences of\n      the respective structure for each component algorithm.  This document\n      also defines algorithms for generating and verifying composite\n      signatures.  This document makes no assumptions about what the\n      component algorithms are, provided that their algorithm identifiers\n      and signature generation and verification algorithms are defined.\n\n  "Centralized DNS over HTTPS (DoH) Implementation Issues and Risks", Jason\n  Livingood, Manos Antonakakis, Bob Sleigh, Alister Winfield, 2019-09-16,\n  <draft-livingood-doh-implementation-risks-issues-04.txt>\n\n      The DNS over HTTPS (DoH) protocol is specified in RFC8484.  This\n      document considers Centralized DoH deployment, which seems one likely\n      way that DoH may be implemented, based on recent industry discussions\n      and testing.  This describes that implementation model, as well the\n      potential associated risks and issues.  The document also makes\n      recommendations pertaining to the implementation of DoH, as well as\n      recommendations for further study prior to widespread adoption.\n\n  "A YANG Data Model for Network Interconnect Tester Management", Vladimir\n  Vassilev, 2019-10-08,\n  <draft-vassilev-bmwg-network-interconnect-tester-02.txt>\n\n      This document introduces new YANG model for use in network\n      interconnect testing containing modules for traffic generator and\n      traffic analyzer.\n\n  "Recommendations for DNS Privacy Client Applications", Vittorio Bertola,\n  2019-09-10, <draft-bertola-bcp-doh-clients-01.txt>\n\n      This document presents operational, policy and security\n      considerations for the authors and publishers of client applications\n      that choose to implement DNS resolution through any of the protocols\n      that provide private, encrypted connections between the application\n      itself and the DNS resolver.  As these protocols, depending on\n      implementation choices and deployment models, may impact the Internet\n      significantly at the architectural, legal and policy levels, the\n      document records the current consensus on how these protocols should\n      be used by applications, especially user-facing applications meant\n      for mass usage by non-technical consumers.\n\n  "Group Communication for the Constrained Application Protocol (CoAP)", Esko\n  Dijk, Chonggang Wang, Marco Tiloca, 2019-11-04,\n  <draft-dijk-core-groupcomm-bis-02.txt>\n\n      This document specifies the use of the Constrained Application\n      Protocol (CoAP) for group communication, using UDP/IP multicast as\n      the underlying data transport.  Both unsecured and secured CoAP group\n      communication are specified.  Security is achieved by use of the\n      Group Object Security for Constrained RESTful Environments (Group\n      OSCORE) protocol.  The target application area of this specification\n      is any group communication use cases that involve resource-\n      constrained network nodes.  The most common of such use cases are\n      listed in this document.\n\n  "Encapsulation For MPLS Performance Measurement with Alternate Marking\n  Method", Weiqiang Cheng, Min Xiao, Tianran Zhou, Ximing Dong, Yoav Peleg,\n  2019-11-04, <draft-cheng-mpls-inband-pm-encapsulation-02.txt>\n\n      This document defines the encapsulation for MPLS performance\n      measurement with alternate marking method, which performs flow-based\n      packet loss, delay, and jitter measurements on live traffic.\n\n  "SRv6 Proxy Forwarding", Huaimo Chen, Zhibo Hu, China Telecom, 2019-09-13,\n  <draft-chen-rtgwg-srv6-midpoint-protection-01.txt>\n\n      The endpoints of a SRv6 path are given by a SRv6 Policy.  When an\n      endpoint node fails, we need bypass this failed endpoint node and\n      forward the packets to the failed node\'s next endpoint node.\n\n  "Requirements and Challenges for User-level Service Managements of IoT\n  Network by utilizing Artificial Intelligence", Junkyun Choi, Jaeseob Han,\n  Gyeong Lee, Na Kim, 2019-11-17, <draft-choi-icnrg-aiot-02.txt>\n\n      This document describes the requirements and challenges to employ\n      artificial\n      intelligence     (AI) into the constraint Internet of Things\n      (IoT) service environment for\n      embedding     intelligence and increasing\n      efficiency.\n      The IoT service environment includes heterogeneous and\n      multiple IoT devices and\n      systems     that work together in a cooperative\n      and intelligent way to manage homes, buildings,\n      and     complex\n      autonomous systems. Therefore, it is becoming very essential to\n      integrate IoT\n      and     AI technologies to increase the synergy between\n      them. However, there are\n      several     limitations to achieve AI enabled\n      IoT as the availability of IoT devices is not always\n      high,     and IoT\n      networks cannot guarantee a certain level of performance in real-time\n      applications     due to resource constraints.\n      This document intends to\n      present a right direction to empower AI in IoT for learning\n      and\n      analyzing the usage behaviors of IoT devices/systems and human behaviors\n      based\n      on     previous records and experiences. With AI enabled IoT, the\n      IoT service environment can\n      be     intelligently managed in order to\n      compensate for the unexpected performance\n      degradation     often caused\n      by abnormal situations.\n      \n      This Internet-Draft is submitted in full conformance with the\n      provisions of BCP 78 and BCP 79.\n      \n      Internet-Drafts are working documents of the Internet Engineering\n      Task Force (IETF).  Note that other groups may also distribute\n      working documents as Internet-Drafts.  The list of current Internet-\n      Drafts is at http://datatracker.ietf.org/drafts/current/.\n      \n      Internet-Drafts are draft documents valid for a maximum of six months\n      and may be updated, replaced, or obsoleted by other documents at any\n      time.  It is inappropriate to use Internet-Drafts as reference\n      material or to cite them other than as "work in progress."\n      \n      This Internet-Draft will\n      expire on May 19, 2020\n\n  "Use of BIER IPv6 Encapsulation (BIERv6) for Multicast VPN in IPv6\n  networks", Jingrong Xie, Mike McBride, Senthil Dhanaraj, Liang Geng,\n  2020-01-13, <draft-xie-bier-ipv6-mvpn-02.txt>\n\n      This draft defines the procedures and messages for using Bit Index\n      Explicit Replication (BIER) for Multicast VPN Services in IPv6\n      networks using the BIER IPv6 encapsulation.  It provides a migration\n      path for Multicast VPN service using BIER MPLS encapsulation in MPLS\n      networks to multicast VPN service using BIER IPv6 encapsulation\n      (BIERv6) in IPv6 networks.\n\n  "Support of asynchronous Enrollment in BRSKI", Steffen Fries, Hendrik\n  Brockhaus, Eliot Lear, 2019-11-04,\n  <draft-fries-anima-brski-async-enroll-02.txt>\n\n      This document discusses an enhancement of automated bootstrapping of\n      a remote secure key infrastructure (BRSKI) to operate in domains\n      featuring no or only timely limited connectivity to backend services\n      offering enrollment functionality, specifically a Public Key\n      Infrastructure (PKI).  In the context of deploying new devices the\n      design of BRSKI allows for online (synchronous object exchange) and\n      offline interactions (asynchronous object exchange) with a\n      manufacturer\'s authorization service.  For this it utilizes a self-\n      contained voucher to transport the domain credentials as a signed\n      object to establish an initial trust between a pledge and the target\n      deployment domain.  The currently supported enrollment protocol for\n      request and distribution of deployment domain specific device\n      certificates provides only limited support for asynchronous PKI\n      interactions.  This memo motivates the enhancement of supporting\n      self-contained objects for certificate management by using an\n      abstract notation.  This allows off-site operation of PKI services\n      outside the deployment domain of the pledge.  This addresses\n      specifically scenarios, in which the final authorization of\n      certification request of a pledge cannot be made in the deployment\n      domain and is therefore delegated to a operator backend.  The goal is\n      to enable the usage of existing and potentially new PKI protocols\n      supporting self-containment for certificate management.\n\n  "Deployment Considerations for In-situ OAM with IPv6 Options", Shwetha\n  Bhandari, Frank Brockners, Tal Mizrahi, Aviv Kfir, Barak Gafni, Mickey\n  Spiegel, Suresh Krishnan, Mark Smith, 2019-09-26,\n  <draft-ioametal-ippm-6man-ioam-ipv6-deployment-02.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in the packet while the packet\n      traverses a path between two points in the network.  This document\n      outlines how IOAM can be enabled in an IPv6 network.\n\n  "BGP Route Policy and Attribute Trace Using BMP", Feng Xu, Thomas Graf,\n  Yunan Gu, Shunwan Zhuang, Zhenbin Li, 2020-01-05,\n  <draft-xu-grow-bmp-route-policy-attr-trace-04.txt>\n\n      The generation of BGP adj-rib-in, local-rib or adj-rib-out comes from\n      BGP route exchange and route policy processing.  BGP Monitoring\n      Protocol (BMP) provides the monitoring of BGP adj-rib-in [RFC7854],\n      BGP local-rib [I-D.ietf-grow-bmp-local-rib] and BGP adj-rib-out\n      [I-D.ietf-grow-bmp-adj-rib-out].  By monitoring these BGP RIB\'s the\n      full state of the network is visible, but how route-policies affect\n      the route propagation or changes BGP attributes is still not.  This\n      document describes a method of using BMP to record the trace data on\n      how BGP routes are (not) changed under the process of route policies.\n\n  "A YANG Data Model for Flex Ethernet(FlexE)", Xiaobing NIU, Qilei Wang,\n  Yunbin Xu, Sivakumar Munagapati, 2019-11-04,\n  <draft-xiaobn-ccamp-flexe-yang-mod-03.txt>\n\n      Flex Ethernet(FlexE) implementation agreement have been published by\n      OIF.  FlexE provides a generic mechanism for supporting a variety of\n      Ethernet MAC rates that may or may not correspond to any existing\n      Ethernet PHY rate.\n      \n      This document describes a YANG data model for FlexE.  It can be used\n      to manage and control devices supporting FlexE functions.\n\n  "BGP Flow Specification for SRv6", Zhenbin Li, Lei Li, Huaimo Chen,\n  Christoph Loibl, Yanhe Fan, Yongqing Zhu, Lei Liu, Xufeng Liu, 2019-12-13,\n  <draft-li-idr-flowspec-srv6-02.txt>\n\n      This document proposes extensions to BGP Flow Specification for SRv6\n      for filtering SRv6 packets that match a sequence of conditions.\n\n  "Enhanced Topology Independent Loop-free Alternate Fast Re-route", Cheng\n  Li, Zhibo Hu, 2020-01-11, <draft-li-rtgwg-enhanced-ti-lfa-01.txt>\n\n      Topology Independent Loop-free Alternate Fast Re-route (TI-LFA) aims\n      at providing protection of node and adjacency segments within the\n      Segment Routing (SR) framework.  A key aspect of TI-LFA is the FRR\n      path selection approach establishing protection over the expected\n      post-convergence paths from the point of local repair.  However, the\n      TI-LFA FRR path may skip the node even if it is specified in the SID\n      list to be traveled.\n      \n      This document defines Enhanced TI-LFA(TI-LFA+) by adding a No-bypass\n      indicator for segments to ensure that the FRR route will not bypass\n      the specific node, such as firewall.\n\n  "Multipath Use Case and Requirement for Security", Stafan Rass, Yingzhen\n  Qu, Lin Han, 2019-09-10, <draft-rass-panrg-mpath-usecase-01.txt>\n\n      This document describes a use case of multipath to achieve full CIA+\n      by using symmetric cryptography and point-to-point shared secrets.\n\n  "Analysis for FlexE control", Qilei Wang, Xiaobing NIU, Yunbin Xu,\n  2019-11-04, <draft-wang-ccamp-flexe-control-analysis-03.txt>\n\n      This document gives some analysis about the control of FlexE.\n\n  "YANG Data Models for Multiprotocol Label Switching - Transport Profile",\n  Italo Busi, Haomian Zheng, 2019-10-11,\n  <draft-busizheng-teas-mpls-tp-yang-01.txt>\n\n      Multi-protocol Label Switching - Transport Profile (MPLS-TP) is a\n      profile of the MPLS protocol that is used in packet switched\n      transport networks and operated in a similar manner to other\n      existing transport technologies (e.g., OTN), as described in\n      RFC5921. This document specifies YANG models for MPLS-TP, which have\n      not been covered by existing models so far. The gap analysis with\n      current relevant traffic-engineering (TE) and MPLS models is also\n      included.\n\n  "Signed HTTP Requests (SHREQ)", Anders Rundgren, 2019-09-09,\n  <draft-rundgren-signed-http-requests-01.txt>\n\n      The SHREQ specification describes how the JSON Web Signature (JWS)\n      specification combined with the JSON Canonicalization Scheme (JCS),\n      can be utilized to support HTTP based applications needing digitally\n      signed requests.  SHREQ is specifically tailored for Web applications\n      using JSON as data interchange format.  There is also a SHREQ scheme\n      for HTTP requests that do not have a body ("payload") like GET.\n      SHREQ was designed to be agnostic with respect to REST concepts\n      versus traditional GET/POST schemes.\n\n  "Using CBOR Web Tokens (CWTs) in Transport Layer Security (TLS) and\n  Datagram Transport Layer Security (DTLS)", Hannes Tschofenig, Mathias\n  Brossard, 2019-11-04, <draft-tschofenig-tls-cwt-01.txt>\n\n      The TLS protocol supports different credentials, including pre-shared\n      keys, raw public keys, and X.509 certificates.  For use with public\n      key cryptography developers have to decide between raw public keys,\n      which require out-of-band agreement and full-fletched X.509\n      certificates.  For devices where the reduction of code size is\n      important it is desirable to minimize the use of X.509-related\n      libraries.  With the CBOR Web Token (CWT) a structure has been\n      defined that allows CBOR-encoded claims to be protected with CBOR\n      Object Signing and Encryption (COSE).\n      \n      This document registers a new value to the "TLS Certificate Types"\n      sub-registry to allow TLS and DTLS to use CWTs.  Conceptually, CWTs\n      can be seen as a certificate format (when with public key\n      cryptography) or a Kerberos ticket (when used with symmetric key\n      cryptography).\n\n  "Arm\'s Platform Security Architecture (PSA) Attestation Token", Hannes\n  Tschofenig, Simon Frost, Mathias Brossard, Adrian Shaw, Thomas Fossati,\n  2019-11-20, <draft-tschofenig-rats-psa-token-04.txt>\n\n      The insecurity of IoT systems is a widely known and discussed\n      problem.  The Arm Platform Security Architecture (PSA) is being\n      developed to address this challenge by making it easier to build\n      secure IoT systems.\n      \n      This document specifies token format and claims used in the\n      attestation API of the Arm Platform Security Architecture (PSA).\n      \n      At its core, the CWT (COSE Web Token) format is used and populated\n      with a set of claims, in a way similar to EAT (Entity Attestation\n      Token).  This specification describes what claims are used by PSA\n      compliant systems and what has been implemented within Arm Trusted\n      Firmware-M.\n\n  "Connection Setup in a Quantum Network", Rodney Van Meter, Takaaki Matsuo,\n  2019-09-11, <draft-van-meter-qirg-quantum-connection-setup-01.txt>\n\n      Near-term quantum networks will grow to form a Noisy, Intermediate-\n      Scale Quantum Internet (NISQI).  Connection setup will require\n      adapting behavior along the path to the noise levels of individual\n      elements.  In this proposal, path creation is triggered by an\n      application at the Initiator, information is accumulated node-by-node\n      on an outbound pass in a series of QCap (quantum capability) blocks,\n      then the RuleSets are created at the Responder.  RuleSets are\n      installed at the individual nodes on the return pass.  This document\n      describes the architecture of connection setup in a network.  Details\n      of the RuleSets and QCaps, addressing architecture, link protocols,\n      routing, resource allocation (multiplexing), extension of this setup\n      procedure to an internetwork, and extension to multiparty\n      communications are beyond the scope of this document.\n\n  "IPv6 Encapsulation for SFC and IFIT", Zhenbin Li, Shuping Peng, Kihoon\n  LEE, 2019-09-09, <draft-li-6man-ipv6-sfc-ifit-02.txt>\n\n      Service Function Chaining (SFC) and In-situ Flow Information\n      Telemetry (IFIT) are important path services along with the packets.\n      In order to support these services, several encapsulations have been\n      defined.  The document analyzes the problems of these encapsulations\n      in the IPv6 scenario and proposes the possible optimized\n      encapsulation for IPv6.\n\n  "Weighted HRW and its applications", satyamoh@cisco.com, mankamana mishra,\n  Acee Lindem, Ali Sajassi, John Drake, 2019-09-11,\n  <draft-mohanty-bess-weighted-hrw-01.txt>\n\n      Rendezvous Hashing also known as Highest Random Weight (HRW) has been\n      used in many load balancing applications where the central problem is\n      how to map an object to as server such that the mapping is uniform\n      and also minimally affected by the change in the server set.\n      Recently, it has found use in DF election algorithms in the EVPN\n      context and load balancing using DMZ.  This draft deals with the\n      problem of achieving load balancing with minimal disruption when the\n      servers have different weights.  It provides an algorithm to do so\n      and also describes a few use-case scenarios where this algorithmic\n      technique can apply.\n\n  "YANG Semantic Versioning", Benoit Claise, Joe Clarke, Reshad Rahman,\n  Robert Wilton, Balazs Lengyel, Jason Sterne, Kevin D\'Souza, 2019-10-11,\n  <draft-verdt-netmod-yang-semver-01.txt>\n\n      This document specifies a scheme for applying a modified set of\n      semantic versioning rules to revisions of YANG modules.\n      Additionally, this document defines a revision label for this\n      modified semver scheme based on the specification in draft-verdt-\n      netmod-yang-module-versioning.\n\n  "BGP-LS Extensions for Inter-AS TE using EPE based mechanisms", Shraddha\n  Hegde, Srihari Ramachandra, Mukul Srivastava, Xiaohu Xu, 2019-11-02,\n  <draft-hegde-idr-bgp-ls-epe-inter-as-02.txt>\n\n      In certain network deployments, a single operator has multiple\n      Autonomous Systems(AS) to facilitate ease of management.  A multiple\n      AS network design could also be a result of network mergers and\n      acquisitions.  In such scenarios, a centralized Inter-domain TE\n      approach could provide most optimal allocation of resources and the\n      most controlled path placement.  BGP-LS-EPE\n      [I-D.ietf-idr-bgpls-segment-routing-epe] describes an extension to\n      BGP Link State (BGP-LS) for the advertisement of BGP Peering Segments\n      along with their BGP peering node and inter-AS link information, so\n      that efficient BGP Egress Peer Engineering (EPE) policies and\n      strategies can be computed based on Segment Routing.  This document\n      describes extensions to the BGP-LS EPE to enable it to be used for\n      inter-AS Traffic-Engineering (TE) purposes.\n\n  "A Connectivity Monitoring Metric for IPPM", Ruediger Geib, 2020-01-02,\n  <draft-geib-ippm-connectivity-monitoring-02.txt>\n\n      Within a Segment Routing domain, segment routed measurement packets\n      can be sent along pre-determined paths.  This enables new kinds of\n      measurements.  Connectivity monitoring allows to supervise the state\n      and performance of a connection or a (sub)path from one or a few\n      central monitoring systems.  This document specifies a suitable\n      type-P connectivity monitoring metric.\n\n  "Urban Air Mobility Implications for Intelligent Transportation Systems",\n  Fred Templin, 2020-01-01, <draft-templin-ipwave-uam-its-01.txt>\n\n      Urban Air Mobility concerns the introduction of manned and unmanned\n      aircraft within urban environments, while Intelligent Transportation\n      Systems have traditionally considered only terrestrial vehicles\n      operating on city streets and highways.  This document considers the\n      implications for introduction of low-altitude aircraft within urban\n      environments operating in harmony with ground transportation.\n\n  "Nested JSON Web Token (JWT)", Rifaat Shekh-Yusef, 2019-09-10,\n  <draft-yusef-oauth-nested-jwt-03.txt>\n\n      This specification extends the scope of the Nested JSON Web Token\n      (JWT) to allow the enclosing JWT to contain its own Claims Set in\n      addition to the enclosed JWT.\n\n  "Multicast VPN with Segment Routing Point-to-Multipoint Trees", Rishabh\n  Parekh, Clarence Filsfils, Arvind Venkateswaran, Hooman Bidgoli, Daniel\n  Voyer, Zhaohui Zhang, 2019-10-29, <draft-parekh-bess-mvpn-sr-p2mp-01.txt>\n\n      A Point-to-Multipoint (P2MP) Tree in a Segment Routing domain\n      efficiently carries traffic from a Root to a set of Leaves.  This\n      document describes extensions to BGP encodings and procedures for\n      P2MP trees used in BGP/MPLS IP VPNs.\n\n  "Compatible Version Negotiation for QUIC", David Schinazi, Eric Rescorla,\n  2019-11-04, <draft-schinazi-quic-version-negotiation-02.txt>\n\n      QUIC does not provide a complete version negotiation mechanism but\n      instead only provides a way for the server to indicate that the\n      version the client offered is unacceptable.  This document describes\n      a version negotiation mechanism that allows a client and server to\n      select a mutually supported version.  Optionally, if the original and\n      negotiated version share a compatible Initial format, the negotiation\n      can take place without incurring an extra round trip.\n      \n      Discussion of this work is encouraged to happen on the QUIC IETF\n      mailing list quic@ietf.org [1] or on the GitHub repository which\n      contains the draft: http://github.com/ekr/draft-schinazi-quic-\n      version-negotiation [2].\n\n  "Deprecation of IKEv1 and obsoleted algorithms", Paul Wouters, 2019-12-30,\n  <draft-pwouters-ikev1-ipsec-graveyard-04.txt>\n\n      Internet Key Exchange version 1 (IKEv1) is deprecated.  Accordingly,\n      IKEv1 has been moved to Historic status.  A number of old algorithms\n      that are associated with IKEv1, and not widely implemented for IKEv2\n      are deprecated as well.  IANA is instructed to close all IKEv1\n      registries.\n\n  "Use cases for Remote Attestation common encodings", Michael Richardson,\n  Carl Wallace, Wei Pan, 2019-11-04, <draft-richardson-rats-usecases-06.txt>\n\n      This document details mechanisms created for performing Remote\n      Attestation that have been used in a number of industries.  The\n      document initially focuses on existing industry verticals, mapping\n      terminology used in those specifications to the more abstract\n      terminology used by the IETF RATS Working Group.\n      \n      The document aspires to describe possible future use cases that would\n      be enabled by common formats.\n\n  "Autonomic setup of fog monitoring agents", Carlos Bernardos, Alain Mourad,\n  2019-11-19, <draft-bernardos-anima-fog-monitoring-01.txt>\n\n      The concept of fog computing has emerged driven by the Internet of\n      Things (IoT) due to the need of handling the data generated from the\n      end-user devices.  The term fog is referred to any networked\n      computational resource in the continuum between things and cloud.  In\n      fog computing, functions can be stiched together composing a service\n      function chain.  These functions might be hosted on resources that\n      are inherently heterogeneous, volatile and mobile.  This means that\n      resources might appear and disappear, and the connectivity\n      characteristics between these resources may also change dynamically.\n      This calls for new orchestration solutions able to cope with dynamic\n      changes to the resources in runtime or ahead of time (in anticipation\n      through prediction) as opposed to today\'s solutions which are\n      inherently reactive and static or semi-static.\n      \n      A fog monitoring solution can be used to help predicting events so an\n      action can be taken before an event actually takes place.  This\n      solution is composed of agents running on the fog nodes plus a\n      controller hosted at another device (running in the infrastructure or\n      in another fog node).  Since fog environments are inherently volatile\n      and extremely dynamic, it is convenient to enable the use of\n      autonomic technologies to autonomously set-up the fog monitoring\n      platform.  This document aims at presenting this use case as well as\n      specifying how to use GRASP as needed in this scenario.\n\n  "Multi-domain Network Virtualization", Carlos Bernardos, Luis Contreras,\n  Ishan Vaishnavi, Robert Szabo, Xi Li, Francesco Paolucci, Andrea\n  Sgambelluri, Barbara Martini, Luca Valcarenghi, Giada Landi, Dmitriy\n  Andrushko, Alain Mourad, 2019-09-12,\n  <draft-bernardos-nmrg-multidomain-01.txt>\n\n      This document analyzes the problem of multi-provider multi-domain\n      orchestration, by first scoping the problem, then looking into\n      potential architectural approaches, and finally describing the\n      solutions being developed by the European 5GEx and 5G-TRANSFORMER\n      projects.\n\n  "QoS Treatments in ICN using Disaggregated Name Components", Anil Jangam,\n  Prakash suthar, Milan Stolic, 2019-09-11,\n  <draft-anilj-icnrg-dnc-qos-icn-01.txt>\n\n      Mechanisms for specifying and implementing end-to-end Quality of\n      service (QoS) treatments in Information-Centric Networks (ICN) has\n      not been explored so far.  There has been some work towards\n      implementing QoS in ICN; however, the discussions are mainly centered\n      around strategies used in efficient forwarding of Interest packets.\n      Moreover, as ICN has been tested mainly as an IP overlay, it\'s QoS is\n      still governed by the IP QoS framework and there is a need for\n      implementing QoS in ICN natively.  This document describes mechanisms\n      to classify and provide associated "name-based" extensions to\n      identify QoS within the framework of ICN\'s core design principles.\n      The name-based design provides a mechanism to carry QoS information\n      and implement the treatments as ICN packets travel across different\n      routers in the ICN network.  Detailed discussion is provided for QoS\n      specific procedures in each of the ICN network elements i.e.\n      consumer, producer and forwarder.\n\n  "Best practices for TLS Downgrade", Brian Sniffen, Mike Bishop, Erik\n  Nygren, Rich Salz, 2019-09-19,\n  <draft-richsalz-httpbis-https-downgrade-02.txt>\n\n      Content providers delivering content via CDNs will sometimes deliver\n      content over HTTPS (or both HTTPS and HTTP) but configure the CDN to\n      pull from the origin over cleartext and unauthenticated HTTP.  From\n      the perspective of a client, it appears that their requests and\n      associated responses are delivered over HTTPS, while in reality their\n      requests are being sent across the network in-the-clear and responses\n      are delivered unauthenticated.  This exposes user request data to\n      pervasive monitoring [RFC7258]; it also means response data may be\n      tampered with by active adversaries.  Terminating TLS connections on\n      a load balancer and contacting a backend over cleartext has long been\n      common within data centers, but doing this TLS termination and\n      downgrade to HTTP at a CDN introduces additional risk when the\n      unprotected traffic is sent over the general Internet, sometimes\n      across national boundaries.\n      \n      While it would be nice to say "never do this," customer demand,\n      content provider use-cases, and market forces today make it\n      impossible for CDNs to not support downgrade.  However, following a\n      set of best practices can provide visibility into when this is\n      happening and can reduce some of the risks.\n\n  "EVPN Multi-Homing Extensions for Split Horizon Filtering", Jorge Rabadan,\n  Kiran Nagaraj, Wen Lin, Ali Sajassi, 2019-11-01,\n  <draft-nr-bess-evpn-mh-split-horizon-02.txt>\n\n      Ethernet Virtual Private Network (EVPN) is commonly used along with\n      Network Virtualization Overlay (NVO) tunnels. The EVPN multi-homing\n      procedures may be different depending on the NVO tunnel type used in\n      the EVPN Broadcast Domain. In particular, there are two multi-homing\n      Split Horizon procedures to avoid looped frames on the multi-homed\n      CE: ESI Label based and Local Bias. ESI Label based Split Horizon is\n      used for MPLSoX tunnels, E.g., MPLSoUDP, whereas Local Bias is used\n      for others, E.g., VXLAN tunnels. The current specifications do not\n      allow the operator to decide which Split Horizon procedure to use for\n      tunnel encapsulations that could support both. Examples of tunnels\n      that may support both procedures are MPLSoGRE, MPLSoUDP, GENEVE or\n      SRv6.sThis document extends the EVPN Multi-Homing procedures so that\n      an operator can decide the Split Horizon procedure for a given NVO\n      tunnel depending on their own requirements.\n\n  "MVPN/EVPN Composite Tunnel", Zhaohui Zhang, Jorge Rabadan, Ali Sajassi,\n  2019-10-29, <draft-zzhang-bess-mvpn-evpn-composite-tunnel-01.txt>\n\n      EVPN E-Tree defines a composite tunnel to be used for a Root PE to\n      simultaneously indicate a non-Ingress-Replication tunnel (e.g., P2MP\n      tunnel) in the transmit direction and an Ingress Replication tunnel\n      in the receive direction for BUM traffic.  This document extends it\n      to more generic use in both MVPN and general EVPN.\n\n  "In Situ OAM Profiles", Tal Mizrahi, Frank Brockners, Shwetha Bhandari,\n  Ramesh Sivakolundu, Carlos Pignataro, Aviv Kfir, Barak Gafni, Mickey\n  Spiegel, Tianran Zhou, John Lemon, 2019-09-11,\n  <draft-mizrahi-ippm-ioam-profile-01.txt>\n\n      In Situ Operations, Administration and Maintenance (IOAM) is used for\n      monitoring network performance and for detecting traffic bottlenecks\n      and anomalies.  This is achieved by incorporating IOAM data into in-\n      flight data packets.  This document introduces the concept of use\n      case-driven IOAM profiles.  An IOAM profile defines a use case or a\n      set of use cases for IOAM, and an associated set of rules that\n      restrict the scope and features of the IOAM specification, thereby\n      limiting it to a subset of the full functionality.  The motivation\n      for defining profiles is to limit the scope of IOAM features,\n      allowing simpler implementation, verification, and interoperability\n      testing in the context of specific use cases that do not require the\n      full functionality of IOAM.\n\n  "YANG Schema Version Selection", Robert Wilton, Reshad Rahman, Joe Clarke,\n  2019-11-02, <draft-wilton-netmod-yang-ver-selection-01.txt>\n\n      This document defines protocol mechanisms to allow clients, using\n      NETCONF or RESTCONF, to choose which YANG schema to use for\n      interactions with a server, out of the available YANG schemas\n      supported by a server.  The provided functionality allow servers to\n      support clients in a backwards compatible way, at the same time\n      allowing for non-backwards-compatible updates to YANG modules.\n      \n      This draft provides a solution to YANG versioning requirements 3.1\n      and 3.2.\n\n  "DCCP Extensions for Multipath Operation with Multiple Addresses", Markus\n  Amend, Eckard Bogenfeld, Anna Brunstrom, Andreas Kassler, Veselin\n  Rakocevic, 2019-11-04, <draft-amend-tsvwg-multipath-dccp-03.txt>\n\n      DCCP communication is currently restricted to a single path per\n      connection, yet multiple paths often exist between peers.  The\n      simultaneous use of these multiple paths for a DCCP session could\n      improve resource usage within the network and, thus, improve user\n      experience through higher throughput and improved resilience to\n      network failure.\n      \n      Multipath DCCP provides the ability to simultaneously use multiple\n      paths between peers.  This document presents a set of extensions to\n      traditional DCCP to support multipath operation.  The protocol offers\n      the same type of service to applications as DCCP and it provides the\n      components necessary to establish and use multiple DCCP flows across\n      potentially disjoint paths.\n\n  "Compact TLS 1.3", Eric Rescorla, Richard Barnes, Hannes Tschofenig,\n  2019-11-04, <draft-rescorla-tls-ctls-03.txt>\n\n      This document specifies a "compact" version of TLS 1.3.  It is\n      isomorphic to TLS 1.3 but saves space by trimming obsolete material,\n      tighter encoding, and a template-based specialization technique. cTLS\n      is not directly interoperable with TLS 1.3, but it should eventually\n      be possible for a cTLS/TLS 1.3 server to exist and successfully\n      interoperate.\n\n  "The Link Layer service in a Quantum Internet", Axel Dahlberg, Matthew\n  Skrzypczyk, Stephanie Wehner, 2019-10-10, <draft-dahlberg-ll-quantum-03.txt>\n\n      In a classical network the link layer is responsible for transferring\n      a datagram between two nodes that are connected by a single link,\n      possibly including switches.  In a quantum network however, the link\n      layer will need to provide a robust entanglement generation service\n      between two quantum nodes which are connected by a quantum link.\n      This service can be used by higher layers to produce entanglement\n      between distant nodes or to perform other operations such as qubit\n      transmission, without full knowledge of the underlying hardware and\n      its parameters.  This draft defines what can be expected from the\n      service provided by a link layer for a Quantum Network and defines an\n      interface between higher layers and the link layer.\n\n  "Enhanced AS Loop Detection for BGP", China Telecom, Di Ma, Yunan Gu,\n  Shunwan Zhuang, Haibo Wang, 2019-11-04,\n  <draft-chen-grow-enhanced-as-loop-detection-03.txt>\n\n      Misconfiguration and malicious manipulation of BGP AS_Path may lead\n      to route hijack.  This document proposes to enhance the BGP Inbound/\n      Outbound route processing in the case of detecting an AS loop.  Two\n      options are proposed for the enhancement, a) a local check at the\n      device; b) data collection/analysis at the remote network controller/\n      server.  Both approaches are beneficial for route hijack detection.\n\n  "Reference Interaction Models for Remote Attestation Procedures", Henk\n  Birkholz, Michael Eckel, 2020-01-07,\n  <draft-birkholz-rats-reference-interaction-model-02.txt>\n\n      This document defines interaction models for basic remote attestation\n      procedures.  Different methods of conveying attestation evidence\n      securely are defined and illustrated.  Analogously, the required\n      information elements used by conveyance protocols are defined and\n      illustrated.\n\n  "Time-Based Uni-Directional Attestation", Andreas Fuchs, Henk Birkholz, Ira\n  McDonald, Carsten Bormann, 2019-09-11, <draft-birkholz-rats-tuda-01.txt>\n\n      This documents defines the method and bindings used to conduct Time-\n      based Uni-Directional Attestation (TUDA) between two RATS (Remote\n      ATtestation procedureS) Principals over the Internet.  TUDA does not\n      require a challenge-response handshake and thereby does not rely on\n      the conveyance of a nonce to prove freshness of remote attestation\n      Evidence.  Conversely, TUDA enables the creation of Secure Audit Logs\n      that can constitute Evidence about current and past operational\n      states of an Attester.  As a prerequisite for TUDA, every RATS\n      Principal requires access to a trusted and synchronized time-source.\n      Per default, in TUDA this is a Time Stamp Authority (TSA) issuing\n      signed Time Stamp Tokens (TST).\n\n  "Revision of the Recall Initiation Model", Moonesamy S, John Klensin,\n  2019-11-09, <draft-moonesamy-recall-rev-03.txt>\n\n      The procedures for initiating a recall specified in RFC 7437 restrict\n      signatories of a recall petition to those who are "nomcom qualified".\n      This document suggests those limitations had unanticipated and\n      undesirable side-effects and proposes to remove them.  It also\n      specifies that remote participants should be allowed to seek redress\n      through the procedures and decreases the number of signatories\n      required for a recall petition.\n      \n      This document updates RFC 7437.\n\n  "rdlink: Robust distributed links to constrained devices", Christian\n  Amsuess, 2019-09-23, <draft-amsuess-t2trg-rdlink-01.txt>\n\n      Thing to thing communication in Constrained RESTful Environments\n      (CoRE) relies on URIs to link to servers.  Next to hierarchical\n      configuration and short-lived IP addresses, this document introduces\n      a naming scheme for devices based on cryptographic identifiers.  A\n      special purpose domain is reserved for expressing those identifiers,\n      and mechanisms for constrained devices to announce their names and to\n      look them up are described.\n\n  "SRv6 Implementation and Deployment Status", Satoru Matsushima, Clarence\n  Filsfils, Zafar Ali, Zhenbin Li, 2020-01-21,\n  <draft-matsushima-spring-srv6-deployment-status-05.txt>\n\n      This draft provides an overview of IPv6 Segment Routing (SRv6)\n      deployment status.  It lists various SRv6 features that have been\n      deployed in the production networks.  It also provides an overview of\n      SRv6 implementation and interoperability testing status.\n\n  "Capabilities and Limitations of an Endpoint-only Security Solution",\n  Arnaud Taddei, Candid Wueest, Kevin Roundy, Dominique Lazanski, 2020-01-09,\n  <draft-taddei-smart-cless-introduction-02.txt>\n\n      In the context of existing, proposed and newly published protocols,\n      this draft RFC is to establish the capabilities and limitations of\n      endpoint-only security solutions and explore benefits and\n      alternatives to mitigate those limits with the support of real case\n      studies.\n\n  "Simplifying Firewall Rules with Network Programming and SRH Metadata", Jim\n  Guichard, Clarence Filsfils, daniel.bernier@bell.ca, Zhenbin Li, Francois\n  Clad, Pablo Camarillo, Ahmed Abdelsalam, 2019-09-23,\n  <draft-guichard-spring-srv6-simplified-firewall-01.txt>\n\n      A clear application of the SRv6 Network Programming model consists in\n      steering, in a stateless manner, packets through a Service Function\n      Chain (SFC).  Each Service Function (SF) is identified by a segment.\n      Each SF can enrich its operation thanks to metadata present in the\n      SRH.\n      \n      This document describes a practical use-case where the SF is a\n      firewall and the metadata helps to drastically decrease the number of\n      rules that need to be maintained by the operation team.\n\n  "Concise Binary Object Representation (CBOR) Tag for Coordinate Reference\n  System (CRS) Specification", Trevor Clarke, 2020-01-06,\n  <draft-clarke-cbor-crs-01.txt>\n\n      The Concise Binary Object Representation (CBOR, RFC 7049) is a data\n      format whose design goals include the possibility of extremely small\n      code size, fairly small message size, and extensibility without the\n      need for version negotiation.\n      \n      In CBOR, one point of extensibility is the definition of CBOR tags.\n      An existing CBOR tag, 103, allows for the representation of\n      geographic coordinates.  Proper exploitation of geographic\n      coordinates requires an associated reference frame.  The present\n      document defines a CBOR tag for referencing the coordinate reference\n      system (CRS) for a geographic coordinate.  It is intended as the\n      reference document for the IANA registration of the CBOR tag defined.\n\n  "Network File System Version 4 Requirements for Computational Storage",\n  Chuck Lever, 2019-08-12, <draft-cel-nfsv4-comp-stor-reqs-01.txt>\n\n      This document introduces an architecture for supporting Computational\n      Storage on Network File System version 4 (NFS) servers and clients.\n\n  "The SODP (Secure Object Delivery Protocol) Server Interfaces: NSA\'s\n  Profile for Delivery of Certificates, CRLs, and Symmetric Keys to Clients",\n  Michael Jenkins, Sean Turner, 2019-08-16, <draft-turner-sodp-profile-04.txt>\n\n      This document specifies protocol interfaces profiled by the US NSA\n      (United States National Security Agency) for NSS (National Security\n      System) servers that provide public key certificates, CRLs\n      (Certificate Revocation Lists), and symmetric keys to NSS clients.\n      Servers that support these interfaces are referred to as SODP (Secure\n      Object Delivery Protocol) servers. The intended audience for this\n      profile comprises developers of client devices that will obtain key\n      management services from NSA-operated SODP servers.  Interfaces\n      supported by SODP servers include: EST (Enrollment over Secure\n      Transport) and its extensions as well as CMC (Certificate Management\n      over CMS (Cryptographic Message Syntax)).\n      \n      This profile applies to the capabilities, configuration, and\n      operation of all components of US National Security Systems (SP 800-\n      59). It is also appropriate for other US Government systems that\n      process high-value information. It is made publicly available for use\n      by developers and operators of these and any other system\n      deployments.\n\n  "Hybrid Post-Quantum Key Encapsulation Methods (PQ KEM) for Transport Layer\n  Security 1.2 (TLS)", Matt Campagna, Eric Crockett, 2019-11-04,\n  <draft-campagna-tls-bike-sike-hybrid-02.txt,.pdf>\n\n      Hybrid key exchange refers to executing two independent key exchanges\n      and feeding the two resulting shared secrets into a Pseudo Random\n      Function (PRF), with the goal of deriving a secret which is as secure\n      as the stronger of the two key exchanges.  This document describes\n      new hybrid key exchange schemes for the Transport Layer Security 1.2\n      (TLS) protocol.  The key exchange schemes are based on combining\n      Elliptic Curve Diffie-Hellman (ECDH) with a post-quantum key\n      encapsulation method (PQ KEM) using the existing TLS PRF.  In\n      particular, this document specifies the use of the Bit Flipping Key\n      Exchange (BIKE) and Supersingular Isogeny Key Exchange (SIKE) schemes\n      in combination with ECDHE as a hybrid key agreement in a TLS 1.2\n      handshake.\n\n  "OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer\n  (DPoP)", Daniel Fett, Brian Campbell, John Bradley, Torsten Lodderstedt,\n  Michael Jones, David Waite, 2019-10-31, <draft-fett-oauth-dpop-03.txt>\n\n      This document describes a mechanism for sender-constraining OAuth 2.0\n      tokens via a proof-of-possession mechanism on the application level.\n      This mechanism allows for the detection of replay attacks with access\n      and refresh tokens.\n\n  "Vehicular Mobility Management for IP-Based Vehicular Networks", Jaehoon\n  Jeong, Yiwen Shen, Zhong Xiang, 2019-11-04,\n  <draft-jeong-ipwave-vehicular-mobility-management-02.txt>\n\n      This document specifies a Vehicular Mobility Management (VMM) scheme\n      for IP-based vehicular networks.  The VMM scheme takes advantage of a\n      vehicular link model based on a multi-link subnet.  With a vehicle\'s\n      mobility information (e.g., position, speed, acceleration/\n      deceleration, and direction) and navigation path (i.e., trajectory),\n      it can provide a moving vehicle with proactive and seamless handoff\n      along with its trajectory.\n\n  "IGMPv3 and MLDv2 Update Survey", Toerless Eckert, Olufemi Komolafe,\n  Hitoshi Asaeda, Timothy Winters, Nicolai Leymann, mankamana mishra, Anish\n  Peter, Suneesh Babu, ramakanthjosyula@gmail.com, 2019-11-03,\n  <draft-eckert-pim-igmp-mld-questionnaire-02.txt>\n\n      The PIM WG intends to progress IGMPv3 and MLDv2 from Proposed\n      Standards to Internet Standards.  This document describes the\n      motivation, procedures and questions proposed for a survey of\n      operators, vendors and implementors of IGMPv3 and MLDv2.  The\n      objective of the survey is to collate information to help the PIM WG\n      progress these protocols to Internet Standards.\n\n  "ACME End User Client and Code Signing Certificates", Kathleen Moriarty,\n  2019-11-17, <draft-moriarty-acme-client-04.txt>\n\n      Automated Certificate Management Environment (ACME) core protocol\n      addresses the use case of web server certificates for TLS.  This\n      document extends the ACME protocol to support end user client, device\n      client, and code signing certificates.\n\n  "Transmission of IPv6 Packets over Overlay Multilink Network (OMNI)\n  Interfaces", Fred Templin, Tony Whyman, 2020-01-27,\n  <draft-templin-atn-aero-interface-13.txt>\n\n      Mobile nodes (e.g., aircraft of various configurations, terrestrial\n      vehicles, seagoing vessels, mobile enterprise devices, etc.)\n      communicate with networked correspondents over multiple access\n      network data links and configure mobile routers to connect end user\n      networks.  A multilink interface specification is therefore needed\n      for coordination with the network-based mobility service.  This\n      document specifies the transmission of IPv6 packets over Overlay\n      Multilink Network (OMNI) Interfaces.\n\n  "IS-IS Optimal Distributed Flooding for Dense Topologies", Russ White,\n  Shraddha Hegde, Shawn Zandi, 2019-09-30, <draft-white-distoptflood-01.txt>\n\n      In dense topologies, such as data center fabrics based on the Clos\n      and butterfly fabric topologies, flooding mechanisms designed for\n      sparse topologies, when used in these dense topologies, can\n      "overflood," or carry too many copies of topology and reachability to\n      fabric devices.  This results in slower convergence times and higher\n      resource utilization.  The modifications to the flooding mechanism in\n      the Intermediate System to Intermediate System (IS-IS) link state\n      protocol described in this document reduce resource utilization to a\n      minimum, while increaseing convergence performance in dense\n      topologies.\n      \n      Note that a Clos fabric is used as the primary example of a desne\n      flooding topology throughout this document.  However, the flooding\n      optimizations described in this document apply to any dense topology.\n\n  "Mathematical Mesh 3.0 Part X: Considerations for Quantum Cryptanalysis\n  Resistance", Phillip Hallam-Baker, 2019-10-23,\n  <draft-hallambaker-mesh-quantum-01.txt>\n\n      The Mathematical Mesh \'The Mesh\' is an infrastructure that\n      facilitates the exchange of configuration and credential data between\n      multiple user devices and provides end-to-end security.  This\n      document describes.\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-quantum.html [1]\n      .\n\n  "Mathematical Mesh 3.0 Part IX: Considerations for Constrained Devices",\n  Phillip Hallam-Baker, 2019-10-23,\n  <draft-hallambaker-mesh-constrained-01.txt>\n\n      The Mathematical Mesh \'The Mesh\' is an infrastructure that\n      facilitates the exchange of configuration and credential data between\n      multiple user devices and provides end-to-end security.  This\n      document describes the\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-constrained.html\n      [1] .\n\n  "Mathematical Mesh 3.0 Part VIII: Cryptographic Algorithms", Phillip\n  Hallam-Baker, 2020-01-16, <draft-hallambaker-mesh-cryptography-05.txt>\n\n      The Mathematical Mesh \'The Mesh\' is an infrastructure that\n      facilitates the exchange of configuration and credential data between\n      multiple user devices and provides end-to-end security.  This\n      document describes the cryptographic algorithm suites used in the\n      Mesh and the implementation of Multi-Party Encryption and Multi-Party\n      Key Generation used in the Mesh.\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-\n      cryptography.html.\n\n  "Mathematical Mesh 3.0 Part VII: Security Considerations", Phillip\n  Hallam-Baker, 2020-01-16, <draft-hallambaker-mesh-security-03.txt>\n\n      The Mathematical Mesh \'The Mesh\' is an end-to-end secure\n      infrastructure that facilitates the exchange of configuration and\n      credential data between multiple user devices.  The core protocols of\n      the Mesh are described with examples of common use cases and\n      reference data.\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-security.html.\n\n  "Mathematical Mesh 3.0 Part V: Protocol Reference", Phillip Hallam-Baker,\n  2020-01-16, <draft-hallambaker-mesh-protocol-04.txt>\n\n      The Mathematical Mesh \'The Mesh\' is an end-to-end secure\n      infrastructure that facilitates the exchange of configuration and\n      credential data between multiple user devices.  The core protocols of\n      the Mesh are described with examples of common use cases and\n      reference data.\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html.\n\n  "Mathematical Mesh 3.0 Part IV: Schema Reference", Phillip Hallam-Baker,\n  2020-01-16, <draft-hallambaker-mesh-schema-05.txt>\n\n      The Mathematical Mesh \'The Mesh\' is an end-to-end secure\n      infrastructure that facilitates the exchange of configuration and\n      credential data between multiple user devices.  The core protocols of\n      the Mesh are described with examples of common use cases and\n      reference data.\n      \n      [Note to Readers]\n      \n      Discussion of this draft takes place on the MATHMESH mailing list\n      (mathmesh@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=mathmesh.\n      \n      This document is also available online at\n      http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html.\n\n  "Abuse-Resistant OpenPGP Keystores", Daniel Gillmor, 2019-08-22,\n  <draft-dkg-openpgp-abuse-resistant-keystore-04.txt>\n\n      OpenPGP transferable public keys are composite certificates, made up\n      of primary keys, direct key signatures, user IDs, identity\n      certifications ("signature packets"), subkeys, and so on.  They are\n      often assembled by merging multiple certificates that all share the\n      same primary key, and are distributed in public keystores.\n      \n      Unfortunately, since many keystores permit any third-party to add a\n      certification with any content to any OpenPGP certificate, the\n      assembled/merged form of a certificate can become unwieldy or\n      undistributable.  Furthermore, keystores that are searched by user ID\n      or fingerprint can be made unusable for specific searches by public\n      submission of bogus certificates.  And finally, keystores open to\n      public submission can also face simple resource exhaustion from\n      flooding with bogus submissions, or legal or other risks from uploads\n      of toxic data.\n      \n      This draft documents techniques that an archive of OpenPGP\n      certificates can use to mitigate the impact of these various attacks,\n      and the implications of these concerns and mitigations for the rest\n      of the OpenPGP ecosystem.\n\n  "Packet Loss Signaling for Encrypted Protocols", Alexandre Ferrieux,\n  Isabelle Hamchaoui, Igor Lubashev, Dmitri Tikhonov, 2020-01-16,\n  <draft-ferrieuxhamchaoui-quic-lossbits-03.txt>\n\n      This document defines an extension to the QUIC transport protocol to\n      allow endpoints to signal packet loss in a way that can be used by\n      network devices to measure and locate the source of the loss.\n      \n      Discussion of this work is encouraged to happen on the QUIC IETF\n      mailing list quic@ietf.org [1] or on the GitHub repository which\n      contains the draft: https://github.com/igorlord/draft-\n      ferrieuxhamchaoui-lossbits [2].\n\n  "ARP/ND Synching And IP Aliasing without IRB", Yubao(Bob) Wang, Zheng\n  Zhang, 2019-11-28, <draft-wang-bess-evpn-arp-nd-synch-without-irb-02.txt>\n\n      This draft proposes an extension to [RFC7432] to do ARP synchronizing\n      and IP aliasing for Layer 3 routes that is needed for pure L3 EVPN to\n      build a complete IP ECMP.  The phrase "pure L3 EVPN" means that there\n      is no MAC-VRF or IRB interface in the use case.\n\n  "DNS over HTTP resolver announcement Using DHCP or Router Advertisements",\n  Thomas Peterson, 2019-10-21, <draft-peterson-doh-dhcp-01.txt>\n\n      This specification describes a DHCP option and Router Advertisement\n      (RA) extension to inform clients of the presence of a DNS over HTTP\n      (DoH) service to be used for DNS queries.\n\n  "Datagram PLPMTUD for UDP Options", Gorry Fairhurst, Tom Jones, 2019-10-02,\n  <draft-fairhurst-tsvwg-udp-options-dplpmtud-01.txt>\n\n      This document specifies how a UDP Options sender implements Datagram\n      Packetization Layer Path Maximum Transmission Unit Discovery\n      (DPLPMTUD) as a robust method for Path Maximum Transmission Unit\n      Discovery.\n\n  "IPv6 Neighbor Discovery on Wireless Networks", Pascal Thubert, 2019-09-26,\n  <draft-thubert-6man-ipv6-over-wireless-04.txt>\n\n      This document describes how the original IPv6 Neighbor Discovery and\n      Wireless ND (WiND) can be applied on various abstractions of wireless\n      media.\n\n  "L3DL Upper Layer Protocol Configuration", Randy Bush, Keyur Patel,\n  2019-11-02, <draft-ymbk-lsvr-l3dl-ulpc-02.txt>\n\n      This document users the Layer 3 Liveness and Discovery protocol to\n      communicate the parameters needed to exchange inter-device Upper\n      Layer Protocol Configuration for upper layer protocols such as the\n      BGP family.\n\n  "YANG Model for IGP Flexible Algorithm", Mobashshera Rasool, Sreekanth S,\n  Mahendra Negi, 2020-01-09, <draft-rasool-lsr-flex-algo-yang-01.txt>\n\n      This document describes a YANG data model for IGP Flexible Algorithm.\n      The model serves as a base framework for configuring and managing\n      Flexible Algorithms which is used by IGPs to compute constraint based\n      paths over the network.\n\n  "ForCES architecture CUSP applicability", Evangelos Haleplidis, Jamal Hadi\n  Salim, 2019-11-04, <draft-haleplidis-bcause-forces-gap-analysis-01.txt>\n\n      This document provides a gap-analysis on how the ForCES architecture\n      meets the requirements for CUSP.  In addition it provides a ForCES\n      XML model that implements the current proposed CUSP information\n      model.\n\n  "Using NETCONF over QUIC connection", Jinyou Dai, Xueshun Wang, Yang Kou,\n  Lifen Zhou, 2019-10-28, <draft-dai-quic-netconf-01.txt>\n\n      The Network Configuration Protocol (NETCONF) provides mechanisms to\n      install, manipulate, and delete the configuration of network devices.\n      At present, almost all implementations of NETCONF are based on TCP\n      protocol. QUIC, a new UDP-based transport protocol, can facilitate to\n      improve the transportation performance when being used as an\n      infrastructure layer of NETCONF.   This document describes how to use\n      the QUIC protocol as the transport   protocol of\n      NETCONF(NETCONFoQUIC).\n\n  "In-Network Computing for App-Centric Micro-Services", Chathura\n  Sarathchandra, Dirk Trossen, Michael Boniface, 2019-10-30,\n  <draft-sarathchandra-coin-appcentres-01.txt>\n\n      The application-centric deployment of \'Internet\' services has\n      increased over the past ten years with many million applications\n      providing user-centric services, executed on increasingly more\n      powerful smartphones that are supported by Internet-based cloud\n      services in distributed data centres, the latter mainly provided by\n      large scale players such as Google, Amazon and alike. This draft\n      outlines a vision of evolving those data centres towards executing\n      app-centric micro-services; we dub this evolved data centre as an\n      AppCentre. Complemented with the proliferation of such AppCentres at\n      the edge of the network, they will allow for such micro-services to\n      be distributed across many places of execution, including mobile\n      terminals themselves, while specific micro-service chains equal\n      today\'s applications in existing smartphones. We outline the key\n      enabling technologies that needs to be provided for such evolution to\n      be realized, including references to ongoing IETF work in some\n      areas.\n\n  "Link relationship types for authentication", Evert Pot, 2019-10-02,\n  <draft-pot-authentication-link-01.txt>\n\n      This specification defines a set of relationships that may be used to\n      indicate where a user may authenticate, log out, register a new\n      account or find out who is currently authenticated.\n\n  "The WebTransport Protocol Framework", Victor Vasiliev, 2019-11-03,\n  <draft-vvv-webtransport-overview-01.txt>\n\n      The WebTransport Protocol Framework enables clients constrained by\n      the Web security model to communicate with a remote server using a\n      secure multiplexed transport.  It consists of a set of individual\n      protocols that are safe to expose to untrusted applications, combined\n      with a model that allows them to be used interchangeably.\n      \n      This document defines the overall requirements on the protocols used\n      in WebTransport, as well as the common features of the protocols,\n      support for some of which may be optional.\n\n  "WebTransport over QUIC", Victor Vasiliev, 2019-11-03,\n  <draft-vvv-webtransport-quic-01.txt>\n\n      WebTransport [OVERVIEW] is a protocol framework that enables clients\n      constrained by the Web security model to communicate with a remote\n      server using a secure multiplexed transport.  This document describes\n      QuicTransport, a transport protocol that uses a dedicated QUIC [QUIC]\n      connection and provides support for unidirectional streams,\n      bidirectional streams and datagrams.\n\n  "WebTransport over HTTP/3", Victor Vasiliev, 2019-11-03,\n  <draft-vvv-webtransport-http3-01.txt>\n\n      WebTransport [OVERVIEW] is a protocol framework that enables clients\n      constrained by the Web security model to communicate with a remote\n      server using a secure multiplexed transport.  This document describes\n      Http3Transport, a WebTransport protocol that is based on HTTP/3\n      [HTTP3] and provides support for unidirectional streams,\n      bidirectional streams and datagrams, all multiplexed within the same\n      HTTP/3 connection.\n\n  "BGP-LS Filters : A Framework for Network Slicing and Enhanced VPNs", John\n  Drake, Adrian Farrel, Luay Jalil, Avinash Lingala, 2019-11-04,\n  <draft-drake-bess-enhanced-vpn-02.txt>\n\n      Future networks that support advanced services, such as those enabled\n      by 5G mobile networks, envision a set of overlay networks each with\n      different performance and scaling properties.  These overlays are\n      known as network slices and are realized over a common underlay\n      network.\n      \n      In order to support network slicing, as well as to offer enhanced VPN\n      services in general, it is necessary to define a mechanism by which\n      specific resources (links and/or nodes) of an underlay network can be\n      used by a specific network slice, VPN, or set of VPNs.  This document\n      sets out such a mechanism for use in Segment Routing networks.\n\n  "An IPv6 stateless interface identifier generation method based on\n  geographic location coding", Pei Zhang, Qianli Zhang, Dandan Li, Yan Ma,\n  Kun Xie, 2019-09-23, <draft-zhang-6man-ipv6-geoiid-01.txt>\n\n      This document describes how to generate a stateless IPv6 host\n      interface identifier based on host geographic location information.\n      This method can guarantee the uniqueness and stability of the address\n      generated within a certain geographical range. The method is similar\n      to mechanism introduced in RFC 7217, but remains stable within an\n      adjustable geographical area.\n\n  "Service Oriented Internet Protocol", Brian Carpenter, Sheng Jiang,\n  Guangpeng Li, 2019-10-28, <draft-jiang-service-oriented-ip-02.txt>\n\n      This document proposes a new, backwards-compatible, approach to\n      packet forwarding, where the service required rather than the IP\n      address required acts as the vector for routing packets at the edge\n      of the network.  Deeper in the network, the mechanism can interface\n      to conventional and future methods of service or application aware\n      networking.\n\n  "Public Key Authenticated Encryption for JOSE: ECDH-1PU", Neil Madden,\n  2019-08-13, <draft-madden-jose-ecdh-1pu-02.txt>\n\n      This document describes the ECDH-1PU public key authenticated\n      encryption algorithm for JWE.  The algorithm is similar to the\n      existing ECDH-ES encryption algorithm, but adds an additional ECDH\n      key agreement between static keys of the sender and recipient.  This\n      additional step allows the recipient to be assured of sender\n      authenticity without requiring a nested signed-then-encrypted message\n      structure.\n\n  "Shared Use of Experimental Hop-by-Hop and Destination Options", Tom\n  Herbert, 2019-08-20, <draft-herbert-6man-exp-opts-02.txt>\n\n      This document describes how the experimental IPv6 Hop-by-Hop and\n      Destinations Option types can concurrently support different\n      experimental options. This is accomplished by employing a format in\n      the Option Data for experimental option types. The format contains an\n      experiment identifier that indicates an experimental option contained\n      in the trailing Option Data. This approach is robust to experiments\n      that are not registered and to those that do not use this sharing\n      mechanism. It is recommended for all new Destination and Hop-by-Hop\n      options that use experimental codepoints.\n\n  "Use of the Walnut Digital Signature Algorithm with CBOR Object Signing and\n  Encryption (COSE)", Derek Atkins, 2019-12-20,\n  <draft-atkins-suit-cose-walnutdsa-02.txt>\n\n      This document specifies the conventions for using the Walnut Digital\n      Signature Algorithm (WalnutDSA) for digital signatures with the CBOR\n      Object Signing and Encryption (COSE) syntax.  WalnutDSA is a\n      lightweight, quantum-resistant signature scheme based on Group\n      Theoretic Cryptography with implementation and computational\n      efficiency of signature verification in constrained16807\n      environments, even on 8- and 16-bit platforms.\n      \n      The goal of this publication is to document a way to use the\n      lightweight, quantum-resistant WalnutDSA signature algorithm in COSE\n      in a way that would allow multiple developers to build compatible\n      implementations.\n\n  "IS-IS Extensions To Support The IPv6 Compressed Routing Header (CRH)",\n  Parag Kaneriya, Rejesh Shetty, Shraddha Hegde, Ron Bonica, 2019-11-04,\n  <draft-bonica-lsr-crh-isis-extensions-01.txt>\n\n      Source nodes can use the IPv6 Compressed Routing Header (CRH) to\n      steer packets through a specified path.  This document defines IS-IS\n      extensions that support the CRH.\n\n  "Coordinating Attack Response at Internet Scale 2 (CARIS2) Workshop\n  Report", Kathleen Moriarty, 2019-12-02, <draft-moriarty-caris2-02.txt>\n\n      The Coordinating Attack Response at Internet Scale (CARIS) 2 workshop\n      workshop [CARISEvent], sponsored by the Internet Society, took place\n      28 February and 1 March 2019 in Cambridge, Massachusetts, USA.\n      Participants spanned regional, national, international, and\n      enterprise CSIRTs, operators, service providers, network and security\n      operators, transport operators and researchers, incident response\n      researchers, vendors, and participants from standards communities.\n      This workshop continued the work started at the first CARIS workshop,\n      with a focus for CARIS 2 scaling incident prevention and detection as\n      the Internet industry moves to a stronger and a more ubiquitous\n      deployment of session encryption.\n\n  "Transactional Authorization", Justin Richer, 2019-12-13,\n  <draft-richer-transactional-authz-04.txt>\n\n      This document defines a mechanism for delegating authorization to a\n      piece of software, and conveying that delegation to the software.\n\n  "Reliable and Available Wireless Technologies", Pascal Thubert, Dave\n  Cavalcanti, Xavier Vilajosana, Corinna Schmitt, 2020-01-06,\n  <draft-thubert-raw-technologies-04.txt>\n\n      This document presents a series of recent technologies that are\n      capable of time synchronization and scheduling of transmission,\n      making them suitable to carry time-sensitive flows with high\n      reliability and availbility.\n\n  "LOOPS Generic Information Set", Michael Welzl, Carsten Bormann,\n  2019-11-04, <draft-welzl-loops-gen-info-02.txt>\n\n      LOOPS (Local Optimizations on Path Segments) aims to provide local\n      (not end-to-end but in-network) recovery of lost packets to achieve\n      better data delivery in the presence of losses.\n      [I-D.li-tsvwg-loops-problem-opportunities] provides an overview over\n      the problems and optimization opportunities that LOOPS could address.\n      \n      The present document is a strawman for the set of information that\n      would be interchanged in a LOOPS protocol, without already defining a\n      specific data packet format.\n      \n      The generic information set needs to be mapped to a specific\n      encapsulation protocol to actually run the LOOPS optimizations.  The\n      current version of this document contains sketches of bindings to GUE\n      [I-D.ietf-intarea-gue] and Geneve [I-D.ietf-nvo3-geneve].\n\n  "Reporting Progress of Long-Running Operations in HTTP", Austin Wright,\n  2019-11-21, <draft-wright-http-progress-02.txt>\n\n      This document defines a mechanism for following the real-time\n      progress of long-running operations over HTTP.\n\n  "YANG Data Model for Segment Routing Policy", Kamran Raza, Robert Sawaya,\n  Zhuang Shunwan, Daniel Voyer, Muhammad Durrani, Satoru Matsushima, Vishnu\n  Beeram, 2019-11-04, <draft-raza-spring-sr-policy-yang-02.txt>\n\n      This document defines a YANG data model for Segment Routing (SR)\n      Policy that can be used for configuring, instantiating, and managing\n      SR policies.  The model is generic and apply equally to the MPLS and\n      SRv6 instantiations of SR policies.\n\n  "The China Mobile, Huawei, and ZTE BNG Simple Control and User Plane\n  Separation Protocol (S-CUSP)", Shujun Hu, Donald Eastlake, Fengwei Qin, Tee\n  Chua, Daniel Huang, 2019-10-19,\n  <draft-chz-simple-cu-separation-bng-protocol-06.txt>\n\n      A Broadband Network Gateway (BNG) in a fixed wireline access network\n      is an Ethernet-centric IP edge router and the aggregation point for\n      subscriber traffic. Control Plane (CP) and User Plane (UP) Separation\n      (CUPS) for such a BNG improves flexibility and scalability but\n      requires various communication between the UP and the CP.  China\n      Mobile, Huawei Technologies, and ZTE have developed a simple CUPS\n      control channel Protocol (S-CUSP) to support such communication.\n      \n      This document is not an IETF standard and does not have IETF\n      consensus.  S-CUSP is presented here to make its specification\n      conveniently available to the Internet community to enable diagnosis\n      and interoperability.\n\n  "Asymmetric IPv6 for IoT Networks", Sheng Jiang, Guangpeng Li, Brian\n  Carpenter, 2019-10-28, <draft-jiang-asymmetric-ipv6-02.txt>\n\n      This document describes a new approach to IPv6 header compression for\n      use in scenarios where minimizing packet size is crucial but routing\n      performance must be maximised.\n\n  "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS\n  Traffic Engineering", Mach Chen, Les Ginsberg, Stefano Previdi, Xiaodong\n  Duan, 2019-12-02, <draft-chen-lsr-isis-rfc5316bis-01.txt>\n\n      This document describes extensions to the Intermediate System to\n      Intermediate System (IS-IS) protocol to support Multiprotocol Label\n      Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering\n      (TE) for multiple Autonomous Systems (ASs).  It defines IS-IS\n      extensions for the flooding of TE information about inter-AS links,\n      which can be used to perform inter-AS TE path computation.\n      \n      No support for flooding information from within one AS to another AS\n      is proposed or defined in this document.\n      \n      This document obsoletes RFC 5316.\n\n  "Use Cases and Requirements for QUIC as a Substrate", Mirja Kuehlewind,\n  Zaheduzzaman Sarker, Thomas Fossati, Lucas Pardue, 2019-11-04,\n  <draft-kuehlewind-quic-substrate-02.txt>\n\n      TCP is often used as a proxying or tunneling protocol.  QUIC is a\n      new, emerging transport protocol and there is a similar expectation\n      that it too will be used as a substrate once it is widely deployed.\n      Using QUIC instead of TCP in existing scenarios will allow proxying\n      and tunneling services to maintain the benefits of QUIC natively,\n      without degrading the performance and security characteristics.  QUIC\n      also opens up new opportunities for these services to have lower\n      latency and better multistreaming support.  This document summarizes\n      current and future usage scenarios to derive requirements for QUIC\n      and to provide additional protocol considerations.\n\n  "New IPv6 Multicast Addresses for Switch ML", Hemant Singh, 2019-12-09,\n  <draft-hsingh-ipv6-coin-ml-03.txt>\n\n      Recently, in-network aggregation to scale distributed machine\n      learning (ML) has been presented.  A network switch implementation\n      uses IPv4 broadcast messages from switch to the hosts to send updates\n      to all workers.  IPv6 does not support broadcast addresses.  This\n      document proposes, IPv6 implementations use the IPv6 link-local all-\n      nodes multicast address, until a new IPv6 link-local multicast\n      address is assigned by IANA for switch to hosts multicast\n      communications.\n\n  "Security Considerations for SRv6 Networks", Cheng Li, Zhenbin Li,\n  Chongfeng Xie, Hui Tian, Jianwei Mao, 2019-11-04,\n  <draft-li-spring-srv6-security-consideration-03.txt>\n\n      SRv6 inherits potential security vulnerabilities from Source Routing\n      in general, and also from IPv6.  This document describes various\n      threats and security concerns related to SRv6 networks and existing\n      approaches to solve these threats.\n\n  "The Cooperative Communication Method of the Converged Multi-media Wireless\n  Resource Management Network", Yi Liu, 2019-11-29, <draft-liu-mwrmn-01.txt>\n\n      This paper describes a cooperative communication method of\n      theconverged multi-media wireless resource management network.It can\n      maximize the utilization of heterogeneous network resources and\n      optimize the access to wireless resources of the network in the form\n      of Mesh, which solves the problem of collaborative wireless resource\n      management in multi-media converged networks.  Through the overall\n      consideration of multi-media converged networks including wired\n      network, wireless network, broadband network, and narrowband network,\n      joint access control and resource scheduling for network devices with\n      different characteristics in heterogeneous networks are realized.\n\n  "RIFT Applicability", Yuehua Wei, Zheng Zhang, Dmitry Afanasiev, Tom\n  Verhaeg, Jaroslaw Kowalczyk, 2019-11-04,\n  <draft-wei-rift-applicability-02.txt>\n\n      This document discusses the properties, applicability and operational\n      considerations of RIFT in different network scenarios.  It intends to\n      provide a rough guide how RIFT can be deployed to simplify routing\n      operations in Clos topologies and their variations.\n\n  "Design of the native Cyberspace Map", Jilong Wang, Shuying Zhuang, Miao\n  Congcong, Changqing An, 2019-12-13,\n  <draft-jilongwang-opsawg-cybersmap-01.txt>\n\n      This memo discusses the design of the native cyberspace map which is\n      stable and flexible to describe cyberspace.  Although we have\n      accepted the cyberspace as a parallel new world, we even have not\n      defined its basic coordinate system, which means cyberspace have no\n      its basic space dimension till now.  The objective of this draft is\n      to illustrate the basic design methodology of the native coordinate\n      system of cyberspace and show how to design a cyberspace map on this\n      basis.\n\n  "Exploiting Packet Replication and Elimination in Complex Tracks in LLNs",\n  Georgios Papadopoulos, Remous-Aris Koutsiamanis, Nicolas Montavont, Pascal\n  Thubert, 2020-01-02, <draft-papadopoulos-raw-pareo-reqs-01.txt>\n\n      The Packet Replication and Elimination (PRE) mechanism duplicates\n      data packets into several paths in the network to increase\n      reliability and provide low jitter.  PRE may be used to complement\n      layer-2 Automatic Repeat reQuest (ARQ) and receiver-end Ordering to\n      form the PAREO functions.  Over a wireless medium, this technique can\n      take advantage of communication Overhearing, when parallel\n      transmissions over two adjacent paths are scheduled.  This document\n      presents the concept and details the required changes to the current\n      specifications that will be necessary to enable the PAREO functions.\n\n  "IETF Meeting Network Requirements", Karen O\'Donoghue, Robert Hinden,\n  2019-11-04, <draft-odonoghue-netrqmts-02.txt>\n\n      The IETF Meeting Network has become integral to the success of any\n      physical IETF meeting.  Building such a network, which provides\n      service to thousands of heavy users and their multitude of devices,\n      spread throughout the event venue, with very little time for setup\n      and testing is a challenge.  This document provides a set of\n      requirements, derived from hard won experience, as an aid to anyone\n      involved in designing and deploying such future networks.\n\n  "Extensible Provisioning Protocol (EPP) Secure Authorization Information\n  for Transfer", James Gould, Richard Wilhelm, 2020-01-14,\n  <draft-gould-regext-secure-authinfo-transfer-03.txt>\n\n      The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the\n      use of authorization information to authorize a transfer.  The\n      authorization information is object-specific and has been defined in\n      the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact\n      Mapping, in RFC 5733, as password-based authorization information.\n      Other authorization mechanisms can be used, but in practice the\n      password-based authorization information has been used at the time of\n      object create, managed with the object update, and used to authorize\n      an object transfer request.  What has not been fully considered is\n      the security of the authorization information that includes the\n      complexity of the authorization information, the time-to-live (TTL)\n      of the authorization information, and where and how the authorization\n      information is stored.  This document defines an operational\n      practice, using the EPP RFCs, that leverages the use of strong random\n      authorization information values that are short-lived, that are not\n      stored by the client, and that are stored using a cryptographic hash\n      by the server to provide for secure authorization information used\n      for transfers.\n\n  "GOST R 34.12-2015: Block Cipher "Magma"", Vasily Dolmatov, Dmitry\n  Eremin-Solenikov, 2019-11-17, <draft-dolmatov-magma-05.txt>\n\n      In addition to a new cipher with block length of n=128 bits (referred\n      to as "Kyznyechik" and described in RFC 7801) Russian Federal\n      standard GOST R 34.12-2015 includes an updated version of the block\n      cipher with block length of n=64 bits and key length k=256 bits,\n      which is also referred to as "Magma".  The algorithm is an updated\n      version of an older block cipher with block length of n=64 bits\n      described in GOST 28147-89 (RFC 5830).  This document is intended to\n      be a source of information about the updated version of the 64-bit\n      cipher.  It may facilitate the use of the block cipher in Internet\n      applications by providing information for developers and users of\n      GOST 64-bit cipher with the revised version of the cipher for\n      encryption and decryption.\n\n  "A Framework for Constructing Service Function Chaining Systems Based on\n  Segment Routing", Cheng Li, Ahmed El Sawaf, Ruizhao Hu, Zhenbin Li,\n  2019-11-04, <draft-li-spring-sr-sfc-control-plane-framework-01.txt>\n\n      Segment Routing (SR) allows for a flexible definition of end-to-end\n      paths by encoding paths as sequences of topological sub-paths, called\n      "segments".  Segment routing architecture can be implemented over an\n      MPLS data plane as well as an IPv6 data plane.\n      \n      Service Function Chaining (SFC) provides support for the creation of\n      composite services that consist of an ordered set of Service\n      Functions (SF) that are to be applied to packets and/or frames\n      selected as a result of classification.\n      \n      SFC can be implemented based on several technologies, such as Network\n      Service Header (NSH) and SR.  This document describes a framework for\n      constructing SFC based on Segment Routing.  The document reviews the\n      control plane solutions for route distribution of service function\n      instance and service function path, and steering packets into a\n      service function chain.\n\n  "Multicast-only Fast Reroute Based on Topology Independent Loop-free\n  Alternate Fast Reroute", Yisong Liu, Mike McBride, 2019-11-23,\n  <draft-liu-pim-mofrr-tilfa-01.txt>\n\n      Multicast-only Fast Reroute (MoFRR) has been defined in [RFC7431],\n      but the selection of the secondary multicast next hop only according\n      to the loop-free alternate fast reroute, which has restrictions in\n      multicast deployments. This document describes a mechanism for\n      Multicast-only Fast Reroute by using Topology Independent Loop-free\n      Alternate fast reroute, which is independent of network topology and\n      can achieve covering more network environments.\n\n  "IS-IS Flooding Speed advertisement", Bruno Decraene, Chris Bowers, Jayesh\n  J, Tony Li, Gunter Van de Velde, 2020-01-06,\n  <draft-decraene-lsr-isis-flooding-speed-02.txt>\n\n      This document proposes a mechanism that can be used to increase the\n      speed at which link state information is flooded across a network\n      when multiple LSPDUs need to be flooded, such as in case of a node\n      failure.  It also reduces the likelihood of overloading the\n      downstream flooding neighbors.  This document defines a new TLV to be\n      advertised in IS-IS Hello messages.  This TLV carries two parameters\n      indicating the performance capacity to receive LSPDUs: the minimum\n      delay between two consecutive LSPDUs and the number of LSPDUs which\n      can the received back to back.\n\n  "TLS Metadata for Load Balancers", Benjamin Schwartz, 2019-10-31,\n  <draft-schwartz-tls-lb-02.txt>\n\n      A load balancer that does not terminate TLS may wish to provide some\n      information to the backend server, in addition to forwarding TLS\n      data.  This draft proposes a protocol between load balancers and\n      backends that enables secure, efficient delivery of TLS with\n      additional information.  The need for such a protocol has recently\n      become apparent in the context of split mode ESNI.\n\n  "Guidelines for Internet Congestion Control at Endpoints", Gorry Fairhurst,\n  2019-11-03, <draft-fairhurst-tsvwg-cc-04.txt>\n\n      This document provides guidance on the design of methods to avoid\n      congestion collapse and to provide congestion control.\n      Recommendations and requirements on this topic are distributed across\n      many documents in the RFC series.  This therefore seeks to gather and\n      consolidate these recommendations and provide overall guidance.  It\n      is intended to provide input to the design of new congestion control\n      methods in protocols, such as the IETF Quick UDP Internet Connections\n      (QUIC) transport.\n      \n      The present document is for discussion and comment by the IETF.  If\n      published, it plans to update or replace the Best Current Practice in\n      BCP 41, which currently includes "Congestion Control Principles"\n      provided in RFC2914.\n\n  "BIER IPv6 Encapsulation (BIERv6) Support via IS-IS", Jingrong Xie, Aijun\n  Wang, Gang Yan, Senthil Dhanaraj, 2020-01-13,\n  <draft-xie-bier-ipv6-isis-extension-01.txt>\n\n      This document defines IS-IS extensions to support multicast\n      forwarding using the Bit Index Explicit Replication (BIER) with IPv6\n      encapsulation (BIERv6).\n\n  "TCP ACK Pull", Carles Gomez, Jon Crowcroft, 2019-11-04,\n  <draft-gomez-tcpm-ack-pull-01.txt>\n\n      Delayed Acknowledgments (ACKs) allow reducing protocol overhead in\n      many scenarios.  However, in some cases, Delayed ACKs may\n      significantly degrade network and device performance in terms of link\n      utilization, latency, memory usage and/or energy consumption.  This\n      document defines the TCP ACK Pull (AKP) mechanism, which allows a\n      sender to request the ACK for a data segment to be sent without\n      additional delay by the receiver.  AKP makes use of one of the\n      reserved bits in the TCP header, which is defined in this\n      specification as the AKP flag.\n\n  "Requirement and Solution for Multicast Traffic Telemetry", Haoyu Song,\n  Mike McBride, Gregory Mirsky, 2019-11-01,\n  <draft-song-multicast-telemetry-01.txt>\n\n      This document discusses the requirement of on-path telemetry for\n      multicast traffic.  The existing solutions are examined and their\n      issues are addressed with new modifications that adapt to the\n      multicast scenario.\n\n  "Support Postcard-Based Telemetry for SRv6 OAM", Haoyu Song, 2019-10-14,\n  <draft-song-6man-srv6-pbt-01.txt>\n\n      Applications such as SRv6 TE may require to collect detailed\n      performance data on SR paths.  Existing in-situ OAM techniques incur\n      encapsulation and header overhead issues.  This document describes a\n      method based on Postcard-based Telemetry with Packet Marking for SRv6\n      on-path OAM, which avoids the extra overhead for encapsulating\n      telemetry-related instruction and metadata in SRv6 packets.\n\n  "Deterministic Networking (DetNet) Controller Plane Framework", Andrew\n  Malis, Xuesong Geng, Mach Chen, Fengwei Qin, 2020-01-20,\n  <draft-malis-detnet-controller-plane-framework-03.txt>\n\n      This document provides a framework overview for the Deterministic\n      Networking (DetNet) controller plane.  It discusses concepts and\n      requirements that will be basis for Detnet controller plane solution\n      documents.\n\n  "The Some Congestion Experienced ECN Codepoint", Jonathan Morton, Rodney\n  Grimes, 2019-11-04, <draft-morton-tsvwg-sce-01.txt>\n\n      This memo reclassifies ECT(1) to be an early notification of\n      congestion on ECT(0) marked packets, which can be used by AQM\n      algorithms and transports as an earlier signal of congestion than CE.\n      It is a simple, transparent, and backward compatible upgrade to\n      existing IETF-approved AQMs, RFC3168, and nearly all congestion\n      control algorithms.\n\n  "QUIC for SATCOM", Nicolas Kuhn, Gorry Fairhurst, John Border, Stephan\n  Emile, 2020-01-16, <draft-kuhn-quic-4-sat-03.txt>\n\n      QUIC has been designed for use across Internet paths.  Initial\n      designs of QUIC have focussed on common deployment scenarios for web\n      traffic and have not focussed on the performance when using a path\n      with a large Bandwidth-Delay Product (BDP).  A path can combine\n      satellites network segment together with a wide variety of other\n      network technologies (Ethernet, cable modems, WiFi, cellular, radio\n      links, etc): this complicates the characteristics of the end-to-end\n      path.  One example of such a scenario occurs when a satellite\n      communication (SATCOM) system is used to provide all or a part of the\n      end-to-end path.  If this is not addressed, the end-to-end quality of\n      experience can be degraded.\n      \n      This memo identifies the characteristics of a SATCOM link that impact\n      the operation of the QUIC transport protocol.  It proposes regression\n      tests to evaluate QUIC over SATCOM links.  It discusses how to ensure\n      acceptable protocol performance.\n\n  "Updated YANG Module Revision Handling", Benoit Claise, Joe Clarke, Reshad\n  Rahman, Robert Wilton, Balazs Lengyel, Jason Sterne, Kevin D\'Souza,\n  2019-10-15, <draft-verdt-netmod-yang-module-versioning-01.txt>\n\n      This document specifies a new YANG module update procedure that can\n      document when non-backwards-compatible changes have occurred during\n      the evolution of a YANG module.  It extends the YANG import statement\n      with an earliest revision filter to better represent inter-module\n      dependencies.  It provides help and guidelines for managing the\n      lifecycle of YANG modules and individual schema nodes.  This document\n      updates RFC 7950, RFC 8407 and RFC 8525.\n\n  "Network Device Attestation Workflow", Guy Fedorkow, Jessica\n  Fitzgerald-McKay, 2019-11-05,\n  <draft-fedorkow-rats-network-device-attestation-01.txt>\n\n      This document describes a workflow for network device attestation.\n\n  "Carrying SID Algorithm information in PCE-based Networks.", Alexej Tokar,\n  Siva Sivabalan, Mahendra Negi, 2019-12-31, <draft-tokar-pce-sid-algo-01.txt>\n\n      The Algorithm associated with a prefix Segment-ID (SID) defines the\n      path computation Algorithm used by Interior Gateway Protocols (IGPs).\n      This information is available to controllers such as the Path\n      Computation Element (PCE) via topology learning.  This document\n      proposes an approach for informing headend routers regarding the\n      Algorithm associated with each prefix SID used in PCE-computed paths,\n      as well as signalling a specific SID algorithm as a constraint to the\n      PCE.\n\n  "Avoid IP fragmentation in DNS", Kazunori Fujiwara, Paul Vixie, 2019-09-27,\n  <draft-fujiwara-dnsop-avoid-fragmentation-01.txt>\n\n      Path MTU discovery remains widely undeployed due to security issues,\n      and IP fragmentation has exposed weaknesses in application protocols.\n      Currently, DNS is known to be the largest user of IP fragmentation.\n      It is possible to avoid IP fragmentation in DNS by limiting response\n      size where possible, and signaling the need to upgrade from UDP to\n      TCP transport where necessary.  This document proposes to avoid IP\n      fragmentation in DNS.\n\n  "Main logging schema for qlog", Robin Marx, 2019-10-14,\n  <draft-marx-qlog-main-schema-01.txt>\n\n      This document describes a high-level schema for a standardized\n      logging format called qlog.  This format allows easy sharing of data\n      and the creation of reusable visualization and debugging tools.  The\n      high-level schema in this document is intended to be protocol-\n      agnostic.  Separate documents specify how the format should be used\n      for specific protocol data.\n\n  "QUIC and HTTP/3 event definitions for qlog", Robin Marx, 2019-10-14,\n  <draft-marx-qlog-event-definitions-quic-h3-01.txt>\n\n      This document describes concrete qlog event definitions and their\n      metadata for QUIC and HTTP/3-related events.  These events can then\n      be embedded in the higher level schema defined in [QLOG-MAIN].\n\n  "The Use of Path Segment in SR Inter-domain Scenarios", Quan Xiong, Gregory\n  Mirsky, Weiqiang Cheng, 2019-10-17,\n  <draft-xiong-spring-path-segment-sr-inter-domain-01.txt>\n\n      This document discusses the inter-domain scenarios for SR-MPLS\n      networks and proposes the solution with the use of path segments.\n\n  "The Use of Path Segment in SR-MPLS and MPLS Interworking", Quan Xiong,\n  Gregory Mirsky, Weiqiang Cheng, 2019-10-17,\n  <draft-xiong-mpls-path-segment-sr-mpls-interworking-01.txt>\n\n      This document discusses the SR-MPLS and MPLS interworking scenarios\n      and proposes the solution with the use of path segments.\n\n  "Inter-Domain Multicast Deployment using BIERv6", Liang Geng, Jingrong Xie,\n  Mike McBride, Gang Yan, 2020-01-13,\n  <draft-geng-bier-ipv6-inter-domain-01.txt>\n\n      Bit Index Explicit Replication IPv6 encapsulation (BIERv6) introduces\n      an approach to use IPv6 extension header to carry BIER header with\n      IPv6 unicast address as destination address.  It provides the ability\n      to replicate a packet from one router to another router in a\n      different domain as well as in the same domain.  This document\n      introduces the techniques for multicast deployment across multiple\n      domains using BIERv6, and demonstrate how BIERv6 is beneficial for\n      such deployment.\n\n  "PMS/Head-end based MPLS Ping and Traceroute in Inter-AS SR Networks",\n  Shraddha Hegde, Kapil Arora, Samson Ninan, Mukul Srivastava, Nagendra\n  Kumar, 2019-11-04, <draft-ninan-spring-mpls-inter-as-oam-02.txt>\n\n      Segment Routing (SR) architecture leverages source routing and\n      tunneling paradigms and can be directly applied to the use of a\n      Multiprotocol Label Switching (MPLS) data plane.  Segment Routing\n      also provides an easy and efficient way to provide inter connectivity\n      in a large scale network as described in [RFC8604].  [RFC8287]\n      illustrates the problem and defines extensions to perform LSP Ping\n      and Traceroute for Segment Routing IGP-Prefix and IGP-Adjacency\n      Segment Identifiers (SIDs) with an MPLS data plane.  It is useful to\n      have the LSP Ping and traceroute procedures when an SR end-to-end\n      path spans across multiple ASes.  This document describes mechanisms\n      to facilitae LSP ping and traceroute in inter-AS SR networks in an\n      efficient manner with simple OAM protocol extension which uses\n      dataplane forwarding alone for sending Echo-Reply.\n\n  "Advertising L2 Bundle Member Link Attributes in OSPF", Ketan Talaulikar,\n  Peter Psenak, 2020-01-06, <draft-ketant-lsr-ospf-l2bundles-01.txt>\n\n      There are deployments where the Layer 3 interface on which OSPF\n      operates is a Layer 2 interface bundle.  Existing OSPF advertisements\n      only support advertising link attributes of the Layer 3 interface.\n      If entities external to OSPF wish to control traffic flows on the\n      individual physical links which comprise the Layer 2 interface bundle\n      link attribute information about the bundle members is required.\n      \n      This document introduces the ability for OSPF to advertise the link\n      attributes of layer 2 (L2) Bundle members.\n\n  "Industrial Use Cases for In-Network Computing", Ike Kunze, Klaus Wehrle,\n  2019-11-04, <draft-kunze-coin-industrial-use-cases-01.txt>\n\n      Cyber-physical systems and the Industrial Internet of Things are\n      characterized by diverse sets of requirements which can hardly be\n      satisfied using standard networking technology.  One example are\n      latency-critical computations which become increasingly complex and\n      are consequently outsourced to more powerful cloud platforms for\n      feasibility reasons.  The intrinsic physical propagation delay to\n      these remote sites can, however, already be too high for given\n      requirements.  The challenge is to develop techniques that bring\n      together these requirements.  Utilizing available computational\n      capabilities within the network can be a solution to this challenge\n      which makes in-network computing concepts a promising starting point.\n      This document discusses select industrial use cases to demonstrate\n      how in-network computing concepts can be applied to the industrial\n      domain and to point out essential requirements of industrial\n      applications.\n\n  "RAW use cases", Georgios Papadopoulos, Pascal Thubert, Fabrice Theoleyre,\n  Carlos Bernardos, 2019-11-04, <draft-bernardos-raw-use-cases-01.txt>\n\n      The wireless medium presents significant specific challenges to\n      achieve properties similar to those of wired deterministic networks.\n      At the same time, a number of use cases cannot be solved with wires\n      and justify the extra effort of going wireless.  This document\n      presents wireless use cases demanding reliable and available\n      behavior.\n\n  "Operations, Administration and Maintenance (OAM) features for RAW",\n  Fabrice Theoleyre, Georgios Papadopoulos, 2019-11-04,\n  <draft-theoleyre-raw-oam-support-01.txt>\n\n      The wireless medium presents significant specific challenges to\n      achieve properties similar to those of wired deterministic networks.\n      At the same time, a number of use cases cannot be solved with wires\n      and justify the extra effort of going wireless.  This document\n      presents some of these use-cases.\n\n  "Using GOST ciphers in ESP and IKEv2", Valery Smyslov, 2019-10-31,\n  <draft-smyslov-esp-gost-02.txt>\n\n      This document defines a set of encryption transforms for use in\n      Encapsulating Security Payload (ESP) and Internet Key Exchange\n      version 2 (IKEv2) protocols.  The transforms are based on Russian\n      cryptographic standard algorithms (GOST) in a Multilinear Galois Mode\n      (MGM).\n\n  "OAM for use in GENEVE", Gregory Mirsky, Min Xiao, Sami Boutros, David\n  Black, 2020-01-06, <draft-mmbb-nvo3-geneve-oam-01.txt>\n\n      This document defines encapsulation for active Operations,\n      Administration, and Maintenance protocols in Geneve protocol.  Also,\n      the format and operation of the Echo Request and Echo Reply mechanism\n      in Geneve are defined.\n\n  "BMP Extension for Path Marking TLV", Camilo Cardona, Paolo Lucente, Pierre\n  Francois, Yunan Gu, Thomas Graf, 2020-01-03,\n  <draft-cppy-grow-bmp-path-marking-tlv-02.txt>\n\n      The BGP Monitoring Protocol (BMP) provides an interface for obtaining\n      BGP Path information.  BGP Path Information is conveyed within BMP\n      Route Monitoring (RM) messages.  This document proposes an extension\n      to BMP to convey the status of a BGP path after being processed by\n      the BGP best-path selection algorithm.  This extension makes use of\n      the TLV mechanims described in draft-lucente-bmp-tlv\n      [I-D.lucente-bmp-tlv].\n\n  "Observe Notifications as CoAP Multicast Responses", Marco Tiloca, Rikard\n  Hoeglund, Christian Amsuess, Francesca Palombini, 2019-11-04,\n  <draft-tiloca-core-observe-multicast-notifications-01.txt>\n\n      The Constrained Application Protocol (CoAP) allows clients to\n      "observe" resources at a server, and receive notifications as unicast\n      responses upon changes of the resource state.  In some use cases,\n      such as based on publish-subscribe, it would be convenient for the\n      server to send a single notification to all the clients observing a\n      same target resource.  This document defines how a CoAP server sends\n      observe notifications as response messages over multicast, by\n      synchronizing all the observers of a same resource on a same shared\n      Token value.  Besides, this document defines how Group OSCORE can be\n      used to protect multicast notifications end-to-end from the CoAP\n      server to the multiple observer clients.\n\n  "Group OSCORE Profile of the Authentication and Authorization for\n  Constrained Environments Framework", Marco Tiloca, Rikard Hoeglund, Ludwig\n  Seitz, Francesca Palombini, 2019-11-04,\n  <draft-tiloca-ace-group-oscore-profile-01.txt>\n\n      This document specifies a profile for the Authentication and\n      Authorization for Constrained Environments (ACE) framework.  The\n      profile uses Object Security for Constrained RESTful Environments\n      (OSCORE) and/or Group OSCORE to provide communication security\n      between a Client and (a group of) Resource Server(s).  Furthermore,\n      the profile uses (Group) OSCORE to provide server authentication, and\n      OSCORE to achieve proof-of-possession for a key owned by the Client\n      and bound to an OAuth 2.0 Access Token.  Also, the profile provides\n      proof-of-group-membership for the Client, by securely binding the\n      pre-established Group OSCORE Security Context to the pairwise OSCORE\n      Security Context newly established with the Resource Server.\n\n  "IS-IS Extensions to Support Packet Network Slicing using Segment Routing",\n  Yongqing Zhu, Ran Chen, Shaofu Peng, Fengwei Qin, 2019-12-03,\n  <draft-zch-lsr-isis-network-slicing-03.txt>\n\n      [I-D.peng-teas-network-slicing] defines a unified TN-slice\n      identifier, AII(administrative instance identifier), to indicate the\n      topology, computing, storage resources of the dedicated virtual\n      network for both intra-domain and inter-domain network slicing\n      scenarios.  This draft describes the IS-IS extensions required to\n      support Packet Network Slicing using Segment Routing.\n\n  "Reaction of Stateless Address Autoconfiguration (SLAAC) to Flash-\n  Renumbering Events", Fernando Gont, Jan Zorz, Richard Patterson,\n  2019-11-01, <draft-gont-v6ops-slaac-renum-01.txt>\n\n      In scenarios where network configuration information related to IPv6\n      prefixes becomes invalid without any explicit signaling of that\n      condition (such as when a CPE crashes and reboots without knowledge\n      of the previously-employed prefixes), nodes on the local network will\n      continue using stale prefixes for an unacceptably long period of\n      time, thus resulting in connectivity problems.  This document\n      documents this problem, and discusses operational workarounds that\n      may help to improve network robustness.  Additionally, it highlights\n      areas where further work may be needed.\n\n  "YANG Data Model for p2mp sr policy", Hooman Bidgoli, Daniel Voyer, Jayant\n  Kotalwar, Rishabh Parekh, Tarek Saad, 2019-10-30,\n  <draft-hb-spring-sr-p2mp-policy-yang-01.txt>\n\n      SR P2MP policies are set of policies that enable architecture for\n      P2MP service delivery.\n      \n      A P2MP policy consists of candidate paths that connects the Root of\n      the Tree to a set of Leaves. The P2MP policy is composed of\n      replication segments. A replication segment is a forwarding\n      instruction for a candidate path which is downloaded to the Root,\n      transit nodes and the leaves.\n      \n      This document defines a YANG data model for SR P2MP Policy\n      Configuration and operation.\n\n  "M-LDP Signaling Through BIER Core", Hooman Bidgoli, Jayant Kotalwar,\n  Zhaohui Zhang, Eddie Leyton, mankamana mishra, 2019-11-04,\n  <draft-hb-bier-mldp-signaling-over-bier-01.txt>\n\n      Bit Index Explicit Replication (BIER) is an architecture that\n      provides multicast forwarding through a "BIER domain" without\n      requiring intermediate routers to maintain multicast related per-flow\n      state.  Neither does BIER require an explicit tree-building protocol\n      for its operation.  A multicast data packet enters a BIER domain at a\n      "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at\n      one or more "Bit-Forwarding Egress Routers" (BFERs).  The BFIR router\n      adds a BIER header to the packet.  Such header contains a bit-string\n      in which each bit represents exactly one BFER to forward the packet\n      to.  The set of BFERs to which the multicast packet needs to be\n      forwarded is expressed by the according set of bits switched on in\n      BIER packet header.\n      \n      This document describes the procedure needed for mLDP tunnels to be\n      signaled over and stitched through a BIER core, allowing LDP routers\n      to run traditional Multipoint LDP services through a BIER core.\n\n  "SR Path Ingress Protection", Huaimo Chen, Mehmet Toy, Aijun Wang,\n  Zhenqiang Li, Lei Liu, Xufeng Liu, 2019-10-23,\n  <draft-chen-idr-sr-ingress-protection-01.txt>\n\n      This document describes extensions to Border Gateway Protocol (BGP)\n      for protecting the ingress node of a Segment Routing (SR) tunnel or\n      path.\n\n  "SR Path Ingress Protection", Huaimo Chen, Mehmet Toy, Aijun Wang,\n  Zhenqiang Li, Lei Liu, Xufeng Liu, 2019-10-24,\n  <draft-chen-pce-sr-ingress-protection-02.txt>\n\n      This document describes extensions to Path Computation Element (PCE)\n      communication Protocol (PCEP) for protecting the ingress node of a\n      Segment Routing (SR) tunnel or path.\n\n  "A method for dots server deployment", chenmeiling, Li Su, Jin Peng,\n  2019-11-03, <draft-chen-dots-server-hierarchical-deployment-01.txt>\n\n      As DOTS is used for DDoS Mitigation signaling, in practice, there are\n      different deployment scenarios for DOTS agents deployment depending\n      on the network deployment mode.  This document made an accommandation\n      for DOTS Server deployment which may be Suitable for ISP.  The goal\n      is to provide some guidance for DOTS agents deployment.\n\n  "CMP Updates", Hendrik Brockhaus, 2020-01-27,\n  <draft-brockhaus-lamps-cmp-updates-03.txt>\n\n      This document contains a set of updates to the base syntax of\n      Certificate Management Protocol (CMP) version 2.  This document\n      updates RFC 4210.\n      \n      Specifically, the CMP services updated in this document comprise the\n      enabling of using EnvelopedData instead of EncryptedValue and the\n      definition of extended key usages to identify certificates of CMP\n      endpoints on certification and registration authorities.\n\n  "Robots Exclusion Protocol", Martijn Koster, Gary Illyes, Henner Zeller,\n  Lizzi Harvey, 2020-01-07, <draft-koster-rep-01.txt>\n\n      This document standardizes and extends the "Robots Exclusion\n      Protocol" <http://www.robotstxt.org/> method originally defined by\n      Martijn Koster in 1996 for service owners to control how content\n      served by their services may be accessed, if at all, by automatic\n      clients known as crawlers.\n\n  "Operational Considerations for Streaming Media", Jake Holland, 2020-01-17,\n  <draft-jholland-mops-taxonomy-01.txt>\n\n      This document provides an overview of operational networking issues\n      that pertain to quality of experience in delivery of video and other\n      high-bitrate media over the internet.\n\n  "Usecases definition for IoT DDoS attacks prevention", Sorin Faibish,\n  2019-12-25, <draft-faibish-iot-ddos-usecases-01.txt>\n\n      This document specifies several usecases related to the different\n      ways IoT devices are exploited by malicious adversaries to\n      instantiate Distributed Denial of Services (DDoS) attacks. The\n      attacks are generted from IoT devices that have no proper protection\n      against generating unsolicited communication messages targeting a\n      certain network and creating large amounts of network traffic. The\n      attackers take advantage of breaches in the configuration data in\n      unprotected IoT devices exploited for DDoS attacks. The attackers\n      take advantage of the IoT devices that can send network packets\n      that were generated by malicious code that interacts with an OS\n      implementation that runs on the IoT devices. The prupose of this\n      draft is to present possible IoT DDoS usecases that need to be\n      prevented by TEE. The major enabler of such attacks is related to\n      IoT devices that have no OS or unprotected EE OS and run\n      code that is downloaded to them from the TA and modified by\n      man-in-the-middle that inserts malicious code in the OS.\n\n  "DOTS client carry ddos attack informations in signal channel",\n  chenmeiling, Li Su, Jin Peng, 2019-08-22,\n  <draft-chen-dots-attack-informations-03.txt>\n\n      This document describes DDoS attack information which can be obtained\n      by DOTS client when the enterprise suspects it is under DDoS attack,\n      these informations will be send from DOTS client to DOTS server in\n      mitigation request using Signal channel or Data channel.\n\n  "SRv6 and MPLS interworking for VPN service", Zheng Zhang, Shaofu Peng,\n  Gregory Mirsky, 2020-01-09, <draft-pzm-spring-interdomain-vpn-01.txt>\n\n      This document describes a method to achieve an inter-domain\n      connection for a VPN (Virtual Private Network) service.\n\n  "rLEDBAT: receiver-driven Low Extra Delay Background Transport for TCP",\n  Marcelo Bagnulo, Alberto Garcia-Martinez, Gabriel Montenegro, Praveen\n  Balasubramanian, 2019-10-29, <draft-bagnulo-iccrg-rledbat-01.txt>\n\n      This document specifies the rLEDBAT, a set of mechanisms that enable\n      the execution of a less-than-best-effort congestion control algorithm\n      for TCP at the receiver end.\n\n  "BFD for Geneve", Min Xiao, Gregory Mirsky, Juniper Networks, 2019-10-22,\n  <draft-xiao-nvo3-bfd-geneve-01.txt>\n\n      This document describes the use of the Bidirectional Forwarding\n      Detection (BFD) protocol in point-to-point Generic Network\n      Virtualization Encapsulation (Geneve) tunnels forming up an overlay\n      network.\n\n  "IoT Edge Challenges and Functions", Jungha Hong, Yong-Geun Hong, Xavier de\n  Foy, Matthias Kovatsch, Eve Schooler, Dirk Kutscher, 2020-01-17,\n  <draft-hong-t2trg-iot-edge-computing-02.txt>\n\n      Many IoT applications have requirements that cannot be met by\n      the traditional Cloud (aka Cloud computing).  These include time\n      sensitivity, data volume, uplink cost, operation in the face of\n      intermittent services, privacy and security.  As a result, the IoT is\n      driving the Internet toward Edge computing.  This document outlines\n      the requirements of the emerging IoT Edge and its challenges.  It\n      presents a snapshot of the state-of-the-art, a general model, and\n      major components of the IoT Edge, with the goal to provide a common\n      base for future discussions in T2TRG and other IETF WGs and RGs.\n\n  "Hop-by-Hop Authentication in Content-Centric Networking/Named Data\n  Networking", Ruidong Li, Hitoshi Asaeda, 2019-11-16,\n  <draft-li-icnrg-hopauth-01.txt>\n\n      The unpredictability of consumers, routers, copyholders, and\n      publishers for the in-network data retrievals in Content-Centric\n      Networking (CCN) / Named Data Networking (NDN) poses a challenge to\n      design an authentication mechanism to inhibit the malicious consumers\n      to flood data requests and prevent the fake data from being provided.\n      Signature is adopted as the fundamental function in CCN / NDN, which\n      however can only provide publisher authentication with additional\n      certificate acquisition.  This document describes the the Hop-by-Hop\n      Authentication mechanism (HopAuth) integrating certificate collection\n      and packet forwarding potentially with the assistance from\n      certificate authority to provide consumer authentication, copyholder\n      authentication and path authentication to enable the in-network data\n      retrieval to be trustworthy, besides the publisher authentication.\n\n  "Requirement of Computing in network", Peng Liu, Liang Geng, 2019-11-03,\n  <draft-liu-coinrg-requirement-01.txt>\n\n      New technology such as IOT, edge computing,etc. propose the\n      requirement of computing in network, so convergence of network and\n      computing has become a trend.  This document points out the\n      requirements of computing in network according to the development of\n      new Industry, including the performance, function and management\n      requirements.\n\n  "Distributed SFC control for fog environments", Carlos Bernardos, Alain\n  Mourad, 2020-01-27, <draft-bernardos-sfc-distributed-control-01.txt>\n\n      Service function chaining (SFC) allows the instantiation of an\n      ordered set of service functions and subsequent "steering" of traffic\n      through them.  In order to set up and maintain SFC instances, a\n      control plane is required, which typically is centralized.  In\n      certain environments, such as fog computing ones, such centralized\n      control might not be feasible, calling for distributed SFC control\n      solutions.  This document introduces the role of SFC pseudo-\n      controller and specifies solutions to select and initialize such new\n      logical function.\n\n  "Gateway Function for Network Slicing", Shunsuke Homma, Xavier de Foy, A.\n  Galis, Luis Contreras, 2019-11-03, <draft-homma-rtgwg-slice-gateway-01.txt>\n\n      This document describes the roles and requirements for a slice\n      gateway that is a function or function group for handling data plane\n      traffic, such as connecting/disconnecting and compose/decompose\n      network slice subnet instances and providing network slices from end\n      to end.  The interworkings between management and control elements at\n      the management and control planes with the gateway function for\n      controlling and orchestrating end-to-end network slices are also\n      presented in this document.\n\n  "Encapsulation of Path Segment in SRv6", Cheng Li, Weiqiang Cheng, Zhenbin\n  Li, Dhruv Dhody, 2019-11-04, <draft-li-6man-srv6-path-segment-encap-01.txt>\n\n      Segment Routing (SR) allows for a flexible definition of end-to-end\n      paths by encoding paths as sequences of sub-paths, called "segments".\n      Segment routing architecture can be implemented over IPv6 data plane,\n      called SRv6.  In some use-cases such as end-to-end SR Path Protection\n      and Performance Measurement (PM), SRv6 path need to be identified.\n      This document defines the encoding and processing of Path Segment in\n      SRv6 networks.\n\n  "Lightweight CMP Profile", Hendrik Brockhaus, Steffen Fries, David von\n  Oheimb, 2020-01-27, <draft-brockhaus-lamps-lightweight-cmp-profile-03.txt>\n\n      The goal of this document is to facilitate interoperability and\n      automation by profiling the Certificate Management Protocol (CMP)\n      version 2 and the related Certificate Request Message Format (CRMF)\n      version 2 and the HTTP Transfer for the Certificate Management\n      Protocol.  It specifies a subset of CMP and CRMF focusing on typical\n      uses cases relevant for managing certificates of devices in many\n      industrial and IoT scenarios.  To limit the overhead of certificate\n      management for more constrained devices only the most crucial types\n      of transactions are specified as mandatory.  To foster\n      interoperability also in more complex scenarios, other types of\n      transactions are specified as recommended or optional.\n\n  "Enhancement of IPv6 Extension Header", Zhenbin Li, Shuping Peng, Chongfeng\n  Xie, Kihoon LEE, 2020-01-19,\n  <draft-li-6man-enhanced-extension-header-01.txt>\n\n      As SRv6 and the new services such as IOAM are progressing, more and\n      more new requirements are imposed upon the IPv6 extension headers,\n      i.e.. Hop-by-hop Options Header, Destination Options Header and\n      Routing Header.\n      \n      This document defines new IPv6 extension headers and corresponding\n      processing procedures considering the interactions among the existing\n      IPv6 extension headers, SRH and the newly introduced IPv6 extension\n      headers.\n\n  "Instant Congestion Assessment Network (iCAN) for Traffic Engineering",\n  Joanna Dang, Bing Liu, Guangming Yang, Kyungtae Lee, 2019-11-04,\n  <draft-liu-ican-01.txt>\n\n      This draft proposes a new technology named iCAN (instant Congestion\n      Assessment Network), which represents a set of mechanisms running\n      directly on network nodes.  These mechanisms allow the nodes\n      adjusting the flows\' paths based on real-time measurement of the\n      candidate paths.  The measurement is to reflect the congestion\n      situation of each path, so that the nodes could decide which flows\n      need to be switched from a path to another.\n      \n      This is something that current TE technologies can hardly achieve.\n      In current TE, the paths are usually planned in a certralized\n      controller, which is far from the data plane, thus neither be able to\n      assess the real-time congestion situation of each path, nor able to\n      assure the data plane always go as expected (especially in SRv6\n      scenarios).  In a result, traditional TE is not able to adjust the\n      flow paths in real-time to fit for the change of traffic instantly.\n      \n      iCAN can work with traditional TE perfectly: the controller plans\n      multi-path transmission in relatively long period (e.g. minutes), and\n      iCAN does the flow path optimization in a much shorter interval (e.g.\n      milliseconds).\n\n  "Network Programming extension: SRv6 uSID instruction", Clarence Filsfils,\n  Pablo Camarillo, Dezhong Cai, Zhichun Jiang, Daniel Voyer, Ahmed Shawky,\n  Nicolai Leymann, Dirk Steinberg, Shawn Zandi, Gaurav Dawra, Israel Meilik,\n  Jim Uttaro, Luay Jalil, Ning So, Michael Fiumano, Mazen Khaddam,\n  2019-08-28, <draft-filsfils-spring-net-pgm-extension-srv6-usid-02.txt>\n\n      The SRv6 "micro segment" (SRv6 uSID or uSID for short) instruction is\n      defined and illustrated.\n      \n      It is a straightforward extension to the SRv6 Network Programming\n      model and its SRH encapsulation.\n\n  "PCEP extensions for p2mp sr policy", Hooman Bidgoli, Daniel Voyer, Saranya\n  Rajarathinam, Jayant Kotalwar, Siva Sivabalan, Tarek Saad, 2019-11-04,\n  <draft-hsd-pce-sr-p2mp-policy-01.txt>\n\n      SR P2MP policies are set of policies that enable architecture for\n      P2MP service delivery.\n      \n      This document specifies extensions to the Path Computation Element\n      Communication Protocol (PCEP) that allow a stateful PCE to compute\n      and initiate P2MP paths from a Root to a set of Leaves.\n\n  "BGP Usage for SDWAN Overlay Networks", Linda Dunbar, Jim Guichard, Ali\n  Sajassi, John Drake, 2019-11-04, <draft-dunbar-bess-bgp-sdwan-usage-03.txt>\n\n      The document describes three distinct SDWAN scenarios and discusses\n      the applicability of BGP for each of those scenarios. The goal of\n      the document is to make it easier for future SDWAN control plane\n      protocols discussion.\n      \n      SDWAN edge nodes are commonly interconnected by multiple underlay\n      networks that are owned and managed by different network providers.\n      A BGP-based control plane is chosen for handling large number of\n      SDWAN edge nodes with little manual intervention.\n\n  "Applicability of Abstraction and Control of Traffic Engineered Networks\n  (ACTN) to Packet Optical Integration (POI)", Fabio Peruzzini, Italo Busi,\n  Daniel King, Sergio Belotti, Gabriele Galimberti, Zheng Yanlei, Washington\n  Correia, Jean-Francois Bouquier, 2019-10-31,\n  <draft-peru-teas-actn-poi-applicability-02.txt>\n\n      This document considers the applicability of ACTN to Packet Optical\n      Integration (POI) and IP and Optical DWDM domain internetworking,\n      and specifically the YANG models being defined by the IETF to\n      support this deployment architecture.\n      \n      In this document we highlight the IETF protocols and data models\n      that may be used for the ACTN and control of POI networks, with\n      particular focus on the interfaces between the MDSC (Multi-Domain\n      Service Coordinator) and the underlying Packet and Optical Domain\n      Controllers (P-PNC and O-PNC) to support Packet Optical Integration\n      (POI) use cases.\n\n  "Multipath TCP Extension for Robust Session Establishment", Markus Amend,\n  Jiao Kang, 2019-11-04, <draft-amend-mptcp-robe-01.txt>\n\n      Multipath TCP extends the plain, single-path limited, TCP towards the\n      capability of multipath transmission.  This greatly improves the\n      reliability and performance of TCP communication.  For backwards\n      compatibility reasons the Multipath TCP was designed to setup\n      successfully an initial path first, after which subsequent paths can\n      be added for multipath transmission.  For that reason the Multipath\n      TCP has the same limitations as the plain TCP during connection\n      setup, in case the selected path is not functional.\n      \n      This document proposes a set of implementations and possible\n      combinations thereof, that provide a more Robust Establishment (RobE)\n      of MPTCP sessions.  It includes RobE_TIMER, RobE_SIM, RobE_eSIM and\n      RobE_IPS.\n      \n      RobE_TIMER is designed to stay close to MPTCP in that standard\n      functionality is used wherever possible.  Resiliency against network\n      outages is achieved by modifying the SYN retransmission timer: If one\n      path is defective, another path is used.\n      \n      RobE_SIM and RobE_eSIM provides the ability to simultaneously use\n      multiple paths for connection setup.  They ensure connectivity if at\n      least one functional path out of a bunch of paths is given and offers\n      beside that the opportunity to significantly improve loading times of\n      Internet services.\n      \n      RobE_IPS provides a heuristic to select properly an initial path for\n      connection establishment with a remote host based on empirical data\n      derived from previous connection information.\n      \n      In practice, these independent solutions can be complementary used.\n      This document also presents the design and protocol procedure for\n      those combinations in addition to the respective stand-alone\n      solutions.\n\n  "Operations, Administration and Maintenance (OAM) for Deterministic\n  Networks (DetNet) with MPLS Data Plane", Gregory Mirsky, Mach Chen,\n  2020-01-06, <draft-mirsky-detnet-mpls-oam-01.txt>\n\n      This document lists functional requirements for Operations,\n      Administration, and Maintenance (OAM) toolset in Deterministic\n      Networks (DetNet) and, using these requirements; defines format and\n      use principals of the DetNet service Associated Channel over a DetNet\n      network with the MPLS data plane..\n\n  "Operations, Administration and Maintenance (OAM) for Deterministic\n  Networks (DetNet) with IP Data Plane", Gregory Mirsky, Mach Chen,\n  2020-01-06, <draft-mirsky-detnet-ip-oam-01.txt>\n\n      This document defines the principals for using Operations,\n      Administration, and Maintenance protocols and mechanisms in the\n      Deterministic Networking networks with IP data plane.\n\n  "DoH Preference Hints for HTTP", David Schinazi, Nick Sullivan, Jesse Kipp,\n  2020-01-08, <draft-schinazi-httpbis-doh-preference-hints-01.txt>\n\n      When using a publicly available DNS-over-HTTPS (DoH) server, some\n      clients may suffer poor performance when the authoritative DNS server\n      is located far from the DoH server.  For example, a publicly\n      available DoH server provided by a Content Delivery Network (CDN)\n      should be able to resolve names hosted by that CDN with good\n      performance but might take longer to resolve names provided by other\n      CDNs, or might provide suboptimal results if that CDN is using DNS-\n      based load balancing and returns different address records depending\n      or where the DNS query originated from.  This document attempts to\n      lessen these issues by allowing the web server to indicate to the\n      client which DoH server can best resolve its addresses.  This\n      document defines an HTTP header field that enables web host operators\n      to inform user agents of the preferred DoH servers to use for\n      subsequent DNS lookups for the host\'s domain.\n\n  "Authoritative DNS-over-TLS Operational Considerations", Karl Henderson,\n  Tim April, Jason Livingood, 2019-08-13,\n  <draft-hal-adot-operational-considerations-02.txt>\n\n      DNS over TLS (DoT) has been gaining attention, primarily as a means\n      of communication between stub resolvers and recursive resolvers.\n      There have also been discussions and experiments involving the use of\n      DoT to communicate with authoritative nameservers (Authoritative DNS\n      over TLS or "ADoT"), including communication between recursive and\n      authoritative resolvers.  However, we have identified a number of\n      operational concerns with ADoT that have arisen as DNS operators have\n      begun to experiment with and prepare for deploying DoT.  These\n      operational concerns need to be addressed prior to ADoT\'s deployment\n      at scale by DNS operators in order to maintain the stability and\n      resilience of the global DNS.  The document also provides some\n      suggested next steps to advance the operator community\'s\n      understanding of ADoT\'s operational impact.\n\n  "Directions for Computing in the Network", Dirk Kutscher, Teemu Karkkainen,\n  Joerg Ott, 2019-11-04, <draft-kutscher-coinrg-dir-01.txt>\n\n      In-network computing can be conceived in many different ways - from\n      active networking, data plane programmability, running virtualized\n      functions, service chaining, to distributed computing.\n      \n      This memo proposes a particular direction for Computing in the\n      Networking (COIN) research and lists suggested research challenges.\n\n  "IP RSVP-TE: Extensions to RSVP for P2P IP-TE LSP Tunnels", Tarek Saad,\n  Vishnu Beeram, 2019-11-04, <draft-saad-teas-rsvpte-ip-tunnels-01.txt>\n\n      This document describes the use of RSVP (Resource Reservation\n      Protocol), including all the necessary extensions, to establish\n      Point-to-Point (P2P) Traffic Engineered IP (IP-TE) Label Switched\n      Path (LSP) tunnel(s) for use in native IP forwarding networks.\n      \n      This document proposes specific extensions to the RSVP protocol to\n      allow the establishment of explicitly routed IP paths using RSVP as\n      the signaling protocol.  The result is the instantiation of an IP\n      Path which can be automatically routed away from network failures,\n      congestion, and bottlenecks.\n\n  "Packet Loss Signaling for Encrypted Protocols", Alexandre Ferrieux,\n  Isabelle Hamchaoui, Igor Lubashev, 2019-11-04,\n  <draft-ferrieuxhamchaoui-tsvwg-lossbits-02.txt>\n\n      This document describes a protocol-independent method that employs\n      two bits to allow endpoints to signal packet loss in a way that can\n      be used by network devices to measure and locate the source of the\n      loss.  The signaling method applies to all protocols with a protocol-\n      specific way to identify packet loss.  The method is especially\n      valuable when applied to protocols that encrypt transport header and\n      do not allow an alternative method for loss detection.\n\n  "An Information Model for Claims used in RATS", Henk Birkholz, Michael\n  Eckel, 2020-01-08, <draft-birkholz-rats-information-model-01.txt>\n\n      This document defines a standardized information model (IM) for\n      Claims that can be used in remote attestation procedures (RATS).  The\n      information elements defined include attestation Claims which provide\n      information about system components characteristics, as well as\n      commonly used attributes and attribute structures that are required\n      by protocols facilitating remote attestation.\n\n  "Describing Protocol Data Units with Augmented Packet Header Diagrams",\n  Stephen McQuistin, Vivian Band, Colin Perkins, 2019-11-04,\n  <draft-mcquistin-augmented-ascii-diagrams-01.txt>\n\n      This document describes a machine-readable format for specifying the\n      syntax of protocol data units within a protocol specification.  This\n      format is comprised of a consistently formatted packet header\n      diagram, followed by structured explanatory text.  It is designed to\n      maintain human readability while enabling support for automated\n      parser generation from the specification document.  This document is\n      itself an example of how the format can be used.\n\n  "Operational Considerations for use of DNS in IoT devices", Michael\n  Richardson, 2019-11-04,\n  <draft-richardson-opsawg-mud-iot-dns-considerations-01.txt>\n\n      This document details concerns about how Internet of Things devices\n      use IP addresses and DNS names.  The issue becomes acute as network\n      operators begin deploying RFC8520 Manufacturer Usage Description\n      (MUD) definitions to control device access.\n      \n      This document explains the problem through a series of examples of\n      what can go wrong, and then provides some advice on how a device\n      manufacturer can best make deal with these issues.  The\n      recommendations have an impact upon device and network protocol\n      design.\n\n  "HyStart++: Modified Slow Start for TCP", Praveen Balasubramanian, Yi\n  Huang, Matt Olson, 2020-01-22,\n  <draft-balasubramanian-tcpm-hystartplusplus-02.txt>\n\n      This informational memo describes HyStart++, a simple modification to\n      the slow start phase of TCP congestion control algorithms.  HyStart++\n      combines the use of one variant of HyStart and Limited Slow Start\n      (LSS) to prevent overshooting of the ideal sending rate value, while\n      also mitigating poor performance which can result from false\n      positives when HyStart is used alone.  This memo also describes the\n      details of the current implementation in the Windows operating\n      system.\n\n  "Some Congestion Experienced in TCP", Rodney Grimes, Peter Heist,\n  2019-11-04, <draft-grimes-tcpm-tcpsce-01.txt>\n\n      This memo classifies a TCP code point ESCE ("Echo Some Congestion\n      Experienced") for use in feedback of IP code point SCE ("Some\n      Congestion Experienced").\n\n  "HTTP Transport Authentication", David Schinazi, 2020-01-08,\n  <draft-schinazi-httpbis-transport-auth-01.txt>\n\n      The most common existing authentication mechanisms for HTTP are sent\n      with each HTTP request, and authenticate that request instead of the\n      underlying HTTP connection, or transport.  While these mechanisms\n      work well for existing uses of HTTP, they are not suitable for\n      emerging applications that multiplex non-HTTP traffic inside an HTTP\n      connection.  This document describes the HTTP Transport\n      Authentication Framework, a method of authenticating not only an HTTP\n      request, but also its underlying transport.\n\n  "Segment Routing Generic TLV for MPLS Label Switched Path (LSP)\n  Ping/Traceroute", Nagendra Kumar, Carlos Pignataro, Zafar Ali, Clarence\n  Filsfils, 2020-01-09,\n  <draft-nainar-mpls-spring-lsp-ping-sr-generic-sid-01.txt>\n\n      RFC8402 introduces Segment Routing architecture that leverages source\n      routing and tunneling paradigms and can be directly applied to the\n      Multi Protocol Label Switching (MPLS) data plane.  A node steers a\n      packet through a controlled set of instructions called segments, by\n      prepending the packet with Segment Routing header.  SR architecture\n      defines different types of segments with different forwarding\n      semantics associated.  SR can be applied to the MPLS directly and to\n      IPv6 dataplane using a new routing header.\n      \n      RFC8287 defines the extensions to MPLS LSP Ping and Traceroute for\n      Segment Routing IGP-Prefix and IGP-Adjacency Segment Identifier\n      (SIDs) with an MPLS data plane.  Various SIDs are proposed as part of\n      SR architecture with different associated instructions that raises a\n      need to come up with new Target FEC Stack Sub-TLV for each such SIDs.\n      \n      This document defines a new Target FEC Stack Sub-TLV that is used to\n      validate the instruction associated with any SID.\n\n  "EVPN Interoperability Modes", Lukas Krattiger, Ali Sajassi, Samir Thoria,\n  Jorge Rabadan, John Drake, 2020-01-21,\n  <draft-krattiger-evpn-modes-interop-01.txt>\n\n      Ethernet VPN (EVPN) provides different functional modes in the area\n      of Service Interface, Integrated Route and Bridge (IRB) and IRB Core\n      connectivity. This document specifies how the different EVPN\n      functional modes and types can interoperate with each other. This\n      document doesn\'t aim to redefine the existing functional modes but\n      extend them for interoperability.\n\n  "5G Fixed Mobile Convergence User Plane Encapsulation", Dave Allan, Donald\n  Eastlake, David Woolley, 2020-01-13,\n  <draft-allan-5g-fmc-encapsulation-01.txt>\n\n      As part of providing wireline access to the 5G Core (5GC), deployed\n      wireline networks carry user data between 5G residential gateways\n      and the 5G Access Gateway Function (AGF). The encapsulation used\n      needs to meet a variety of requirements including being able to\n      multiplex the traffic of multiple PDU sessions within a VLAN\n      delineated access circuit, to permit legacy equipment in the data\n      path to snoop certain packet fields, to carry 5G QoS information\n      associated with the data, and to be efficiently encoded. This memo\n      specifies an encapsulation that meets these requirements.\n\n  "Compressed SRv6 Network Programming", Zhenbin Li, Cheng Li, Chongfeng Xie,\n  Daniel Voyer, Kihoon LEE, Hui Tian, Feng Zhao, Jim Guichard, Li Cong,\n  Shuping Peng, 2020-01-23, <draft-li-spring-compressed-srv6-np-01.txt>\n\n      Segment Routing can be applied to the IPv6 data plane by leveraging a\n      new type of Routing Extension Header, called Segment Routing Header\n      (SRH).  However, the overhead introduced by SRH may be a challenge\n      for existing hardware, which may influence on the forwarding\n      performance and the payload efficiency.\n      \n      This document defines a compressed SRv6 network programming mechanism\n      in order to reduce the overhead of SRv6 by introducing the Compressed\n      Segment Identifier (C-SID) and the Compressed SRH (C-SRH).  The C-SRH\n      can be a new Routing Header or an enhancement of SRH.\n\n  "Indication of Local DNS Privacy Service During User Access", Zhiwei Yan,\n  Guanggang Geng, Yang Liu, 2020-01-20,\n  <draft-yan-dprive-local-service-indication-01.txt>\n\n      This document aims to support the indication of privacy service of\n      recursive resolver during the user access.\n\n  "IPv6 Application of the Alternate Marking Method", Giuseppe Fioccola,\n  Tianran Zhou, Mauro Cociglio, Fengwei Qin, 2020-01-21,\n  <draft-fz-6man-ipv6-alt-mark-04.txt>\n\n      This document describes how the Alternate Marking Method can be used\n      as the passive performance measurement tool in an IPv6 domain and\n      reports implementation considerations.  It proposes how to define a\n      new Extension Header Option to encode alternate marking technique and\n      also considers the Segment Routing Header TLV alternative.\n\n  "LEDBAT++: Congestion Control for Background Traffic", Praveen\n  Balasubramanian, Osman Ertugay, Daniel Havey, 2019-11-04,\n  <draft-balasubramanian-iccrg-ledbatplusplus-01.txt>\n\n      This experimental memo describes LEDBAT++, a set of enhancements to\n      the LEDBAT (Low Extra Delay Background Transport) congestion control\n      algorithm for background traffic.  The LEDBAT congestion control\n      algorithm has several shortcomings that prevent it from working\n      effectively in practice.  LEDBAT++ extends LEDBAT by adding a set of\n      improvements, including reduced congestion window gain, modified\n      slow-start, multiplicative decrease and periodic slowdowns.  This set\n      of improvement mitigates the known issues with the LEDBAT algorithm,\n      such as latency drift, latecomer advantage and inter-LEDBAT fairness.\n      LEDBAT++ has been implemented as a TCP congestion control algorithm\n      in the Windows operating system.  LEDBAT++ has been deployed in\n      production at scale on a variety of networks and been experimentally\n      verified to achieve the original stated goals of LEDBAT.\n\n  "PCEP Extension for SR-MPLS Entropy Label Position", Shaofu Peng, Quan\n  Xiong, 2019-09-12, <draft-peng-pce-entropy-label-position-01.txt>\n\n      This document proposes a set of extensions for PCEP to configure the\n      entropy label position for SR-MPLS networks.\n\n  "Cheap Nasty Queueing", Jonathan Morton, Peter Heist, 2019-11-04,\n  <draft-morton-tsvwg-cheap-nasty-queueing-01.txt>\n\n      This note presents Cheap Nasty Queueing (CNQ), a queueing algorithm\n      intended as a bare-minimum functionality standard for hardware\n      implementations.  It provides stateless or single-instance AQM and\n      basic sparse-flow prioritisation.\n\n  "TLS Authentication using IEEE 1609.2 certificate", Mounira Msahli, Nancy\n  Cam-Winget, Ahmed Serhrouchni, Houda Labiod, William Whyte, 2019-11-17,\n  <draft-msahli-ise-ieee1609-03.txt>\n\n      The IEEE and ETSI have specified end-entity certificates.  This\n      docment defines an experimental change to TLS to support IEEE/ETSI\n      certificate types to authenticate TLS entities.\n\n  "YANG Object Universal Parsing Interface", Ivaylo Petrov, 2019-11-04,\n  <draft-petrov-t2trg-youpi-01.txt>\n\n      YANG Object Universal Parsing Interface (YOUPI) specification\n      describes generic way to encode and decode binary data based on a\n      YANG model for use of constrainted devices.  YOUPI is a generic\n      mechanism designed for great flexibility, so that it can be adapted\n      for any of the constainted devices.\n\n  "Updates to the Allocation Policy for the Border Gateway Protocol - Link\n  State (BGP-LS) Parameters Registries", Adrian Farrel, 2019-11-03,\n  <draft-farrel-idr-bgp-ls-registry-03.txt>\n\n      RFC 7752 defines Border Gateway Protocol - Link State (BGP-LS).  IANA\n      created a registry consistent with that document called the "Border\n      Gateway Protocol - Link State (BGP-LS) Parameters Registry" with a\n      number of sub-registries.  The allocation policy applied by IANA for\n      those policies is "Specification Required" as defined in RFC 8126.\n      \n      This document updates RFC 7752 by changing the allocation policy for\n      all of the registries to "Expert Review" and by updating the guidance\n      to the Designated Experts.\n\n  "Definition of new tags for relations between RFCs", Mirja Kuehlewind,\n  Suresh Krishnan, 2019-09-04, <draft-kuehlewind-update-tag-01.txt>\n\n      An RFC can include a tag called "Updates" which can be used to link a\n      new RFC to an existing RFC.  On publication of such an RFC, the\n      existing RFC will include an additional metadata tag called "Updated\n      by" which provides a link to the new RFC.  However, this tag pair is\n      not well-defined and therefore it is currently used for multiple\n      different purposes, which leads to confusion about the actual meaning\n      of this tag and inconsistency in its use.\n      \n      This document recommends the discontinuation of the use of the\n      updates/updated by tag pair, and instead proposes three new tag pairs\n      that have well-defined meanings and use cases.\n\n  "IPv6 Neighbor Discovery Unicast Lookup", Pascal Thubert, Eric\n  Levy-Abegnoli, 2019-07-29, <draft-thubert-6man-unicast-lookup-00.txt>\n\n      This document updates RFC 8505 in order to enable unicast address\n      lookup from a 6LoWPAN Border Router acting as an Address Registrar.\n\n  "Legacy RSASSA-PKCS1-v1_5 codepoints for TLS 1.3", David Benjamin,\n  2019-07-29, <draft-davidben-tls13-pkcs1-00.txt>\n\n      This document allocates code points for the use of RSASSA-PKCS1-v1_5\n      with client certificates in TLS 1.3.\n\n  "PCE TE Constraints for Network Slicing", Shaofu Peng, Quan Xiong, Fengwei\n  Qin, 2019-11-29, <draft-peng-pce-te-constraints-02.txt>\n\n      This document proposes a set of extensions for PCEP to support the\n      constraints for network slicing during path computation, e.g, IGP\n      instance, virtual network, specific application, color template and\n      FA-id etc.\n\n  "Version Capability for BGP", Donatas Abraitis, 2019-11-30,\n  <draft-abraitis-bgp-version-capability-03.txt>\n\n      In this document, we introduce a new BGP capability that allows the\n      advertisement of a BGP speaker\'s version.\n\n  "The "RRSERIAL" EDNS option for the SOA serial of a RR\'s zone", Hugo\n  Salgado, 2020-01-27, <draft-salgado-rrserial-01.txt>\n\n      The "RRSERIAL" EDNS option allows a DNS querier to ask a DNS\n      authoritative server to add a EDNS option in the answer of such query\n      with the SOA serial number field of the origin zone which contains\n      the answered resource record.\n      \n      This "RRSERIAL" data allows to debug problems and diagnosis by\n      helping to recognize the origin of an answer, associating this answer\n      with a respective zone version.\n\n  "Evaluation of a Sample of RFC Produced in 2018", Christian Huitema,\n  2019-10-07, <draft-huitema-rfc-eval-project-02.txt>\n\n      This document presents a first attempt at evaluating the recently\n      published RFC.  We analyze a set of randomly chosen RFC approved in\n      2018, looking for history and delays.  The average RFC was produced\n      in 3 years and 4 months, of which 2 years and 10 months were spent in\n      the working group, 3 to 4 months for IETF consensus and IESG review,\n      and 3 to 4 months in RFC production.  The main variation in RFC\n      production delays comes from the AUTH48 phase.\n      \n      We also measure the number of citations of the chosen RFC using\n      Semantic Scholar, and compare citation counts with what we know about\n      deployment.  We show that citation counts indicate academic interest,\n      but correlate only loosely with deployment or usage of the\n      specifications.\n      \n      The measurement of delays could be automated by processing dates and\n      events recorded in the data tracker.  The measurement of published\n      RFC could be complemented by statistics on abandoned drafts, which\n      would measure the efficiency of the IETF triaging process.\n\n  "Maintaining CCNx or NDN flow balance with highly variable data object\n  sizes", David Oran, 2019-08-10, <draft-oran-icnrg-flowbalance-01.txt>\n\n      Deeply embedded in some ICN architectures, especially Named Data\n      Networking (NDN) and Content-Centric Networking (CCNx) is the notion\n      of flow balance.  This captures the idea that there is a one-to-one\n      correspondence between requests for data, carried in Interest\n      messages, and the responses with the requested data object, carried\n      in Data messages.  This has a number of highly beneficial properties\n      for flow and congestion control in networks, as well as some\n      desirable security properties.  For example, neither legitimate users\n      nor attackers are able to inject large amounts of un-requested data\n      into the network.\n      \n      Existing congestion control approaches however cannot deal\n      effectively with a widely varying MTU of ICN data messages, since the\n      protocols allow a dynamic range of 1-64K bytes.  Since Interest\n      messages are used to allocate the reverse link bandwidth for\n      returning Data, there is large uncertainty in how to allocate that\n      bandwidth.  Unfortunately, current congestion control schemes in CCNx\n      and NDN only count Interest messages and have no idea how much data\n      is involved that could congest the inverse link.  This document\n      proposes a method to maintain flow balance by accommodating the wide\n      dynamic range in Data message MTU.\n\n  "Extensible Provisioning Protocol (EPP) Industrial Internet Identifier\n  Mapping", Yuying Chen, Jiagui Xie, Zhiping Li, Zhipeng Fan, 2019-12-23,\n  <draft-chen-epp-identifier-mapping-01.txt>\n\n      This document describes an Extensible Provisioning Protocol\n      (EPP)mapping for the provisioning and management of Industrial\n      Internet Identifiers. Specified in XML, the mapping defines EPP\n      command syntax and semantics as applied to identifiers.\n\n  "Sampled Traffic Streaming", Andrew Gray, Lawrence Wobker, 2019-11-04,\n  <draft-gray-sampled-streaming-02.txt>\n\n      This document standardizes both 1) a means of requesting a stream of\n      packet samples from any device generating, routing, or forwarding\n      traffic, and 2) receiving metadata information from the network\n      element about these packet samples, and the structure of said stream\n      metadata.  A main design requirement is to provide network elements\n      with widely varying capabilities (e.g., ASICs, NPUs, NICs, vSwitches,\n      CPUs) a mechanism to sample and export packets at high rates, by\n      allowing communication of the specific bit formats of internal data\n      headers applied to the packet flow, in a way that enhances\n      interoperability between traffic sources and sinks.  Historically,\n      Netflow and similar mechanisms have been used for these use cases;\n      however, the increasing packet rates of very high-speed devices and\n      increasing variance in the information available to data planes lends\n      itself to both a less-prescriptive set of packet formats as well as a\n      decoupling of the sampling action from the collection and analysis\n      mechanisms.\n\n  "Support for Data Reduction Attributes in nfsv4 Version 2", Sorin Faibish,\n  David Black, Philip Shilane, 2019-12-30,\n  <draft-faibish-nfsv4-data-reduction-attributes-02.txt>\n\n      This document proposes extending NFSv4 operations to add new\n      named attributes to be used in the protocol to provide information\n      about the data reduction properties of files. The new data reduction\n      attributes are proposed to allow the client application to\n      communicate to the NFSv4 server data reduction attributes\n      associated with files and directories using new metadata,\n      communicated to the Block Storage data reduction engines.\n      Corresponding new named attributes are proposed to allow clients\n      and client applications to query the server for data reduction\n      attributes support and allow to get and set data reduction\n      attributes on files and directories. Such data reduction\n      metadata is used as hints to the file server about what type of data\n      reduction to apply. The proposed data reduction attributes include\n      achievable ratios for compression and deduplication plus whether\n      each data reduction technique applies to a file or directory.\n\n  "JSON Schema Language (JSL)", Ulysse Carion, 2019-08-09,\n  <draft-ucarion-json-schema-language-02.txt>\n\n      JSON Schema Language (JSL) is a portable method for describing the\n      format of JavaScript Object Notation (JSON) data and the errors\n      associated with ill-formed data.  JSL is designed to enable code\n      generation from schemas.\n\n  "MUD (D)TLS profiles for IoT devices", Tirumaleswar Reddy.K, Dan Wing,\n  Blake Anderson, 2020-01-16, <draft-reddy-opsawg-mud-tls-02.txt>\n\n      This memo extends Manufacturer Usage Description (MUD) to incorporate\n      (D)TLS profile parameters.  This allows a network element to identify\n      unexpected (D)TLS usage, which can indicate the presence of\n      unauthorized software or malware on an endpoint.\n\n  "Use of The IPv4 Reserved-flag for OAM", Ashish Ghule, Ron Bonica,\n  2019-08-07, <draft-aghule-intarea-oam-01.txt>\n\n      This document defines new IPv4 Operations and Management (OAM)\n      capabilities.  In order to support these capabilities, this document\n      defines a new interpretation of the IPv4 Reserved-flag.\n\n  "SCIM Protocol: Multi-Value Paging Extension", Phil Hunt, Gregg Wilson,\n  2019-08-07, <draft-hunt-scim-mv-paging-00.txt>\n\n      The System for Cross-Domain Identity Management (SCIM) specifications\n      define a profile of HTTP protocol and a schema that enable managing\n      identities in cross-domain scenarios.  This specification extends\n      SCIM protocol resource retrieval and query functions to enable paging\n      of SCIM resources that contain large complex multi-valued attributes\n      such as SCIM Groups.\n\n  "Considerations in the development of a QoS Architecture for CCNx-like ICN\n  protocols", David Oran, 2019-12-03, <draft-oran-icnrg-qosarch-03.txt>\n\n      This is a position paper.  It documents the author\'s personal views\n      on how Quality of Service (QoS) capabilities ought to be accommodated\n      in ICN protocols like CCNx or NDN which employ flow-balanced\n      Interest/Data exchanges and hop-by-hop forwarding state as their\n      fundamental machinery.  It argues that such protocols demand a\n      substantially different approach to QoS from that taken in TCP/IP,\n      and proposes specific design patterns to achieve both classification\n      and differentiated QoS treatment on both a flow and aggregate basis.\n      It also considers the effect of caches as a resource in addition to\n      memory, CPU and link bandwidth that should be subject to explicitly\n      unfair resource allocation.  The proposed methods are intended to\n      operate purely at the network layer, providing the primitives needed\n      to achieve both transport and higher layer QoS objectives.  It\n      explicitly excludes any discussion of Quality of Experience (QoE)\n      which can only be assessed and controlled at the application layer or\n      above.\n\n  "How Requests for IANA Action Will be Handled on the Independent Stream",\n  Adrian Farrel, 2019-09-23, <draft-ise-iana-policy-03.txt>\n\n      The Internet Assigned Numbers Authority (IANA) maintains registries\n      to track codepoints used by protocols such as those defined by the\n      IETF and documented in RFCs developed on the IETF Stream.\n      \n      The Independent Submissions Stream is another source of documents\n      that can be published as RFCs.  This stream is under the care of the\n      Independent Submissions Editor (ISE).\n      \n      This document complements RFC 4846 by providing a description of how\n      the ISE currently handles documents in the Independent Submissions\n      Stream that request actions from the IANA.  Nothing in this document\n      changes existing IANA registries or their allocation policies, nor\n      does it change any previously documented processes.\n\n  "YANG Data Model for OSPFv3 Segment Routing", Acee Lindem, Yingzhen Qu,\n  2019-08-13, <draft-acee-lsr-ospfv3-sr-yang-00.txt>\n\n      This document defines a YANG data module augmenting the IETF OSPF\n      Segment Routing (SR) YANG model to support OSPFv3 extensions for SR.\n      It can be used to configure and manage OSPFv3 Segment Routing in MPLS\n      dataplane.\n\n  "ShangMi (SM) Cipher Suites for Transport Layer Security (TLS) Protocol\n  Version 1.3", Paul Yang, 2020-01-05, <draft-yang-tls-tls13-sm-suites-03.txt>\n\n      This document specifies a set of cipher suites for the Transport\n      Layer Security (TLS) protocol version 1.3 to support ShangMi (SM)\n      cryptographic algorithms.\n      \n      The use of these cipher suites with TLSv1.3 is not endorsed by the\n      IETF.  The SM cipher suites are becoming mandatory in China, and so\n      this document provides a description of how to use the SM cipher\n      suites with TLSv1.3 so that implementers can produce interworking\n      implementations.\n\n  "Commercial National Security Algorithm (CNSA) Suite Profile for TLS and\n  DTLS 1.2 and 1.3", Dorothy Cooley, 2019-12-12,\n  <draft-cooley-cnsa-dtls-tls-profile-01.txt>\n\n      This document defines a base profile for TLS protocol versions 1.2\n      and 1.3, as well as DTLS protocol versions 1.2 and 1.3 for use with\n      the United States Commercial National Security Algorithm (CNSA)\n      Suite.\n      \n      The profile applies to the capabilities, configuration, and operation\n      of all components of US National Security Systems that use TLS or\n      DTLS.  It is also appropriate for all other US Government systems\n      that process high-value information.\n      \n      The profile is made publicly available here for use by developers and\n      operators of these and any other system deployments.\n\n  "Advertising OTN Fixed Time slot constraints in OSPF", Vijayanand\n  Chandrasekar, 2019-08-16, <draft-vijay-ccamp-ospf-otn-timeslot-00.txt>\n\n      This document describes the extensions needed to OSPF for\n      advertising the constraints that exists in some OTN switches while\n      switching timeslots between ports. This advertisement would be\n      needed for computing path of LSP through these switches taking into\n      account the above mentioned constraint.\n      \n      This document proposes extensions to existing OSPF for advertising\n      the timeslots available on each OTN port in a new sub-tlv and the\n      connectivity matrix representing the capability of the device to\n      cross connect these timeslots in another new sub-tlv\n\n  "IGP Flooding Optimization Methods", Shaofu Peng, Zheng Zhang, 2019-08-19,\n  <draft-peng-lsr-igp-flooding-opt-methods-00.txt>\n\n      This document mainly describe a method to optimize IGP flooding by\n      visited record, the visited record information could be encapsulated\n      in outer carring header, or as a part of IGP PDU.\n\n  "URI Design and Ownership", Mark Nottingham, 2020-01-05,\n  <draft-nottingham-rfc7320bis-03.txt>\n\n      Section 1.1.1 of RFC 3986 defines URI syntax as "a federated and\n      extensible naming system wherein each scheme\'s specification may\n      further restrict the syntax and semantics of identifiers using that\n      scheme."  In other words, the structure of a URI is defined by its\n      scheme.  While it is common for schemes to further delegate their\n      substructure to the URI\'s owner, publishing independent standards\n      that mandate particular forms of substructure in URIs is often\n      problematic.\n      \n      This document provides guidance on the specification of URI\n      substructure in standards.\n\n  "Packet Network Slicing using Segment Routing", Shaofu Peng, Ran Chen,\n  Gregory Mirsky, Fengwei Qin, 2019-12-17,\n  <draft-peng-teas-network-slicing-02.txt>\n\n      This document presents a mechanism aimed at providing a solution for\n      network slicing in the transport network for 5G services.  The\n      proposed mechanism uses a unified administrative instance identifier\n      to distinguish different virtual network resources for both intra-\n      domain and inter-domain network slicing scenarios.  Combined with the\n      segment routing technology, the mechanism could be used for both\n      best-effort and traffic engineered services for tenants.\n\n  "LDP behaviour on link-shut scenarios", Anush Mohan, Anup T, 2019-08-22,\n  <draft-aa-ldp-link-shut-01.txt>\n\n      This document is intended as clarification of LDP behaviour in link-\n      down scenarios.  Base LDP RFC5036 lacks sufficient clarity on what an\n      LDP enabled node should be doing when a link down event is received,\n      and the only LDP adjacency for an LDP peer is over this link.\n      Different vendors have handled this scenario differently, with some\n      immediately resetting tcp session with neighbor and some waiting for\n      igp recovergence instead of reacting directly to link events.  With\n      this document we intend to clarify the expected behaviour explicitly\n      so that any interop issues can be avoided.\n\n  "JSON Data Definition Format (JDDF)", Ulysse Carion, 2020-01-23,\n  <draft-ucarion-jddf-05.txt>\n\n      This document proposes a format, called JSON Data Definition Format\n      (JDDF), for describing the shape of JavaScript Object Notation (JSON)\n      messages.  Its main goals are to enable code generation from schemas\n      as well as portable validation with standardized error indicators.\n      To this end, JDDF is strategically limited to be no more expressive\n      than the type systems of mainstream programming languages.  This\n      strategic limitation, as well as the decision to make JDDF schemas be\n      JSON documents, also makes tooling atop of JDDF easier to build.\n      \n      This document does not have IETF consensus and is presented here to\n      facilitate experimentation with the concept of JDDF.\n\n  "Post-quantum Multi-Key Mechanisms for PKIX-like protocols; Problem\n  Statement and Overview of Solution Space", Mike Ounsworth, 2019-09-17,\n  <draft-pq-pkix-problem-statement-01.txt>\n\n      With the widespread adoption of post-quantum (PQ) cryptography will\n      come uncertainty about the strength of cryptographic primitives.  For\n      example; when will RSA and ECC fall?  Are Lattice schemes as strong\n      as we believe?  The cryptographic community is calling for hybrid\n      schemes that combine classic and post-quantum crypto in ways that\n      remain strong so long as at least one of the algorithms used remains\n      strong.\n      \n      This document defines the problem statement for digital signatures in\n      PKIX-like protocols, and gives an overview of the general families of\n      solutions.\n\n  "Fragmentation in LPWAN considerations: CoAP Block vs SCHC fragmentation",\n  Carles Gomez, Jon Crowcroft, 2019-08-27,\n  <draft-gomez-frag-lpwan-considerations-00.txt>\n\n      The SCHC adaptation layer provides header compression and\n      fragmentation functionality between IPv6 and an underlying LPWAN\n      technology.  SCHC fragmentation has been specifically designed for\n      the characteristics of LPWANs.  However, when CoAP is used at the\n      application layer, there exists an alternative approach for\n      fragmentation, which is using the CoAP Block option.  This document\n      aims at illustrating the advantages and limitations of each approach\n      for transferring larger payloads.\n\n  "Discovery Of Restconf Metadata for Source-specific multicast", Jake\n  Holland, 2019-09-26, <draft-jholland-mboned-dorms-01.txt>\n\n      This document defines DORMS (Discovery Of Restconf Metadata for\n      Source-specific multicast), a method to discover and retrieve\n      extensible metadata about source-specific multicast channels using\n      RESTCONF.  The reverse IP DNS zone for a multicast sender\'s IP\n      address is configured to use SRV resource records to advertise the\n      hostname of a RESTCONF server that publishes metadata according to a\n      new YANG module with support for extensions.  A new service name and\n      the new YANG module are defined.\n\n  "OAuth 2.0 Rich Authorization Requests", Torsten Lodderstedt, Justin\n  Richer, Brian Campbell, 2019-11-04, <draft-lodderstedt-oauth-rar-03.txt>\n\n      This document specifies a new parameter "authorization_details" that\n      is used to carry fine grained authorization data in the OAuth\n      authorization request.\n\n  "OAuth 2.0 Client Intermediary Metadata", Aaron Parecki, 2019-08-29,\n  <draft-parecki-oauth-client-intermediary-metadata-00.txt>\n\n      This specification defines a mechanism for including information\n      about additional parties involved in an OAuth transaction by adding a\n      new section to the OAuth 2.0 Dynamic Client Registration request, as\n      well as requires that authorization servers surface this information\n      to users during an OAuth transaction.\n\n  "TLV support for BMP Route Monitoring and Peer Down Messages", Paolo\n  Lucente, Yunan Gu, Henk Smit, 2019-09-03, <draft-grow-bmp-tlv-00.txt>\n\n      Most of the message types defined by the BGP Monitoring Protocol\n      (BMP) do provision for optional trailing data; however Route\n      Monitoring message (to provide a snapshot of the monitored Routing\n      Information Base) and Peer Down message (to indicate that a peering\n      session was terminated) do not.  Supporting optional data in TLV\n      format across all BMP message types allows for an homogeneous and\n      extensible surface that would be useful for the most different use-\n      cases that need to convey additional data to a BMP station.  While\n      this document does not want to cover any specific utilization\n      scenario, it defines a simple way to support optional TLV data in all\n      message types.\n\n  "YANG Data Model for Dynamic Flooding", Srinath Dontula, Tony Li,\n  2019-09-05, <draft-dontula-lsr-yang-dynamic-flooding-01.txt>\n\n      This document defins YANG data models that can be used to configure\n      and manage Dynamic Flooding for IS-IS and OSPF.\n\n  "LDP behaviour on link-shut scenarios", Anush Mohan, Anup T, 2019-09-04,\n  <draft-aa-mpls-ldp-link-shut-00.txt>\n\n      This document is intended as clarification of LDP behaviour in link-\n      down scenarios.  Base LDP RFC5036 lacks sufficient clarity on what an\n      LDP enabled node should be doing when a link down event is received,\n      and the only LDP adjacency for an LDP peer is over this link.\n      Different vendors have handled this scenario differently, with some\n      immediately resetting tcp session with neighbor and some waiting for\n      igp recovergence instead of reacting directly to link events.  With\n      this document we intend to clarify the expected behaviour explicitly\n      so that any interop issues can be avoided.\n\n  "RateLimit Header Fields for HTTP", Roberto Polli, Alejandro Ruiz,\n  2019-10-21, <draft-polli-ratelimit-headers-01.txt>\n\n      This document defines the RateLimit-Limit, RateLimit-Remaining,\n      RateLimit-Reset header fields for HTTP, thus allowing servers to\n      publish current request quotas and clients to shape their request\n      policy and avoid being throttled out.\n\n  "Usage of PAKE Protocols with IKEv2", Valery Smyslov, 2019-09-10,\n  <draft-smyslov-ikev2-pake-00.txt>\n\n      This memo discusses how PAKE (Password Authenticated Key Exchange)\n      protocols can be integrated into the IKEv2 (Internet Key Exchange)\n      protocol.\n\n  "DNS over HTTPS (DoH) Considerations for Operator Networks", Andy Fidler,\n  Bert Hubert, Jason Livingood, Jim Reid, Nicolai Leymann, 2019-09-10,\n  <draft-doh-reid-operator-00.txt>\n\n      The introduction of DNS over HTTPS (DoH), defined in RFC8484,\n      presents a number of challenges to network operators.  These are\n      described in this document.  The objective is to document the problem\n      space and make suggestions that could help inform network operators\n      on how to take account of DoH deployment.  This document also\n      identifies topics that may require further analysis.\n\n  "BRSKI Cloud Registrar", Owen Friel, Rifaat Shekh-Yusef, Michael\n  Richardson, 2019-10-23, <draft-friel-anima-brski-cloud-01.txt>\n\n      This document specifies the behaviour of a BRSKI Cloud Registrar, and\n      how a pledge can interact with a BRSKI Cloud Registrar when\n      bootstrapping.\n\n  "Automatic Peering for SIP Trunks", Kaustubh Inamdar, Sreekanth Narayanan,\n  Cullen Jennings, 2019-11-04, <draft-kinamdar-dispatch-sip-auto-peer-01.txt>\n\n      This draft specifies a configuration workflow to enable enterprise\n      Session Initiation Protocol (SIP) networks to solicit the capability\n      set of a SIP service provider network.  The capability set can\n      subsequently be used to configure features and services on the\n      enterprise edge element, such as a Session Border Controller (SBC),\n      to ensure smooth peering between enterprise and service provider\n      networks.\n\n  "Hierarchical HITs for HIPv2", Robert Moskowitz, Stuart Card, Adam\n  Wiethuechter, 2019-12-16, <draft-moskowitz-hip-hierarchical-hit-03.txt>\n\n      This document describes using a hierarchical HIT to facilitate large\n      deployments of managed devices.  Hierarchical HITs differ from HIPv2\n      flat HITs by only using 64 bits for mapping the Host Identity,\n      freeing 32 bits to bind in a hierarchy of Registering Entities that\n      provide services to the consumers of hierarchical HITs.\n\n  "Hierarchical HIT Registries", Robert Moskowitz, Stuart Card, Adam\n  Wiethuechter, 2019-10-17, <draft-moskowitz-hip-hhit-registries-01.txt>\n\n      This document describes using the registration protocol and\n      registries to support hierarchical HITs (HHITs).  New and existing\n      HIP parameters are used to communicate Registry Policies and data\n      about the HHIT device and the Registries.  Further Registries are\n      expected to provide RVS services for registered HHIT devices.\n\n  "New Cryptographic Algorithms for HIP", Robert Moskowitz, Stuart Card, Adam\n  Wiethuechter, 2020-01-23, <draft-moskowitz-hip-new-crypto-04.txt>\n\n      This document provides new cryptographic algorithms to be used with\n      HIP.  The Edwards Elliptic Curve and the Keccak sponge functions are\n      the main focus.  The HIP parameters and processing instructions\n      impacted by these algorithms are defined.\n\n  "Additional Parameter sets for LMS Hash-Based Signatures", Scott Fluhrer,\n  Quynh Dang, 2019-09-16, <draft-fluhrer-lms-more-parm-sets-00.txt>\n\n      This note extends LMS (RFC 8554) by defining parameter sets by\n      including additional hash functions.  Hese include hash functions\n      that result in signatures with significantly smaller than the\n      signatures using the current parameter sets, and should have\n      sufficient security.\n      \n      This document is a product of the Crypto Forum Research Group (CFRG)\n      in the IRTF.\n\n  "Reliable and Available Wireless Problem Statement", Pascal Thubert,\n  Georgios Papadopoulos, 2019-10-23,\n  <draft-pthubert-raw-problem-statement-04.txt>\n\n      Due to uncontrolled interferences, including the self-induced\n      multipath fading, deterministic networking can only be approached on\n      wireless links.  The radio conditions may change -way- faster than a\n      centralized routing can adapt and reprogram, in particular when the\n      controller is distant and connectivity is slow and limited.  RAW\n      separates the routing time scale at which a complex path is\n      recomputed from the forwarding time scale at which the forwarding\n      decision is taken for an individual packet.  RAW operates at the\n      forwarded time scale.  The RAW problem is to decide, within the\n      redundant solutions that are proposed by the routing, which will be\n      used for each individual packet to provide a DetNet service while\n      minimizing the waste of resources.\n\n  "Framework for Network Resources Categorization", Jilong Wang, Congcong\n  Miao, Shuying Zhuang, Qianli Zhang, Jianfeng Chen, 2019-10-14,\n  <draft-jilongwang-opsawg-crc-02.txt>\n\n      This memo presents the definition of cyberspace resource, and then\n      discusses a classification framework for cyberspace resources.\n      Cyberspace is widely applied in people\'s daily life and it is\n      regarded as a new space, paralleled to the geographic space.  There\n      are various resources in cyberspace.  However, they have not been\n      systematically defined and classified.  The objective of this draft\n      is to present the deifinition of cyberspace resource and a standard\n      classification framework, thus, supporting the unified resource\n      storage and shares.\n\n  "OAuth 2.0 Pushed Authorization Requests", Torsten Lodderstedt, Brian\n  Campbell, Nat Sakimura, Dave Tonge, Filip Skokan, 2019-11-03,\n  <draft-lodderstedt-oauth-par-01.txt>\n\n      This document defines the pushed authorization request endpoint,\n      which allows clients to push the payload of an OAuth 2.0\n      authorization request to the authorization server via a direct\n      request and provides them with a request URI that is used as\n      reference to the data in a subsequent authorization request.\n\n  "A YANG Module for uCPE management.", Dmytro Shytyi, Laurent Beylier, Luigi\n  Iannone, 2019-11-20, <draft-shytyi-opsawg-vysm-07.txt,.pdf>\n\n      This document provides a YANG data model for uCPE management (VYSM)\n      and definition of the uCPE equipment.  The YANG Model serves as a\n      base framework for managing an universal Customer-Premises Equipment\n      (uCPE) subsystem.  The model can be used by a Network Orchestrator.\n\n  "RTP Payload Format for Versatile Video Coding (VVC)", Shuai Zhao, Stephan\n  Wenger, 2019-09-23, <draft-zhao-avtcore-rtp-vvc-00.txt,.pdf>\n\n      This memo describes an RTP payload format for the video coding\n      standard ITU-T Recommendation H.266 and ISO/IEC International\n      Standard 23090-3, both also known as Versatile Video Coding (VVC) and\n      developed by the Joint Video Experts Team (JVET).  The RTP payload\n      format allows for packetization of one or more Network Abstraction\n      Layer (NAL) units in each RTP packet payload as well as fragmentation\n      of a NAL unit into multiple RTP packets.  The payload format has wide\n      applicability in videoconferencing, Internet video streaming, and\n      high-bitrate entertainment-quality video, among others.\n\n  "BGP Flexible Color-Based Tunnel Selection", Yimin Shen, Ravi Singh,\n  2019-09-24, <draft-shen-idr-flexible-color-tunnel-selection-00.txt>\n\n      This document discusses color-based tunnel selection for BGP payload\n      prefixes.  It defines a set of extended mapping modes, and describes\n      how to use these modes to construct tunnel selection schemes to\n      achieve flexible tunnel selection.  Tunnel selection schemes can be\n      implemented as policies on routers performing tunnel selection, or\n      signaled by next hop routers or a central controller via BGP.\n\n  "Revised BGP Maximum Prefix Limits", Job Snijders, Melchior Aelmans,\n  2019-09-24, <draft-sa-idr-maxprefix-00.txt>\n\n      This document updates RFC4271 by revising control mechanism which\n      limit the negative impact of route leaks (RFC7908) and/or resource\n      exhaustion in Border Gateway Protocol (BGP) implementations.\n\n  "SRv6 NET-PGM extension: Insertion", Clarence Filsfils, Pablo Camarillo,\n  John Leddy, Daniel Voyer, Satoru Matsushima, Zhenbin Li, 2020-01-15,\n  <draft-filsfils-spring-srv6-net-pgm-insertion-02.txt>\n\n      Traffic traversing an SR domain is encapsulated in an outer IPv6\n      header for its journey through the SR domain.\n      \n      To implement transport services strictly within the SR domain, the SR\n      domain may require insertion or deletion of an SRH after the outer\n      IPv6 header of the SR domain.  Any segment within the SRH is strictly\n      contained within the SR domain.\n      \n      This document extends SRv6 Network Programming\n      [I-D.ietf-spring-srv6-network-programming] with new SR endpoint and\n      transit behaviors to be performed only within the SR domain in any\n      packet owned by the domain.\n\n  "IPv4 Hop-by-Hop Options and Destination Options Extension Headers", Tom\n  Herbert, 2019-09-24, <draft-herbert-ipv4-hbh-destopt-00.txt>\n\n      This specification enables the use of Hop-by-Hop Options and\n      Destination Options extension headers which are defined for IPv6 to\n      be used with IPv4. The goal is to provide a uniform and feasible\n      method of extensibility that is common between IPv4 and IPv6.\n\n  "Cyberspace Resources Measurement", Jianfeng Chen, Zhi Sun, Da He, Rui Xu,\n  Jilong Wang, 2019-09-24,\n  <draft-jilongwang-opsawg-cyberresource-measurement-00.txt>\n\n      This memo describes the measurement of cyberspace resource; it adopts\n      a multi-level hierarchical indicator system, which focuses on the\n      unified calculation of the measurement weigh of cyberspace resources.\n      The goal of this draft is to discuss the basic principles and the\n      methodology of measurement standards.  Additionally, demonstrating\n      how the cyberspace resources can be measured based on the existing\n      economy information measurement, geographic information measurement\n      and statistical theory.\n\n  "Framework for Network Resource Property Description", Zhi Sun, Da He,\n  Jianfeng Chen, Rui Xu, Jilong Wang, 2019-09-26,\n  <draft-jilongwang-opsawg-csp-01.txt>\n\n      This memo discusses and defines a framework for cyberspace resource\n      property description, which is suitable for the unified\n      classification organization and description of multi-source network\n      resource measurement information.  Now, there is no unified\n      description framework for network resource property.  The objective\n      of this draft is to establish a general model based on cyberspace\n      identification reference, and implement the reuse of survey data in\n      different users and occasions.  Then discuss the basic methodology\n      and propose a less mature framework for further complement and\n      improvement\n\n  "Problem Statement and Use Cases of Application-aware IPv6 Networking\n  (APN6)", Zhenbin Li, Shuping Peng, Daniel Voyer, Chongfeng Xie, Peng Liu,\n  Chang Liu, Kentaro Ebisawa, Stefano Previdi, Jim Guichard, 2019-11-03,\n  <draft-li-apn6-problem-statement-usecases-01.txt>\n\n      Network operators are facing the challenge of providing better\n      network services for users.  As the ever developing 5G and industrial\n      verticals evolve, more and more services that have diverse network\n      requirements such as ultra-low latency and high reliability are\n      emerging, and therefore differentiated service treatment is desired\n      by users.  However, network operators are typically unaware of which\n      applications are traversing their network infrastructure, which means\n      that only coarse-grained services can be provided to users.  As a\n      result, network operators are only evolving their infrastructure to\n      be large but dumb pipes without corresponding revenue increases that\n      might be enabled by differentiated service treatment.  As network\n      technologies evolve including deployments of IPv6 and SRv6, the\n      programmability provided by IPv6 and SRv6 encapsulations can be\n      augmented by conveying application related information into the\n      network.  Adding application knowledge to the network layer allows\n      applications to specify finer granularity requirements to the network\n      operator.\n      \n      This document analyzes the existing problems caused by lack of\n      application awareness, and outlines various use cases that could\n      benefit from an Application-aware IPv6 Networking (APN6)\n      architecture.\n\n  "Circuit Breaker Assisted Congestion Control", Jake Holland, 2019-09-26,\n  <draft-jholland-mboned-cbacc-00.txt>\n\n      This document specifies Circuit Breaker Assisted Congestion Control\n      (CBACC).  CBACC enables fast-trip Circuit Breakers by publishing rate\n      metadata about multicast channels from senders to intermediate\n      network nodes or receivers.  The circuit breaker behavior is defined\n      as a supplement to receiver driven congestion control systems, to\n      preserve network health if receivers subscribe to a volume of traffic\n      that exceeds capacity policies or capability for a network or\n      receiver.\n\n  "IP Traffic Engineering Architecture with Network Programming", Robert\n  Raszuk, 2019-09-26, <draft-raszuk-rtgwg-ip-te-np-00.txt>\n\n      This document describes a control plane based IP Traffic Engineering\n      Architecture where path information is kept in the control plane by\n      selected nodes instead of being inserted into each packet on ingress\n      of an administrative domain.  The described proposal is also fully\n      compatible with the concept of network programming.\n      \n      It is positioned as a complimentary technique to native SRv6 and can\n      be used when there are concerns with increased packet size due to\n      depth of SID stack, possible concerns regarding exceeding MTU or more\n      strict simplicity requirements typically seen in number of enterprise\n      networks.  The proposed solution is applicable to both IPv4 or IPv6\n      based networks.\n      \n      As an additional added value, detection of end to end path liveness\n      as well as dynamic path selection based on real time path quality is\n      integrated from day one in the design.\n\n  "Client DNS Filtering Profile Request", Wes Hardaker, 2019-09-27,\n  <draft-hardaker-dprive-add-doh-dnsop-filter-request-00.txt>\n\n      This document defines a mechanism under which a client can request\n      that an upstream recursive resolver perform DNS filtering on behalf\n      of a client-requested policy.  This is may be done, for example,\n      under a subscription model, where the client wishes not to get\n      redirected to domains known to host malware or malicious content.\n      This request is sent as an EDNS0 option with every DNS request, or\n      potentially to just the first DNS request in a stream when using DNS\n      over TLS, DNS over DTLS or DNS over DOH for example.\n\n  "Link Local Next Hop Handling for BGP", Russ White, Donald Sharp, Dinesh\n  Dutt, Biswajit Sadhu, Jeff Tantsura, 2019-09-30,\n  <draft-white-linklocalnh-00.txt>\n\n      BGP, described in [RFC4271], was originally designed to provide\n      reachability between domains and between the edges of a domain.  As\n      such, BGP assumes the next hop towards any reachable destination may\n      not reside on the advertising speaker, but rather may either be\n      through a router connected to the same subnet as the speaker, or\n      through a router only reachable by traversing multiple hops through\n      the network.  Because of this, BGP does not recognize the use of IPv6\n      link local addresses, as described in [RFC4291], as a valid next hop\n      for forwarding purposes.\n      \n      However, BGP speakers are now often deployed on point-to-point links\n      in networks where multihop reachability of any kind is not assumed or\n      desired (all next hops are assumed to be the speaker reachable\n      through a directly connected point-to-point link).  This is common,\n      for instance, in data center fabrics.  In these situations, a global\n      IPv6 address is not required for the advertisement of reachability\n      information; in fact, providing global IPv6 addresses in these kinds\n      of networks can be detrimental to Zero Touch Provisioning (ZTP).\n      \n      This draft standardizes the operation of BGP over a point-to-point\n      link using link local IPv6 addressing only.\n\n  "IP Traffic Engineering Architecture with Network Programming", Robert\n  Raszuk, 2019-10-02, <draft-raszuk-teas-ip-te-np-00.txt>\n\n      This document describes a control plane based IP Traffic Engineering\n      Architecture where path information is kept in the control plane by\n      selected nodes instead of being inserted into each packet on ingress\n      of an administrative domain.  The described proposal is also fully\n      compatible with the concept of network programming.\n      \n      It is positioned as a complimentary technique to native SRv6 and can\n      be used when there are concerns with increased packet size due to\n      depth of SID stack, possible concerns regarding exceeding MTU or more\n      strict simplicity requirements typically seen in number of enterprise\n      networks.  The proposed solution is applicable to both IPv4 or IPv6\n      based networks.\n      \n      As an additional added value, detection of end to end path liveness\n      as well as dynamic path selection based on real time path quality is\n      integrated from day one in the design.\n\n  "DNS Server Privacy Statement and Filtering Policy with Assertion Token",\n  Tirumaleswar Reddy.K, Dan Wing, Michael Richardson, 2020-01-17,\n  <draft-reddy-dprive-dprive-privacy-policy-02.txt>\n\n      Users want to control how their DNS queries are handled by DNS\n      servers so they can configure their system to use DNS servers that\n      comply with their privacy and DNS filtering expectations.\n      \n      This document defines a mechanism for a DNS server to communicate its\n      privacy statement URL and filtering policy to a DNS client.  This\n      communication is cryptographically signed to attest to its\n      authenticity.  By evaluating the DNS privacy statement, filtering\n      policy and the signatory, the user can choose a DNS server that best\n      supports their desired privacy and filtering policy.  This token is\n      particularly useful for DNS-over-TLS and DNS-over-HTTPS servers that\n      are either public resolvers or are discovered on the local network.\n\n  "Session Initiation Protocol (SIP) Non-eXempt Rate Control", Philip\n  Williams, 2019-10-03, <draft-williams-soc-nxrate-control-00.txt>\n\n      A SIP overload control signalling protocol framework has previously\n      been published, with the flexibility to allow different SIP request\n      rate limiting algorithms to be selected. This document proposes a\n      similar algorithm of maximum rate type with two advantages over\n      existing proposals. Firstly, it exempts certain classes of SIP\n      requests that are fundamental to correct operation of the SIP\n      protocol which, if rejected by control, would worsen rather than\n      improve SIP performance. Secondly, it allows target servers to\n      control SIP traffic from sources not compliant with this document so\n      that it can be deployed in heterogeneous network environments.\n\n  "Area Proxy for IS-IS", Tony Li, Yunxia Chen, 2019-12-24,\n  <draft-li-lsr-isis-area-proxy-01.txt>\n\n      Link state routing protocols have hierarchical abstraction already\n      built into them.  However, when lower levels are used for transit,\n      they must expose their internal topologies to each other, leading to\n      scale issues.\n      \n      To avoid this, this document discusses extensions to the IS-IS\n      routing protocol that would allow level 1 areas to provide transit,\n      yet only inject an abstraction of the level 1 topology into level 2.\n      Each level 1 area is represented as a single level 2 node, thereby\n      enabling greater scale.\n\n  "Adaptive DNS: Improving Privacy of Name Resolution", Eric Kinnear, Tommy\n  Pauly, Christopher Wood, Patrick McManus, 2019-11-01,\n  <draft-pauly-dprive-adaptive-dns-privacy-01.txt>\n\n      This document defines an architecture that allows clients to\n      dynamically discover designated resolvers that offer encrypted DNS\n      services, and use them in an adaptive way that improves privacy while\n      co-existing with locally provisioned resolvers.  These resolvers can\n      be used directly when looking up names for which they are designated.\n      These resolvers also provide the ability to proxy encrypted queries,\n      thus hiding the identity of the client requesting resolution.\n\n  "Oblivious DNS Over HTTPS", Eric Kinnear, Patrick McManus, Tommy Pauly,\n  Christopher Wood, 2019-11-01, <draft-pauly-dprive-oblivious-doh-01.txt>\n\n      This document describes an extension to DNS Over HTTPS (DoH) that\n      allows hiding client IP addresses via proxying encrypted DNS\n      transactions.  This improves privacy of DNS operations by not\n      allowing any one server entity to be aware of both the client IP\n      address and the content of DNS queries and answers.\n\n  "Ecosystem Effects of Web Packaging", Jeffrey Yasskin, 2019-10-07,\n  <draft-yasskin-wpack-ecosystem-effects-00.txt>\n\n      This document analyzes how Web Packaging may affect the web\n      ecosystem.\n      \n      Note to Readers\n      \n      This document has NOT been reviewed widely and probably contains lots\n      of mistakes.\n      \n      Discussion of this draft takes place on the wpack mailing list\n      (wpack@ietf.org), which is archived at\n      https://www.ietf.org/mailman/listinfo/wpack [1].\n      \n      The source code and issues list for this draft can be found in\n      https://github.com/jyasskin/wpack-ecosystem-effects [2].\n\n  "RADIUS Extensions for 0-RTT TCP Converters", Mohamed Boucadair, Christian\n  Jacquenet, 2019-10-07, <draft-boucadair-opsawg-tcpm-converter-00.txt>\n\n      Because of the lack of important TCP extensions, e.g., Multipath TCP\n      support at the server side, some service providers now consider a\n      network-assisted model that relies upon the activation of a dedicated\n      function called Transport Converters.  For example, network-assisted\n      Multipath TCP deployment models are designed to facilitate the\n      adoption of Multipath TCP for the establishment of multi-path\n      communications without making any assumption about the support of\n      Multipath TCP by the remote servers.  Transport Converters located in\n      the network are responsible for establishing multi-path\n      communications on behalf of endpoints, thereby taking advantage of\n      Multipath TCP capabilities to achieve different goals that include\n      (but are not limited to) optimization of resource usage (e.g.,\n      bandwidth aggregation), of resiliency (e.g., primary/backup\n      communication paths), and traffic offload management.\n      \n      This document specifies a new Remote Authentication Dial-In User\n      Service (RADIUS) attributes that carry the IP addresses that will be\n      returned to authorized users to reach one or multiple Converters.\n\n  "In-Flight IPv6 Extension Header Insertion Considered Harmful", Mark Smith,\n  Naveen Kottapalli, Ron Bonica, Fernando Gont, Tom Herbert, 2019-11-03,\n  <draft-smith-6man-in-flight-eh-insertion-harmful-01.txt>\n\n      In the past few years, as well as currently, there have and are a\n      number of proposals to insert IPv6 Extension Headers into existing\n      IPv6 packets while in-flight.  This contradicts explicit prohibition\n      of this type of IPv6 packet proccessing in the IPv6 standard.  This\n      memo describes the possible failures that can occur with EH\n      insertion, the harm they can cause, and the existing model that is\n      and should continue to be used to add new information to an existing\n      IPv6 and other packets.\n\n  "BGPsec Validation State Signaling", Oliver Borchert, Doug Montgomery,\n  Daniel Kopp, 2019-11-18, <draft-sidrops-bgpsec-validation-signaling-01.txt>\n\n      This document updates RFC 8097 by adding the BGPsec path validation\n      state to the reserved portion of the extended community in RFC 8097.\n      BGP speakers that receive this community string can use the embedded\n      BGPsec validation state and configure local policies that allow it\n      being used to influence their decision process.  This is especially\n      helpful because Section 5 of RFC 8205 specifically allows putting\n      BGPsec path validation temporarily on hold.  This allows reducing the\n      load of validation particularly from IBGP learned routes or EBGP\n      learned routes when warranted.\n\n  "BGP Provisioned IPsec Transport Mode Protected Tunnel Configuration", Jun\n  Hu, 2019-10-10, <draft-hujun-idr-bgp-ipsec-transport-mode-00.txt>\n\n      This document defines a method of using BGP to advertise IPsec\n      transport mode protected tunnel (like GRE tunnel with IPsec transport\n      mode protection) configuration along with NLRI, based on\n      [I-D.ietf-idr-tunnel-encaps] and [I-D.hujun-idr-bgp-ipsec].\n\n  "SR Replication Segment for Multi-point Service Delivery", Daniel Voyer,\n  Clarence Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang,\n  2019-11-27, <draft-voyer-spring-sr-replication-segment-02.txt>\n\n      This document describes the SR Replication segment for multi-point\n      service delivery.  A SR Replication segment allows a packet to be\n      replicated from a replication node to downstream nodes.\n\n  "Segment Routing Point-to-Multipoint Policy", Daniel Voyer, Clarence\n  Filsfils, Rishabh Parekh, Hooman Bidgoli, Zhaohui Zhang, 2019-10-11,\n  <draft-voyer-pim-sr-p2mp-policy-00.txt>\n\n      This document describes an architecture to construct a Point-to-\n      Multipoint (P2MP) tree to deliver Multi-point services in a Segment\n      Routing domain.  A SR P2MP tree is constructed by stitching a set of\n      Replication segments together.  A SR Point-to-Multipoint (SR P2MP)\n      Policy is used to define and instantiate a P2MP tree which is\n      computed by a PCE.\n\n  "Remote Attestation Architecture", Dave Thaler, 2019-11-04,\n  <draft-thaler-rats-architecture-01.txt>\n\n      In network protocol exchanges, it is often the case that one entity\n      (a relying party) requires evidence about the remote peer (and system\n      components [RFC4949] thereof), in order to assess the trustworthiness\n      of the peer.  This document describes an architecture for such remote\n      attestation procedures (RATS), which enable relying parties to decide\n      whether to consider a remote system component trustworthy or not.\n\n  "Default IPv6 Local Only Addressing for Non-Internet Devices", Mark Smith,\n  2019-10-14, <draft-smith-v6ops-local-only-addressing-00.txt>\n\n      For certain types or models of devices it should be clear and obvious\n      that, by default, they should not be reachable from the global IPv6\n      Internet, or able to reach the global IPv6 Internet, even though the\n      network they are attached to provides global IPv6 Internet\n      connectivity.  This memo proposes that these types of devices refuse\n      to configure and use global IPv6 Internet addresses by default.\n\n  "OpenPGP Example Keys and Certificates", Bjarni Einarsson, juga, Daniel\n  Gillmor, 2019-12-20, <draft-bre-openpgp-samples-01.txt,.pdf>\n\n      The OpenPGP development community benefits from sharing samples of\n      signed or encrypted data.  This document facilitates such\n      collaboration by defining a small set of OpenPGP certificates and\n      keys for use when generating such samples.\n\n  "Eliding and Querying RPL Information", Pascal Thubert, Rahul Jadhav, Li\n  Zhao, Dominique Barthel, 2019-11-17,\n  <draft-thubert-roll-eliding-dio-information-03.txt>\n\n      This document presents a method to safely elide a group of RPL\n      options in a DIO message by synchronizing the state associated with\n      each of these options between parent and child using a new sequence\n      counter in DIO messages.  A child that missed a DIO message with an\n      update of any of those protected options detects it by the change of\n      sequence counter and queries the update with a DIS Message.  The\n      draft also provides a method to fully elide the options in a DAO\n      message.\n\n  "BMP Compression", Mukul Srivastava, Paolo Lucente, 2019-10-15,\n  <draft-msri-grow-bmp-compression-00.txt,.pdf>\n\n      This document provides specification for an optional compressed BMP\n      Feed from a router to BMP station.\n\n  "Quick and Dirty Security for GRASP", Brian Carpenter, 2019-10-29,\n  <draft-carpenter-anima-quads-grasp-02.txt>\n\n      A secure substrate is required by the Generic Autonomic Signaling\n      Protocol (GRASP) used by Autonomic Service Agents.  This document\n      describes QUADS, a QUick And Dirty Security method using symmetric\n      cryptography and preconfigured keys or passwords.  It also describes\n      a simplistic QUADS Key Infrastructure based on asymmetric\n      cryptography used over insecure instances of GRASP.\n\n  "IPv6 over Controller Area Network", Alexander Wachter, 2019-10-17,\n  <draft-wachter-6lo-can-00.txt>\n\n      Controller Area Network (CAN) is a fieldbus initially designed for\n      automotive applications.  It is a multi-master bus with 11-bit or\n      29-bit frame identifiers.  The CAN standard (ISO 11898 series)\n      defines the physical and data-link layer.  This document describes\n      how to transfer IPv6 packets over CAN using ISO-TP, a dedicated\n      addressing scheme, and IP header compression (IPHC).\n\n  "An Alternative Approach for Postquantum Preshared Keys in IKEv2", Valery\n  Smyslov, 2019-10-17, <draft-smyslov-ipsecme-ikev2-qr-alt-00.txt>\n\n      An IKEv2 extension defined in [I-D.ietf-ipsecme-qr-ikev2] allows\n      IPsec traffic to be protected against someone storing VPN\n      communications today and decrypting it later, when (and if) Quantum\n      Computers are available.  However, this protection doesn\'t cover an\n      initial IKEv2 SA, which might be unacceptable in some scenarios.\n      This specification defines an alternative way get the same protection\n      against Quantum Computers, which allows to extend it on the initial\n      IKEv2 SA.\n\n  "attack type unification", chenmeiling, Li Su, 2019-10-17,\n  <draft-chen-dots-attack-type-unification-00.txt>\n\n      This document put forward a method to unify DDoS attack type\n      classification and attack definition description, this will help\n      different mitigators to mitigate DDoS attacks together.\n\n  "Artificial Intelligence (AI) based ECN adaptive reconfiguration for\n  datacenter networks", Zhuangyan, Bai Zhang, Haotao Pan, 2019-10-18,\n  <draft-zhuang-tsvwg-ai-ecn-for-dcn-00.txt>\n\n      This document is to provide an artificial intelligence (AI) based ECN\n      adaptive reconfiguration for datacenter networks.\n\n  "TM-RID Authentication Formats", Adam Wiethuechter, Stuart Card, Robert\n  Moskowitz, 2019-12-19, <draft-wiethuechter-tmrid-auth-04.txt>\n\n      This document describes how to include trust into the proposed ASTM\n      Remote ID specification defined in WK65041 by the F38 Committee under\n      a Broadcast Remote ID (RID) scenario.  It defines a few different\n      message schemes (based on the authentication message) that can be\n      used to assure past messages sent by a UA and also act as a assurance\n      for UA trustworthiness in the absence of Internet connectivity at the\n      receiving node.\n\n  "Performance Measurement for Segment Routing Networks with MPLS Data\n  Plane", Rakesh Gandhi, Clarence Filsfils, Daniel Voyer, Stefano Salsano,\n  Mach Chen, 2019-12-04, <draft-gandhi-mpls-rfc6374-sr-01.txt>\n\n      Segment Routing (SR) leverages the source routing paradigm.  RFC 6374\n      specifies protocol mechanisms to enable the efficient and accurate\n      measurement of packet loss, one-way and two-way delay, as well as\n      related metrics such as delay variation in MPLS networks using probe\n      messages.  This document utilizes these mechanisms for Performance\n      Delay and Loss Measurements in Segment Routing (SR) networks with\n      MPLS data plane (SR-MPLS), for both SR links and end-to-end SR\n      Policies.  In addition, this document defines Return Path TLV for\n      two-way performance measurement and Block Number TLV for loss\n      measurement.\n\n  "Segment Routing with MPLS Data Plane Encapsulation for In-situ OAM Data",\n  Rakesh Gandhi, Zafar Ali, Clarence Filsfils, Frank Brockners, Bin Wen,\n  Voitek Kozak, 2019-12-06, <draft-gandhi-mpls-ioam-sr-01.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in the data packet while the\n      packet traverses a path between two nodes in the network.  Segment\n      Routing (SR) technology leverages the source routing paradigm.  This\n      document defines how IOAM data fields are transported using the\n      Segment Routing with MPLS data plane (SR-MPLS) encapsulation.  The\n      procedures defined are also equally applicable to all other MPLS data\n      plane encapsulations.\n\n  "Using Netconf Pub/Sub Model for RATS Interaction Procedure", Liang Xia,\n  Wei Pan, 2019-10-21, <draft-xia-rats-pubsub-model-01.txt>\n\n      This draft defines the a new method of using the netconf pub/sub\n      model in the RATS interaction procedure, to increse its flexibility,\n      efficiency and scalability.\n\n  "Path Steering in CCNx and NDN", Ilya Moiseenko, David Oran, 2019-10-21,\n  <draft-oran-icnrg-pathsteering-00.txt>\n\n      Path Steering is a mechanism to discover paths to the producers of\n      ICN content objects and steer subsequent Interest messages along a\n      previously discovered path.  It has various uses, including the\n      operation of state-of-the-art multipath congestion control algorithms\n      and for network measurement and management.  This specification\n      derives directly from the design published in _Path Switching in\n      Content Centric and Named Data Networks_ (4th ACM Conference on\n      Information-Centric Networking - ICN\'17) and therefore does not\n      recapitulate the design motivations, implementation details, or\n      evaluation of the scheme.  Some technical details are different\n      however, and where there are differences, the design documented here\n      is to be considered definitive.\n\n  "Using QUIC Datagrams with HTTP/3", David Schinazi, 2019-11-04,\n  <draft-schinazi-quic-h3-datagram-02.txt>\n\n      The QUIC DATAGRAM extension provides application protocols running\n      over QUIC with a mechanism to send unreliable data while leveraging\n      the security and congestion-control properties of QUIC.  However,\n      QUIC DATAGRAM frames do not provide a means to demultiplex\n      application contexts.  This document defines how to use QUIC DATAGRAM\n      frames when the application protocol running over QUIC is HTTP/3 by\n      adding an identifier at the start of the frame payload.\n      \n      Discussion of this work is encouraged to happen on the QUIC IETF\n      mailing list quic@ietf.org [1] or on the GitHub repository which\n      contains the draft: https://github.com/DavidSchinazi/draft-\n      h3-datagram [2].\n\n  "LSVR IETF Organizationally Specific TLVs for IEEE Std 802.1AB (LLDP)",\n  Paul Congdon, Paul Bottorff, 2019-10-22,\n  <draft-congdon-lsvr-lldp-tlvs-00.txt>\n\n      IEEE Std 802.1AB, commonly known as the Link Layer Discovery\n      Protocol (LLDP), provides a means for individual organizations to\n      define their own Type-Length-Value (TLV) objects for exchange over\n      the protocol.  The IETF is a standards development organization with\n      an IANA OUI (RFC 7042) that can be used in LLDP organizationally\n      specific TLVs.  This document specifies IETF Organizationally\n      Specific TLVs that support LSVR protocols.\n\n  "EDX - Edge Exchanger", Sweta Jaiswal, Karthikeyan Arunachalam, Jamsheed\n  Ppallan, Dronamraju Sabareesh, Madhan Kanagarathinam, 2019-12-04,\n  <draft-edx-edge-exchanger-01.txt>\n\n      This document describes a new DNS resource record (RR) type, called\n      the Edge Exchanger (EDX) RR, that is used to find services and\n      location of the server(s) for any specific domain (the word domain is\n      used here in the strict RFC1034 sense).\n\n  "Data Center Fast Congestion Management", Roni Even, Rachel Huang,\n  2019-10-23, <draft-even-iccrg-dc-fast-congestion-00.txt,.pdf>\n\n      Fast congestion control is discussed in academic papers as well as in\n      the different standard bodies.  There is no one proposal for\n      providing a solution that will work for all use cases leading to\n      multiple approaches.  By congestion control we refer to an end to end\n      solution and not only to the congestion control algorithm on the\n      sender side.  This document describes the current state of flow\n      control and congestion for Data Centers and proposes future\n      directions.\n\n  "ACME for Subdomains", Owen Friel, Richard Barnes, Tim Hollebeek,\n  2020-01-20, <draft-friel-acme-subdomains-01.txt>\n\n      This document outlines how ACME can be used by a client to obtain a\n      certificate for a subdomain identifier from a certificate authority.\n      The client has fulfilled a challenge against a parent domain but does\n      not need to fulfil a challenge against the explicit subdomain as\n      certificate authority policy allows issuance of the subdomain\n      certificate without explicit subdomain ownership proof.\n\n  "LISP Site External Connectivity", Prakash Jain, Victor Moreno, Sanjay\n  Hooda, 2019-10-23, <draft-jain-lisp-site-external-connectivity-00.txt>\n\n      This draft defines how to register/retrieve default-pETR mapping\n      information in LISP when the destination is not registered/known to\n      the local site and its mapping system (e.g. the destination is an\n      internet or external site destination).\n\n  "Prefix Unreachable Announcement", Aijun Wang, Zhibo Hu, 2019-12-08,\n  <draft-wang-lsr-prefix-unreachable-annoucement-01.txt>\n\n      This document describes the mechanism that can be used to announce\n      the unreachable prefixes for service fast convergence.\n\n  "SRv6 and MPLS interworking for VPN service", Zheng Zhang, Shaofu Peng,\n  Gregory Mirsky, 2020-01-03, <draft-pzm-bess-spring-interdomain-vpn-01.txt>\n\n      This document describes a method to achieve an inter-domain\n      connection for a VPN (Virtual Private Network) service.\n\n  "Lzip Compressed Format and the application/lzip Media Type", Antonio Diaz,\n  2019-10-24, <draft-diaz-lzip-00.txt>\n\n      Lzip is a lossless compressed data format designed for data sharing,\n      long-term archiving, and parallel (de)compression.  Lzip uses a\n      simplified form of the Lempel-Ziv-Markov chain-Algorithm (LZMA)\n      stream format, chosen to maximize safety and interoperability.  Lzip\n      can achieve higher compression ratios than gzip.  This document\n      describes the lzip format and registers a media type and content\n      encoding to be used when transporting lzip-compressed content via\n      Multipurpose Internet Mail Extensions (MIME).\n\n  "RFC Series Model Process", Heather Flanagan, 2019-11-19,\n  <draft-flanagan-rseme-03.txt>\n\n      The RFC Series has come to a crossroads where questions must be\n      answered regarding how the Series should be managed, the role of the\n      RFC Series Editor, and the oversight of the RFC Editor function.\n      This draft offers a proposal to form a new IAB program called the RFC\n      Editor Future Development Program.  This proposal is based on the\n      discussions held during three virtual meetings in September and\n      October 2019, as well as the RSEME session at IETF 106, and requests\n      a new, open IAB program that will drive consensus around any changes\n      to the RFC Editor model.  The program will require extensive\n      community engagement and outreach to a broad set of stakeholder\n      communities.\n\n  "Path Protection Enforcement in PCEP", Andrew Stone, Mustapha Aissaoui,\n  2019-10-25, <draft-stone-pce-path-protection-enforcement-00.txt>\n\n      This document aims to clarify existing usage of the local protection\n      desired bit signalled in Path Computation Element Protocol (PCEP).\n      This document also introduces a new flag for signalling protection\n      strictness in PCEP.\n\n  "Layer 3 Discovery and Liveness Signing", Randy Bush, Rob Austein,\n  2019-10-26, <draft-ymbk-lsvr-l3dl-signing-00.txt>\n\n      The Layer 3 Discovery and Liveness protocol OPEN PDU may contain a\n      key and a certificate, which can be used to verify signatures on\n      subsequent PDUs.  This document describes two mechanisms based on\n      digital signatures, one that is Trust On First Use (TOFU), and one\n      that uses certificates to provide authentication as well as session\n      integrity.\n\n  "SRv6 Tagging proxy", Yukito Ueno, Ryo Nakamura, Teppei Kamata, 2019-10-27,\n  <draft-eden-srv6-tagging-proxy-00.txt>\n\n      This document describes the tagging method of SRv6 proxy.  SRv6 proxy\n      is an SR endpoint behavior for processing SRv6 traffic on behalf of\n      an SR-unaware service.\n\n  "XMSS public key algorithms for the Secure Shell (SSH) protocol", Loganaden\n  Velvindron, Jeremie Daniel, 2019-10-28, <draft-mu-curdle-ssh-xmss-00.txt>\n\n      This document describes the use of the XMSS (XMSS: eXtended Merkle\n      Signature Scheme) which is resistant to quantum computers attack, as\n      a digital signature algorithm in the Secure Shell (SSH) protocol.\n\n  "PEM file format for ESNI", Stephen Farrell, 2019-10-28,\n  <draft-farrell-tls-pemesni-00.txt>\n\n      Encrypted SNI key pairs need to be configured into TLS servers, some\n      of which can be built with different TLS libraries, so there is a\n      benefit and little cost in documenting a file format to use for\n      these, similar to how RFC7468 defines other PEM file formats.\n\n  "Stateless OpenPGP Command Line Interface", Daniel Gillmor, 2019-10-29,\n  <draft-dkg-openpgp-stateless-cli-01.txt>\n\n      This document defines a generic stateless command-line interface for\n      dealing with OpenPGP messages, known as "sop".  It aims for a\n      minimal, well-structured API covering OpenPGP object security.\n\n  "The Computerate Specifying Paradigm", Marc Petit-Huguenin, 2019-11-16,\n  <draft-petithuguenin-computerate-specifying-02.txt>\n\n      This document specifies a paradigm named Computerate Specifying,\n      designed to simultaneously document and formally specify\n      communication protocols.  This paradigm can be applied to any\n      document produced by any Standard Developing Organization (SDO), but\n      this document targets specifically documents produced by the IETF.\n\n  "Advancing ACK Handling for Wireless Transports", Tong Li, Kai Zheng, Rahul\n  Jadhav, Jiao Kang, 2019-10-29,\n  <draft-li-ack-handling-for-wireless-transports-00.txt>\n\n      Acknowledgement (ACK) is a basic function and implemented in most of\n      the ordered and reliable transport protocols [RFC0793].  Traditional\n      ACK is designed with high frequency to guarantee correct interaction\n      between sender and receiver.  Delayed byte-counting ACK or periodic\n      ACK with large interval are proposed in prior work to reduce ACK\n      intensity.\n      \n      High-throughput transport over wireless local area network (WLAN)\n      becomes a demanding requirement with the emergence of 4K wireless\n      projection, VR/AR-based interactive gaming, and more.  However, the\n      interference nature of the wireless medium induces an unavoidable\n      contention between data transport and backward signaling, such as\n      acknowledgement.\n      \n      This document presents the problems caused by high-intensity ACK in\n      WLAN.  We also analyze the possibility of ACK optimization in WLAN\n      and the compatibility issues with existing systems.\n\n  "Lossless Path MTU Discovery (PMTUD)", Ron Bonica, Manoj Nayak, Bradely\n  Newton, Hakan Alpan, Radon Rosborough, Miles President, 2019-10-31,\n  <draft-bonica-intarea-lossless-pmtud-01.txt>\n\n      This document describes alternative IPv4 PMTUD procedures that do not\n      prevent IP fragmentation and do no rely on the network\'s ability to\n      deliver ICMP Destination Unreachable messages to the source node.\n      This document also defines a new ICMP message.  IPv4 nodes emit this\n      new message when they reassemble a fragmented packet.\n\n  "Security Considerations Regarding Compression Dictionaries", Felix Handte,\n  2019-10-29, <draft-handte-httpbis-dict-sec-00.txt>\n\n      Dictionary-based compression enables better performance, but brings\n      state into the process of compression, with all the complexities that\n      follow.  This document explores the security implications of this\n      technique in the context of internet protocols and enumerates known\n      risks and mitigations.\n\n  "Using GOST R 34.10-2012 and GOST R 34.11-2012 algorithms with the Internet\n  X.509 Public Key Infrastructure", Dmitry Eremin-Solenikov, Vasily Nikolaev,\n  Aleksandr Chelpanov, 2019-11-20, <draft-deremin-rfc4491-bis-02.txt>\n\n      This document updates RFC 3279 and RFC 4491.  It describes encoding\n      formats, identifiers, and parameter formats for the algorithms GOST R\n      34.10-2012 and GOST R 34.11-2012 for use in Internet X.509 Public Key\n      Infrastructure (PKI).\n\n  "GOST Cipher Suites for Transport Layer Security (TLS) Protocol Version\n  1.3", Stanislav Smyshlyaev, Evgeny Alekseev, Smyshliaeva Ekaterina,\n  Alexandra Babueva, 2019-12-16, <draft-smyshlyaev-tls13-gost-suites-01.txt>\n\n      The purpose of this document is to make the Russian cryptographic\n      standards available to the Internet community for their\n      implementation in the Transport Layer Security (TLS) Protocol Version\n      1.3.\n      \n      This specification defines four new cipher suites and seven new\n      signature schemes based on GOST R 34.12-2015, GOST R 34.11-2012 and\n      GOST R 34.10-2012 algorithms.\n\n  "Trusted Multipath-TCP (MPTCP) extension", Hewu Li, Qian Wu, Boyang Wu, Qi\n  Zhang, Jiang Zhou, Jun Liu, 2019-10-30, <draft-hewu-mptcp-trust-00.txt>\n\n      Multipath TCP (MPTCP) adds the capability of using multiple paths to\n      a regular TCP session and is being deployed extensively.  Source\n      Address Validation (SAV) technologies are proposed to prevent network\n      nodes from spoofing others\' IP addresses and thus improve the\n      accountability of networks.  This document proposes a trusted MPTCP\n      extension based on SAV, which enables MPTCP to work with SAV and thus\n      improve the accountability of MPTCP connections.  This extension\n      doesn\'t intend to replace the security solutions to resolving IP\n      forged attacks, like Hash-based Message Authentication Code (HMAC),\n      but to improve the accountability of them and the whole connection.\n\n  "In-situ OAM Deployment", Frank Brockners, Shwetha Bhandari,\n  daniel.bernier@bell.ca, 2019-10-30,\n  <draft-brockners-opsawg-ioam-deployment-00.txt>\n\n      In-situ Operations, Administration, and Maintenance (IOAM) records\n      operational and telemetry information in the packet while the packet\n      traverses a path between two points in the network.  This document\n      provides a framework for IOAM deployment and provides best current\n      practices.\n\n  "Use Cases and Requirements for Web Packages", Jeffrey Yasskin, 2019-10-30,\n  <draft-yasskin-wpack-use-cases-00.txt>\n\n      This document lists use cases for signing and/or bundling collections\n      of web pages, and extracts a set of requirements from them.\n      \n      Note to Readers\n      \n      Discussion of this draft takes place on the ART area mailing list\n      (art@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/search/?email_list=art [1].\n      \n      The source code and issues list for this draft can be found in\n      https://github.com/WICG/webpackage [2].\n\n  "Advertising p2mp policies in BGP", Hooman Bidgoli, Daniel Voyer, Andrew\n  Stone, Rishabh Parekh, Serge Krier, Arvind Venkateswaran, 2019-10-30,\n  <draft-hb-idr-sr-p2mp-policy-00.txt>\n\n      SR P2MP policies are set of policies that enable architecture for\n      P2MP service delivery.\n      \n      A P2MP policy consists of candidate paths that connects the Root of\n      the Tree to a set of Leaves. The P2MP policy is composed of\n      replication segments. A replication segment is a forwarding\n      instruction for a candidate path which is downloaded to the Root,\n      transit nodes and the leaves.\n      \n      This document specifies a new BGP SAFI with a new NLRI in order to\n      advertise P2MP policy from a controller to a set of nodes.\n      \n      This document introduces two new route types within this NLRI, one\n      for P2MP policy and its candidate paths that need to be programmed on\n      the Root node and another for the replication segment and forwarding\n      instructions that needs to be programmed on the Root, and optionally\n      on Transit and Leaf nodes.\n      \n      It should be noted that this document does not specify how the Root\n      and the Leaves are discovered on the controller, it only describes\n      how the P2MP Policy and Replication Segments are programmed from the\n      controller to the nodes.\n\n  "An Experiment of SRv6 Service Chaining at Interop Tokyo 2019 ShowNet", Ryo\n  Nakamura, Yukito Ueno, Teppei Kamata, 2019-10-31,\n  <draft-upa-srv6-service-chaining-exp-00.txt>\n\n      This document reports lessons learned from an experimental deployment\n      of service chaining with Segment Routing over the IPv6 data plane\n      (SRv6) at an event network.  The service chaining part of the network\n      was comprised of four SRv6-capable nodes (three products from\n      different vendors), five SRv6 proxy nodes (two products from\n      different vendors and three open source software), and six services.\n      This network was deployed at Interop Tokyo 2019, and it successfully\n      provided network connectivity and services to all the exhibitors and\n      visitors on the event.\n\n  "Integrity Protection for Network Service Header (NSH) and Encryption of\n  Sensitive Context Headers", Mohamed Boucadair, Tirumaleswar Reddy.K, Dan\n  Wing, 2019-11-20, <draft-rebo-sfc-nsh-integrity-02.txt>\n\n      This specification adds integrity protection and optional encryption\n      of sensitive metadata directly to Network Service Headers (NSH) used\n      for Service Function Chaining (SFC).\n\n  "Internet Services over ICN in 5G LAN Environments", Dirk Trossen,\n  Chonggang Wang, Sebastian Robitzsch, Martin Reed, Mays AL-Naday, Janne\n  Riihijarvi, 2019-10-31, <draft-trossen-icnrg-internet-icn-5glan-00.txt>\n\n      In this draft, we provide architecture and operations for enabling\n      Internet services over ICN over (5G-enabled) LAN environments.\n      Operations include ICN API to upper layers, HTTP over ICN, Service\n      Proxy Operations, ICN Flow Management, Name Resolution, Mobility\n      Handling, and Dual Stack Device Support.\n\n  "Compressed Routing Header (CRH) Helper Option", Xing Li, Congxiao Bao,\n  Eddie Ruan, Ron Bonica, 2019-10-31,\n  <draft-bonica-6man-crh-helper-opt-00.txt>\n\n      This document defines the IPv6 CRH Helper option.  When an SRm6\n      ingress node originates a packet, it can use the IPv6 CRH Helper\n      option to provide SID Forwarding Information Base (SFIB) information\n      to downstream nodes that do not maintain a complete SFIB.\n\n  "Review of the CFRG PAKE Proposals", Yaron Sheffer, 2019-10-31,\n  <draft-sheffer-cfrg-pake-review-00.txt>\n\n      This draft consists of the author\'s review of the password-\n      authenticated key exchange (PAKE) protocols, as submitted to the\n      IRTF\'s CFRG.  All opinions here are the author\'s alone.\n\n  "Privacy and Security Threat Analysis for Private Messaging", Iraklis\n  Symeonidis, Bernie Hoeneisen, 2019-10-31,\n  <draft-symeonidis-pearg-private-messaging-threats-00.txt>\n\n      Modern email and instant messaging applications offer private\n      communications between users.  As IM and Email network designs become\n      more similar, both share common concerns about security and privacy\n      of the information exchanged.  However, the solutions available to\n      mitigate these threats and to comply with the requirements may\n      differ.  The two communication methods are, in fact, built on\n      differing assumptions and technologies.  Assuming a scenario of\n      untrusted servers, we analyze threats against message delivery and\n      storage, the requirements that these systems need, and the solutions\n      that exist in order to help implement secure and private messaging.\n      From the discussed technological challenges and requirements, we aim\n      to derive an open standard for private messaging.\n\n  "PCEP Extensions for Signaling Multipath Information", Mike Koldychev, Siva\n  Sivabalan, Tarek Saad, Vishnu Beeram, Hooman Bidgoli, Bhupendra Yadav,\n  2019-10-31, <draft-koldychev-pce-multipath-00.txt>\n\n      This document introduces a mechanism to communicate multipath\n      information in PCEP as a set of Explicit Route Objects (EROs).  A\n      special object is defined to carry per ERO attributes.  This\n      mechanism is applicable to SR-TE and RSVP-TE.\n\n  "Real-time text media handling in multi-party conferences", Gunnar\n  Hellstrom, 2019-10-31, <draft-hellstrom-mmusic-multi-party-rtt-00.txt>\n\n      This memo specifies methods for Real-Time Text (RTT) media handling\n      in multi-party calls.  The main solution is to carry Real-Time text\n      by the RTP protocol in a time-sampled mode according to RFC 4103.\n      The main solution for centralized multi-party handling of real-time\n      text is achieved through a media control unit coordinating multiple\n      RTP text streams into one RTP session.\n      \n      Identification for the streams are provided through the RTCP\n      messages.  This mechanism enables the receiving application to\n      present the received real-time text medium in different ways\n      according to user preferences.  Some presentation related features\n      are also described explaining suitable variations of transmission and\n      presentation of text.\n      \n      Call control features are described for the SIP environment.  A\n      number of alternative methods for providing the multi-party\n      negotiation, transmission and presentation are discussed and a\n      recommendation for the main one is provided.  Two alternative methods\n      using a single RTP stream and source identification inline in the\n      text stream are also described, one of them being provided as a lower\n      functionality fallback method for endpoints with no multi-party\n      awareness for RTT.\n      \n      Brief information is also provided for multi-party RTT in the WebRTC\n      environment.\n      \n      EDITOR NOTE: A number of alternatives are specified for discussion.\n      A decision is needed which alternatives are preferred and then how\n      the preferred alternatives shall be emphasized.\n\n  "EVPN-VPWS Seamless Integration with Legacy VPWS", Patrice Brissette, Ali\n  Sajassi, LucAndre Burdet, Jim Uttaro, Daniel Voyer, Iman Ghamari, Eddie\n  Leyton, 2019-11-17, <draft-brissette-bess-evpn-vpws-seamless-01.txt>\n\n      This document specifies mechanisms for backward compatibility of\n      Ethernet VPN Virtual Private Wire Service (EVPN-VPWS) solutions with\n      legacy Virtual Private Wire Service (VPWS).  It provides mechanisms\n      for seamless integration in the same MPLS/IP network on a per-\n      pseudowire or per flexible-crossconnect service basis.\n      Implementation of this document enables service providers to\n      introduce EVPN-VPWS PEs in their brown-field deployments of legacy\n      VPWS networks.  This document specifies control-plane and forwarding\n      behaviour needed for auto-discovery of a pseudowire in order to\n      enable seamless integration between EVPN-VPWS and VPWS PEs.\n\n  "Binary Structured HTTP Headers", Mark Nottingham, 2020-01-09,\n  <draft-nottingham-binary-structured-headers-01.txt>\n\n      This specification defines a binary serialisation of Structured\n      Headers for HTTP, along with a negotiation mechanism for its use in\n      HTTP/2.  It also defines how to use Structured Headers for many\n      existing headers - thereby "backporting" them - when supported by two\n      peers.\n\n  "Fast Address Validation", Qing An, Dapeng Liu, Yanmei Liu, Hao Wang,\n  2019-11-01, <draft-an-fast-address-validation-00.txt>\n\n      This document describes a fast address validation method for QUIC.\n\n  "Configurable Car Infotainment Service", Seok Koh, Dong-Kyu Choi, Joong-Hwa\n  Jung, Hye-Been Nam, 2019-11-04, <draft-sjkoh-ccis-01.txt>\n\n      As the connected car and autonomous car technologies grows, many car\n      manufacturers are interested in in-vehicle infotainment (IVI)\n      services.  In addition, car-sharing services are expected to attract\n      attention in the future automotive industry.  The devices and\n      contents in the car are frequently used not only by the car owner but\n      also by others.  Automobile manufacturers are currently researching\n      on developing their own IVI service platforms.  Contrary to these\n      trends, however, IVI services present a risk that anyone can access\n      the IVI services and lack scalability with other manufacturers.\n      \n      In this document, we introduce the system which provide the basic\n      function that can be commonly used in IVI services growing very\n      rapidly.  This system is consisting of master, device and user.  This\n      system Users are categorized into different types, and services\n      provided by devices have different levels.  These are registered and\n      managed by master.  So, users are delivered different services\n      according to user type.  In addition, devices can be dynamically\n      registered and deregistered to the master.\n\n  "Improving the Reaction of Customer Edge Routers to Renumbering Events",\n  Fernando Gont, Jan Zorz, Richard Patterson, 2019-11-01,\n  <draft-gont-v6ops-cpe-slaac-renum-00.txt>\n\n      In scenarios where network configuration information related to IPv6\n      prefixes becomes invalid without any explicit signaling of that\n      condition (such as when a CPE crashes and reboots without knowledge\n      of the previously-employed prefixes), hosts on the local network will\n      continue using stale prefixes for an unacceptably long period of\n      time, thus resulting in connectivity problems.  This document\n      specifies improvements to Customer Edge Routers that help mitigate\n      the aforementioned problem for typical residential and small office\n      scenarios.\n\n  "Overview and Principles of Internet Traffic Engineering", Adrian Farrel,\n  2019-12-06, <draft-dt-teas-rfc3272bis-05.txt>\n\n      This memo describes the principles of Traffic Engineering (TE) in the\n      Internet.  The document is intended to promote better understanding\n      of the issues surrounding traffic engineering in IP networks, and to\n      provide a common basis for the development of traffic engineering\n      capabilities for the Internet.  The principles, architectures, and\n      methodologies for performance evaluation and performance optimization\n      of operational IP networks are discussed throughout this document.\n      \n      This work was first published as RFC 3272 in May 2002.  This document\n      obsoletes RFC 3272 by making a complete update to bring the text in\n      line with current best practices for Internet traffic engineering and\n      to include references to the latest relevant work in the IETF.\n\n  "GOST XML digital signature syntax", Pavel Smirnov, Maria Paramonova,\n  Mikhail Khomenko, Artyom Makarov, 2019-11-01, <draft-smirnov-xmldsig-00.txt>\n\n      This document specifies XML digital signature syntax and methods of\n      including hash-based message authentication code (HMAC) within the\n      XML document to support the Russian cryptographic standard\n      algorithms.\n\n  "Storing BMP messages in MRT Format", Colin Petrie, 2019-11-01,\n  <draft-petrie-grow-mrt-bmp-00.txt>\n\n      This document extends the Multi-threaded Routing Toolkit (MRT) export\n      format to support the storage of BMP messages.\n\n  "The Qualcomm Wireless Edge Services (QWES) Attestation Token", Giridhar\n  Mandyam, Vivek Sekhar, Shahid Mohammed, 2019-11-01,\n  <draft-mandyam-rats-qwestoken-00.txt,.pdf>\n\n      An attestation format based on the Entity Attestation Token (EAT) is\n      described.  The Qualcomm Wireless Edge Services (QWES) token is used\n      in the context of device onboarding and authentication.  It is\n      verified in the same manner as any CBOR Web Token (CWT).\n\n  "Architecture Discussion on SRv6 Mobile User plane", Miya Kohno, Francois\n  Clad, Pablo Camarillo, Zafar Ali, 2019-11-01,\n  <draft-kohno-dmm-srv6mob-arch-00.txt>\n\n      Layer separation is a powerful concept in system architecture.  In\n      the area of mobility, by separating GTP-U that is the overlay tunnel,\n      and the IP transport network that is the underlay, the operation of\n      the mobile network and the transport network can be separated,\n      allowing them to evolve independently.\n      \n      However, evolving individually at each layer promotes local\n      optimization and may result in non-optimal solutions overall in the\n      long run.\n      \n      When a drastic architectural transition is required, for example, in\n      the 5G era where various SLAs and completely new data intensive\n      services are assumed, it is necessary to reconsider the architecture\n      holistically, rather than from the viewpoint of individual layer.\n      \n      One important value propositions of SRv6 mobile user plane is the\n      possible optimization across the existing multiple layers.\n      \n      This document discusses the architectural implications of applying\n      SRv6 mobile user plane, especially regarding the possible\n      optimization of existing layers.  Then it takes 5G requirements and\n      use cases as an example, and describes how these use cases are simply\n      and effectively realized with the inter-layer optimization capability\n      of SRv6 mobile user plane.  Thus it show that SRv6 mobile use plane\n      is a right architectural choice for the 5G era.\n\n  "Encrypting ICE candidates to improve privacy and connectivity", Alex\n  Drake, Justin Uberti, Qingsi Wang, 2019-11-01,\n  <draft-wang-mmusic-encrypted-ice-candidates-00.txt>\n\n      WebRTC applications collect ICE candidates as part of the process of\n      creating peer-to-peer connections.  To maximize the probability of a\n      direct peer-to-peer connection, client private IP addresses can be\n      included in this candidate collection, but this has privacy\n      implications.  This document describes a way to share local IP\n      addresses with local peers without compromising client privacy.\n      During the ICE process, local IP addresses are encrypted and\n      authenticated using a pre-shared key and cipher suite before being\n      put into ICE candidates as hostnames with an ".encrypted" pseudo-top-\n      level domain.  Other peers who also have the PSK are able to decrypt\n      these addresses and use them normally in ICE processing.\n\n  "EVPN and BGP-based L2VPN Seamless Integration", Wen Lin, Bin Wen, Voitek\n  Kozak, Jorge Rabadan, 2019-11-01,\n  <draft-lin-bess-evpn-bgp-based-l2vpn-seamless-integ-00.txt>\n\n      This document presents a seamless integration solution for BGP-based\n      Layer-2 VPN (L2VPN) and EVPN to provide point-to-point Virtual\n      Private Wire Service (VPWS).  In addition, this document also extends\n      the existing seamless integration for multipoint Ethernet VPN service\n      with all-active multihoming support.  The specified solution allows\n      the coexistence of EVPN and L2VPN services under the same point-to-\n      point or multipoint VPN instance.  By using this seamless integration\n      solution, a service provider can introduce EVPN into their existing\n      L2VPN network or migrate from an existing L2VPN based network to\n      EVPN.\n\n  "Domain Suggestion Extension for the Extensible Provisioning Protocol\n  (EPP)", Alexander Mayrhofer, 2019-11-01,\n  <draft-mayrhofer-epp-domain-suggest-00.txt>\n\n      This document specifies an EPP Extension that allows servers to\n      suggest available domain names to clients, for example in cases where\n      the originally desired domain name is unavailable for registration.\n\n  "X509v3 EAP Parameter Extension", Jan-Frederik Rieckers, 2019-11-01,\n  <draft-rieckers-eapparameterextension-00.txt>\n\n      This document specifies an extension to X509v3 certificates for EAP-\n      TLS servers to mitigate some flaws in the specification to the use of\n      TLS in EAP as specified in RFC5216.  The specified extension enables\n      clients to decide whether to trust the certificate presented by the\n      EAP-TLS server by including information implicitly defined by login\n      credentials or communication context in the server certificate.\n\n  "DetNet Data Plane: IEEE 802.1 Time Sensitive Networking over SRv6",\n  Xueshun Wang, Jinyou Dai, Jianhua Liu, Jing Xu, 2019-11-01,\n  <draft-wang-detnet-tsn-over-srv6-00.txt>\n\n      This document specifies the Deterministic Networking data plane when\n      TSN networks interconnected over an Segment Routing IPv6 Packet\n      Switched Networks.\n\n  "Support for Enterprise-specific TLVs in the BGP Monitoring Protocol",\n  Paolo Lucente, Yunan Gu, 2019-11-02,\n  <draft-lucente-grow-bmp-tlv-ebit-00.txt>\n\n      Message types defined by the BGP Monitoring Protocol (BMP) do\n      provision for optional trailing data in TLV - Type, Length, Value -\n      format; however the space for Type value is unique and governed by\n      IANA.  To allow the usage of vendor-specific TLVs, a mechanism to\n      define per-vendor Type values is required.  With this document we\n      want to introduce an Enterprise Bit, or E-bit, for such purpose.\n\n  "State-updating mechanism in RSVP-TE for MPLS network", Jun Gao, Jinyou\n  Dai, 2019-11-02, <draft-gao-mpls-teas-rsvpte-state-update-00.txt>\n\n      RSVP-TE has the following advantages: source routing capability,\n      and the ability to reserve resources hop by hop along the LSP path.\n      \n      RSVP takes a "soft state" approach to managing the reservation\n      state in routers and hosts. The use of Refresh messages to cover\n      many possible failures has resulted in a number of operational\n      problems.  One problem relates to scaling, another relates to the\n      reliability and latency of RSVP Signaling.\n      \n      This document describes a number of mechanisms that can be used to\n      reduce processing overhead requirements of refresh messages. These\n      extension present no backwards compatibility issues.\n\n  "Segment-Routing over Forwarding Adjacency Links", Tarek Saad, Vishnu\n  Beeram, Colby Barth, 2019-11-02, <draft-saad-sr-fa-link-00.txt>\n\n      Label Switched Paths (LSPs) set up in Multiprotocol Label Switching\n      (MPLS) networks can be used to form Forwarding Adjacency (FA) links\n      that carry traffic in those networks.  An FA link can be assigned\n      Traffic Engineering (TE) parameters that allow other LSR(s) to\n      include it in their constrained path computation.  FA link(s) can be\n      also assigned Segment-Routing (SR) segments that enable the steering\n      of traffic on to the associated FA link(s).  The TE and SR attributes\n      of an FA link can be advertised using known link state protocols.\n      This document elaborates on the usage of FA link(s) and their\n      attributes in SR enabled networks.\n\n  "Predictable Multipath TCP (MPTCP) extension", Qian Wu, Hewu Li, Qi Zhang,\n  Jun Liu, 2019-11-02, <draft-qian-mptcp-predict-00.txt>\n\n      Multipath TCP (MPTCP) adds the capability of using multiple paths to\n      a regular TCP session, which is quite suitable for integrated network\n      scenarios where multiple paths almost always exist.  However, link\n      handover and link on-off switching happen frequently in network\n      systems that integrate different systems (especially the systems that\n      continually move), which defeats the quality of MPTCP connections.\n      Information about the link handover and on-off switching in above-\n      mentioned scenarios can be predicted in advance, but MPTCP is not\n      capable of utilizing the prediction information.  This document\n      suggests MPTCP be extended with the capacity of obtaining and\n      utilizing the prediction information.  Furthermore, the document\n      describes one possible way to enhance MPTCP with prediction\n      information, which proposes a modified MPTCP scheduler utilizing link\n      on-off prediction information.\n\n  "PE-CE Control Plane for EVPN", Neeraj Malhotra, Keyur Patel, Jorge\n  Rabadan, 2019-11-02, <draft-malhotra-bess-evpn-pe-ce-00.txt>\n\n      In an EVPN network, EVPN PEs provide VPN bridging and routing service\n      to connected CE devices based on BGP EVPN control plane. At present,\n      there is no PE-CE control plane defined for an EVPN PE to learn CE\n      MAC, IP, and any other routes from a CE that may be distributed in\n      EVPN control plane to enable unicast flows between CE devices. As a\n      result, EVPN PEs rely on data plane based gleaning of source MACs for\n      CE MAC learning, ARP/ND snooping for CE IPv4/IPv6 learning, and in\n      some cases, local configuration for learning prefix routes behind a\n      CE. A PE-CE control plane alternative to this traditional learning\n      approach, where applicable, offers certain distinct advantages that\n      in turn result in simplified EVPN operation.\n      \n      This document defines a PE-CE control plane as an optional\n      alternative to traditional non-control-plane based PE-CE learning in\n      an EVPN network. It defines PE-CE control plane procedures and TLVs\n      based on L3DL as the base protocol, enumerates advantages that may be\n      achieved by using this PE-CE control plane, and discusses in detail\n      EVPN use cases that are simplified as a result.\n\n  "Grasping Network Situation for Improving End-to-End Throughput", Pyung-Soo\n  Kim, 2019-11-02, <draft-pskim-grasping-network-situation-00.txt>\n\n      In this draft, a mechanism to grasp the network situation is proposed\n      for improving end-to-end path throughput. The proposed mechanism is\n      based on the active packet-train probing based estimation. The\n      proposed mechanism defines three cases of the difference between the\n      average output gap and the input gap, and then reflects fully them.\n      Since three cases are handled respectively by appropriate\n      corresponding manners, the proposed mechanism can be expected to\n      reduce the detection error for the turning point. Therefore, through\n      the proposed mechanism, the available bandwidth can be estimated more\n      reliably.\n\n  "IETF Definition of Transport Slice", Reza Rokui, Shunsuke Homma, Kiran\n  Makhijani, 2019-11-03, <draft-nsdt-teas-transport-slice-definition-00.txt>\n\n      This document describes the definition of transport slice in IETF and\n      considerations on implementation (realization) of transport slice.\n      This work is part of work on TEAS WG network slicing Design Team.\n\n  "Randomized Response Mechanisms in RRT Measurements for HTTP/3", Amelia\n  Andersdotter, Shivan Sahib, 2019-11-03,\n  <draft-andersdotter-rrm-for-rrt-in-http3-00.txt>\n\n      The latency spin bit is an optional feature included in the QUIC\n      transport protocol [I-D-QUIC].  It enables passive, on-path\n      observations for estimation of latency.  This document presents the\n      results of an inquiry into the potential of using randomized response\n      mechanisms (RRM) to reduce privacy loss in latency measurements.  It\n      concludes that RRM could be used to introduce choice for clients in\n      preserving privacy in latency measurements.  But the trade-offs,\n      especially since the latency spin bit is already optional, do not\n      favour RRM.\n\n  "Signaling That an Authoritative DNS server offers DoT", John Levine,\n  2019-11-17, <draft-levine-dprive-signal-02.txt>\n\n      DNS resolvers that wish to use DNS over TLS to authoritative servers\n      (ADoT) need some way to tell whether server offers DoT.  This\n      document describes some ways that a server might signal that it uses\n      DoT.\n\n  "Bulk Subscription to YANG Event Notification", Zitao Wang, Qin WU,\n  2019-11-03, <draft-wang-netconf-bulk-subscribed-notifications-00.txt>\n\n      This document defines a YANG data model and associated mechanism that\n      allows subscriber applications to bulk subscribe to publishers\' event\n      streams based on their requirements.  And it also allows the\n      publishers to report multiple event streams or subscriptions into a\n      single notification message based on group identifier affiliation.\n\n  "IS-IS Flood Reflection", Tony Przygienda, Chris Bowers, Yiu Lee, Alankar\n  Sharma, Russ White, 2020-01-07,\n  <draft-przygienda-lsr-flood-reflection-01.txt>\n\n      This document describes an optional ISIS extension that allows the\n      creation of IS-IS flood reflection topologies.  Flood reflection\n      allows the creation of topologies where L1 areas provide transit\n      forwarding for L2 destinations within an L2 topology.  It\n      accomplishes this by creating L2 flood reflection adjacencies within\n      each L1 area.  The L2 flood reflection adjacencies are used to flood\n      L2 LSPDUs, and they are used in the L2 SPF computation.  However,\n      they are not used for forwarding.  This arrangement gives the L2\n      topology better scaling properties.  In addition, only those routers\n      directly participating in flood reflection have to support the\n      feature.  This allows for the incremental deployment of scalable L1\n      transit areas in an existing network, without the necessity of\n      upgrading other routers in the network.\n\n  "RSVP-TE Extensions in Support of Proactive Protection", Yi Lin,\n  2019-11-03, <draft-lin-ccamp-gmpls-proactive-protection-00.txt>\n\n      This document describes protocol-specific procedures and extensions\n      for Generalized Multi-Protocol Label Switching (GMPLS) Resource\n      ReSerVation Protocol - Traffic Engineering (RSVP-TE) signaling to\n      support Label Switched Path (LSP) Proactive Protection, which create\n      the protection LSP after a failure is predicted and before it\n      becomes a real failure.\n\n  "IS-IS YANG Model Augmentations for Additional Features - Version 1", Acee\n  Lindem, Stephane Litkowski, Yingzhen Qu, 2019-11-03,\n  <draft-acee-lsr-isis-yang-augmentation-v1-00.txt>\n\n      This document defines YANG data modules augmenting the IETF IS-IS\n      YANG model to provide support for IS-IS Minimum Remaining Lifetime as\n      defined in RFC 7987.\n\n  "The Privacy Pass Protocol", Alex Davidson, Nick Sullivan, 2019-11-03,\n  <draft-privacy-pass-00.txt>\n\n      This document specifies the Privacy Pass protocol for anonymously\n      authorizing clients with services on the Internet.\n      \n      Note to Readers\n      \n      Source for this draft and an issue tracker can be found at\n      https://github.com/grittygrease/draft-privacy-pass [1].\n\n  "Color Operation with BGP Label Unicast", Louis Chan, 2019-11-03,\n  <draft-chan-idr-bgp-lu2-00.txt>\n\n      This document specifies how to carry colored path advertisement\n      via an\n      enhancement            to the existing protocol BGP Label Unicast. It\n      would\n      allow backward compatibility            with RFC8277.\n      \n      The targeted solution is to use stack of labels advertised via\n      BGP Label\n      Unicast            2.0 for end to end traffic steering across multiple\n      IGP domains.\n      The operation is            similar to Segment Routing.\n      \n      This proposed protocol will convey the necessary reachability\n      information to the            ingress PE node to construct an end to end\n      path\n\n  "Performance Measurement for Geneve", Min Xiao, Gregory Mirsky, Juniper\n  Networks, 2019-11-03, <draft-xiao-nvo3-pm-geneve-00.txt>\n\n      This document describes the method to achieve Performance Measurement\n      (PM) in point-to-point Generic Network Virtualization Encapsulation\n      (Geneve) tunnels that form an overlay network.\n\n  "YANG Data Node Self Explanation Tags", Ran Tao, Qin WU, 2019-11-03,\n  <draft-tao-netmod-yang-node-tags-00.txt>\n\n      This document defines a method to tag data node associated with\n      telemetry data in YANG Modules.  This YANG data node tagging method\n      can be used to filter queries of operational state on a server during\n      a "pub/sub" service for YANG datastore updates when the state of all\n      subscriptions of a particular Subscriber to be fetched is huge, so\n      that the amount of data to be streamed out to the destination can be\n      greatly reduced.\n      \n      An extension statement to be used to indicate YANG data node tags\n      that SHOULD be added by the module implementation automatically(i.e.,\n      outside of configuration).\n      \n      A YANG module [RFC7950] is defined, which augment Module tag model\n      and provides a list of data node entries to allow for adding or\n      removing of data node tags as well as viewing the set of tags\n      associated with a YANG module.\n\n  "Notification Capabilities Model Extension for self-explanation data Node\n  tag capability support", Ran Tao, Wu Bo, 2019-11-03,\n  <draft-tao-netconf-notif-node-tag-capabilities-00.txt>\n\n      Before a client application subscribes to updates from a datastore,\n      server capabilities related to "Subscription to YANG Datastores" can\n      be advertised using YANG Instance Data format.  These server\n      capabilities can be documented at implement time or reported at run-\n      time.\n      \n      This document proposes a YANG module for Data Node tag capability\n      support which augments YANG Push Notification Capabilities model and\n      provide additional self-explanation data node attributes associated\n      with node selector within per-node capabilities.\n\n  "Application-aware IPv6 Networking (APN6) Framework", Zhenbin Li, Shuping\n  Peng, Daniel Voyer, Chongfeng Xie, Peng Liu, Chang Liu, Kentaro Ebisawa,\n  Stefano Previdi, Jim Guichard, 2019-11-03, <draft-li-apn6-framework-00.txt>\n\n      A multitude of applications are carried over the network, which have\n      varying needs for network bandwidth, latency, jitter, and packet\n      loss, etc.  Some new emerging applications (e.g. 5G) have very\n      demanding performance requirements.  However, in current networks,\n      the network and applications are decoupled, that is, the network is\n      not aware of the applications\' requirements in a fine granularity.\n      Therefore, it is difficult to provide truly fine-granularity traffic\n      operations for the applications and guarantee their SLA requirements.\n      \n      This document proposes a new framework, named Application-aware IPv6\n      Networking (APN6), which makes use of IPv6 encapsulation to convey\n      the application characteristic information such as application\n      identification and its network performance requirements into the\n      network to facilitate service provisioning, perform application-level\n      traffic steering and network resource adjustment.\n\n  "A YANG Data Model for Client Signal Performance Monitoring", Haomian\n  Zheng, Italo Busi, Zheng Yanlei, 2019-11-03,\n  <draft-zheng-ccamp-client-pm-yang-00.txt>\n\n      A transport network is a server-layer network to provide connectivity\n      services to its client.  Given the client signal is configured, the\n      followup function for performance monitoring, such as latency and bit\n      error rate, would be needed for network operation.\n      \n      This document describes the data model to support the performance\n      monitoring functionalities.  The module carefully maps to relevant\n      performance monitoring standards.\n\n  "Framework for Use of ECA (Event Condition Action) in Network Self\n  Management", Mohamed Boucadair, Qin WU, Zitao Wang, Daniel King, Chongfeng\n  Xie, 2019-11-03, <draft-bwd-netmod-eca-framework-00.txt>\n\n      Event-driven management is meant to provide a useful method to\n      monitor state change of managed objects and resources, and facilitate\n      automatic triggering of a response to events, based on an established\n      set of rules.  This would provide rapid autonomic responses to\n      specific conditions, enabling self-management behaviors, including:\n      self-configuration, self-healing, self-optimization, and self-\n      protection.\n      \n      This document provides a framework that describes the architecture\n      for supporting event-driven management of managed object state across\n      devices.  It does not describe specific protocols or protocol\n      extensions needed to realize the objectives and capabilities\n      discussed in the document.\n\n  "An Open Congestion Control Architecture for high performance fabrics",\n  Zhuangyan, Wenhao Sun, Long Yan, 2019-11-03,\n  <draft-zhuang-tsvwg-open-cc-architecture-00.txt,.pdf>\n\n      This document describes an open congestion control architecture of\n      high performance fabrics for the cloud operators and algorithm\n      developers to deploy or develop new congestion control algorithms as\n      well as make appropriate configurations for traffics on smart NICs in\n      a more efficient and flexible way.\n\n  "Problem Statements of FlexE Interface Management", Yuanlong Jiang, Fan\n  Yang, Italo Busi, Junfang Wang, 2019-11-04,\n  <draft-jiang-ccamp-flexe-ifmps-00.txt>\n\n      This document outlines the problem statements for FlexE interface\n      management; it also gives an analysis of configuration requirements\n      for Flex Ethernet (FlexE) interface management. Requirements on FlexE\n      interface management are summarized in the end.\n\n  "Comparison of 6lo and SCHC", Ana Minaburo, Laurent Toutain, 2019-11-04,\n  <draft-toutain-6lo-6lo-and-schc-00.txt>\n\n      6lo and 6lowpan have standardized a stateless IPv6 and UDP\n      compression method for mesh networks.  SCHC proposes a generic\n      compression mechanism that can be applied to any protocol stack.  The\n      lpwan working group is focusing on star topologies for IPv6, UDP and\n      CoAP header compression and fragmentation.\n      \n      This document summarizes the differences between 6lo and SCHC and\n      possible combination of SCHC and 6lo.\n\n  "Unified Identifier in IPv6 Segment Routing Networks", Weiqiang Cheng,\n  Shaofu Peng, Liu Aihua, Gregory Mirsky, XiaoLan Wan, Cheng Wei, Shay,\n  2019-11-04, <draft-wmsaxw-6man-usid-id-use-00.txt>\n\n      Segment Routing architecture leverages the paradigm of source\n      routing.  It can be realized in a network data plane by prepending\n      the packet with a list of instructions, a.k.a. segments.  A segment\n      can be encoded as a Multi-Protocol Label Switching (MPLS) label, IPv4\n      address, or IPv6 address.  Segment Routing can be applied in the MPLS\n      data plane by encoding segments in an MPLS label stack.  It also can\n      be applied to the IPv6 data plane by encoding a list of segment\n      identifiers in IPv6 Segment Routing Extension Header (SRH).  In this\n      document is described the use of unified segment identifiers in use\n      cases where interworking between SR-MPLS and SRv6 is required.\n\n  "Framework of Compute First Networking (CFN)", Li Yizhou, Jianfei(Jeffrey)\n  He, Liang Geng, Peng Liu, Yong Cui, 2019-11-04,\n  <draft-li-rtgwg-cfn-framework-00.txt>\n\n      Compute First Networking (CFN) leverages both computing and\n      networking status to help determine the optimal edge among multiple\n      edge sites with different geographic locations to serve a specific\n      edge computing request. Requests for the same service can be\n      determined and dispatched to different edges based on service\n      requirements, network and computing resource conditions and other\n      factors to achieve better load balancing and system efficiency. The\n      request needs to be dispatched to the selected edge in real time and\n      the subsequent packets from the same flow should be served by the\n      same edge for flow affinity. This document describes a framework of\n      CFN to achieve the desired features.\n\n  "A Report on Compute First Networking (CFN) Field Trial", Shuheng Gu,\n  Guanhua Zhuang, Huijuan Yao, Xunwen Li, 2019-12-01,\n  <draft-gu-rtgwg-cfn-field-trial-01.txt>\n\n      Compute First Networking (CFN) enables the routing of the service\n      request to an optimal edge site to improve the overall system load\n      balancing and efficiency. Especially when an edge site is overloaded,\n      other edges with service equivalency can dynamically serve the\n      request. This document describes a CFN field trial to show the effect\n      that CFN can achieve. Edge to edge interaction to get the available\n      computing resources information for services and the network status\n      to each other is introduced. Data plane to support late binding based\n      dynamic anycast is illustrated too. The field trial shows that CFN\n      can greatly improve the overall query per second served for a service\n      hosted on multiple edges in a more balanced way.\n\n  "Requirements for IoT Services based on Visible Light Communications", Seok\n  Koh, Cheol-Min Kim, 2019-11-04, <draft-sjkoh-requirements-iot-vlc-00.txt>\n\n      This document describes the requirements for IoT Services based on\n      Visible Light Communication (VLC) to effectively provide IoT services\n      in the VLC-based networks.  This document includes the overview of\n      VLC technology and the concepts of VLC-based IoT services, and the\n      requirements for IoT services in the VLC-based networks.\n\n  "New Spin bit enabled measurements with one or two more bits", Mauro\n  Cociglio, Giuseppe Fioccola, Fabio Bulgarella, Riccardo Sisto, 2019-11-04,\n  <draft-cfb-tsvwg-spinbit-new-measurements-00.txt>\n\n      This document introduces additional measurements by using the same\n      spin bit signal as defined in [I-D.trammell-tsvwg-spin] and\n      [I-D.trammell-ippm-spin].  The spin bit signal alone is not enough to\n      evaluate correctly in every network condition the RTT of a flow.  In\n      order to solve this problem, it is theorized the possibility of\n      introducing an additional validation signal called delay bit, similar\n      to what is done by the Valid Edge Counter (VEC), but using just one\n      bit instead of two.  An alternative with two bits is also introduced\n      with a so called loss bit.  More in general a loss signal is defined\n      to measure packet loss and two alternatives are presented with one\n      bit and two bits.\n\n  "Control Plane Considerations for Enhanced VPN", Jie Dong, Zhenbin Li,\n  Fengwei Qin, 2019-11-04, <draft-dong-teas-enhanced-vpn-control-plane-00.txt>\n\n      Enhanced VPN (VPN+) is an enhancement to VPN services to support the\n      needs of new applications, particularly including the applications\n      that are associated with 5G services.  An enhanced VPN may be used\n      for 5G transport network slicing, and will also be of use in more\n      generic scenarios.  [I-D.ietf-teas-enhanced-vpn] describes the\n      framework and candidate component technologies for providing enhanced\n      VPN services.  This document describes the control plane\n      requirements, functions and considerations to enable VPN+ services.\n      Specifically, the scalability of control plane is analyzed, and the\n      proposed optimization mechanisms are described.\n\n  "BGP-LS Extensions for Segment Routing based Enhanced VPN", Jie Dong, Zhibo\n  Hu, 2019-11-04, <draft-dong-idr-bgpls-sr-enhanced-vpn-00.txt>\n\n      Enhanced VPN (VPN+) is an enhancement to VPN services to support the\n      needs of new applications, particularly including the applications\n      that are associated with 5G services.  These applications require\n      better isolation and have more stringent performance requirements\n      than that can be provided with traditional overlay VPNs.  An enhanced\n      VPN may be used for 5G transport network slicing, and will also be of\n      use in more generic scenarios.  This document specifies BGP-LS based\n      mechanism with necessary extensions to advertise the information of\n      Segment Routing (SR) based virtual networks.  These virtual networks\n      could be used as the underlay of enhanced VPN service.  The proposed\n      mechanism is applicable to both segment routing with MPLS data plane\n      (SR-MPLS) and segment routing with IPv6 data plane (SRv6).\n\n  "Context-Aware Navigator Protocol for IP-Based Vehicular Networks", Jaehoon\n  Jeong, Bien Mugabarigira, Zhong Xiang, Yiwen Shen, 2019-11-04,\n  <draft-jeong-ipwave-context-aware-navigator-00.txt>\n\n      This document proposes a Context-Aware Navigator Protocol (CAN) for\n      IP-based vehicular networks for cooperative navigation among vehicles\n      in road networks.  This CAN aims at the enhancement of driving safety\n      through a light-weight driving information sharing method.  The CAN\n      protocol uses an IPv6 Neighbor Discovery (ND) option to convey\n      driving information such as a vehicle\'s position, speed,\n      acceleration/deceleration, and direction, and a driver\'s driving\n      action (e.g., braking and accelerating).\n\n  "Basic Support for Security and Privacy in IP-Based Vehicular Networks",\n  Jaehoon Jeong, Yiwen Shen, J., PARK, 2019-11-04,\n  <draft-jeong-ipwave-security-privacy-00.txt>\n\n      This document describes possible attacks of security and privacy in\n      IP Wireless Access in Vehicular Environments (IPWAVE).  It also\n      proposes countermeasures for those attacks.\n\n  "SRv6 Deployment Consideration", Hui Tian, Feng Zhao, Chongfeng Xie, Tong\n  Li, Jichun Ma, Shuping Peng, Zhenbin Li, Yaqun Xiao, 2019-11-04,\n  <draft-tian-spring-srv6-deployment-consideration-00.txt>\n\n      SRv6 has significant advantages over SR-MPLS and has attracted more\n      and more attention and interest from network operators and verticals.\n      Smooth network migration towards SRv6 is a key focal point and this\n      document provides network migration guidance and recommendations on\n      solutions in various scenarios.  Deployment cases with SRv6 are also\n      introduced.\n\n  "Destination-IP-Origin-AS Filter for BGP Flow Specification", Haibo Wang,\n  Aijun Wang, Shunwan Zhuang, 2019-11-04,\n  <draft-wang-idr-flowspec-dip-origin-as-filter-01.txt>\n\n      This document specifies a new BGP-FS component type to support AS-\n      level filtering.  The match field is the origin AS number of the\n      destination IP address that is encoded in the Flowspec NLRI.\n\n  "Resource Public Key Infrastructure (RPKI) Repository Requirements", Tim\n  Bruijnzeels, 2019-11-04, <draft-sidrops-bruijnzeels-deprecate-rsync-00.txt>\n\n      This document updates the profile for the structure of the Resource\n      Public Key Infrastructure (RPKI) distributed repository [RFC6481] by\n      describing how the RPKI Repository Delta Protocol (RRDP) [RFC8182]\n      can be used, and stipulating that repositories which are made\n      available over RRDP are no longer required to be available over\n      rsync.\n      \n      The Profile for X.509 PKIX Resource Certificates [RFC6487] uses rsync\n      URIs in the Authority Information Access, Subject Information Access,\n      and CRL Distribution Points extensions.  This document leaves this\n      unchanged, meaning that rsync URIs are still used for naming and\n      finding objects in the RPKI.  However, it is no longer guaranteed\n      that objects can be retrieved using these URIs.\n\n  "An Alternative Delta Time encoding for CCNx using Interval Time from\n  RFC5497", Cenk Gundogan, Thomas Schmidt, David Oran, Matthias Waehlisch,\n  2019-11-04, <draft-gundogan-icnrg-ccnx-timetlv-00.txt>\n\n      CCNx utilizes Delta Time for a number of functions.  When using CCNx\n      in environments with constrained nodes and/or bandwidth constrained\n      networks, it is valuable to have a compressed representation of delta\n      time.  In order to do so, either accuracy or dynamic range has to be\n      sacrificed.  Since the current uses of delta time do not require both\n      simultaneously, one can consider a logarithmic encoding such as that\n      specified in RFC5497.  This document updates _CCNx messages in TLV\n      Format_ (RFC8609) to specify this alternative encoding.\n\n  "Transport Network Slice YANG Data Model", Xufeng Liu, Jeff Tantsura, Igor\n  Bryskin, Luis Contreras, Qin WU, 2019-11-04,\n  <draft-liu-teas-transport-network-slice-yang-00.txt>\n\n      This document describes a YANG data model for managing and\n      controlling transport network slices.\n\n  "Problem Statement of MPTCP Transmission Feature Negotiation", Nagesh\n  Shamnur, Zhen Cao, 2019-11-04,\n  <draft-nagesh-mptcp-feature-negotiation-ps-01.txt>\n\n      Path manager and packet scheduler are two important components of\n      MPTCP protocol and associated implementations.  Normally they are\n      implemented and configured statically.  This draft discusses the\n      scenarios where statically configured path manager and packet\n      scheduler are not sufficient, and presents the cases that deserve the\n      negotiation of these multipath transmission features which are\n      currently not addressed by MPTCP.\n\n  "Embedding LOOPS in Geneve", Carsten Bormann, 2019-11-04,\n  <draft-bormann-loops-geneve-binding-00.txt>\n\n      LOOPS (Local Optimizations on Path Segments) aims to provide local\n      in-network loss recovery.  It can be used with tunneling protocols to\n      efficiently recover lost packets on a single segment of an end-to-end\n      path instead of leaving recovery to the end-to-end protocol,\n      traversing the entire path.\n      \n      [I-D.welzl-loops-gen-info] defines the information to be carried\n      between LOOPS ingress and egress nodes in a generic way, giving a\n      guideline on defining the common elements to embed LOOPS functions in\n      various tunnel protocols.  The present document specifies how to\n      embed LOOPS in a specific overlay tunnel protocol, Geneve\n      [I-D.ietf-nvo3-geneve].\n\n  "Network-Based Website Fingerprinting", Ian Goldberg, Tao Wang, Christopher\n  Wood, 2019-11-04, <draft-wood-pearg-website-fingerprinting-00.txt>\n\n      The IETF is well on its way to protecting connection metadata with\n      protocols such as DNS-over-TLS and DNS-over-HTTPS, and work-in-\n      progress towards encrypting the TLS SNI.  However, more work is\n      needed to protect traffic metadata, especially in the context of web\n      traffic.  In this document, we survey Website Fingerprinting attacks,\n      which are a class of attacks that use machine learning techniques to\n      attack web privacy, and highlight metadata leaks used by said\n      attacks.  We also survey proposed mitigations for such leakage and\n      discuss their applicability to IETF protocols such as TLS, QUIC, and\n      HTTP.  We endeavor to show that Website Fingerprinting attacks are a\n      serious problem that affect all Internet users, and we pose open\n      problems and directions for future research in this area.\n\n  "Modifying RFC5549 VPNv4 over IPv6 next hop handling procedures", Stephane\n  Litkowski, Swadesh Agrawal, Keyur Patel, Shunwan Zhuang, 2019-11-04,\n  <draft-litkowski-bess-vpnv4-ipv6-nh-handling-00.txt>\n\n      RFC4364 and RFC4659 define respectively BGP extensions to provide\n      VPN-IPv4 and VPN-IPv6 services.  When defined RFC5549 has brought up\n      an inconsistency in how the next hop is encoded when a VPN-IPv4 NLRI\n      carries an IPv6 next hop compared to RFC4364 and RFC4659.  For some\n      reasons, existing and deployed implementations of RFC5549 haven\'t\n      followed the specification and are using an VPN-IPv6 next hop as in\n      RFC4364 and RFC4659.  Moving these implementations to be compliant\n      with RFC5549 may break existing network deployments.  This document\n      proposes a modification of RFC5549 to enable compliancy of these\n      implementations.  These document also proposes additional\n      modifications of RFC5549 to address missing points.\n\n  "Service Assurance for Intent-based Networking Architecture", Benoit\n  Claise, Jean Quilbeuf, 2019-11-16,\n  <draft-claise-opsawg-service-assurance-architecture-01.txt>\n\n      This document describes the architecture for Service Assurance for\n      Intent-based Networking (SAIN).  This architecture aims at assuring\n      that service instances are correctly running.  As services rely on\n      multiple sub-services by the underlying network devices, getting the\n      assurance of a healthy service is only possible with a holistic view\n      of network devices.  This architecture not only helps to correlate\n      the service degradation with the network root cause but also the\n      impacted services when a network component fails or degrades.\n\n  "IETF Stream Documents Require IETF Rough Consensus", Joel Halpern, Eric\n  Rescorla, 2020-01-21,\n  <draft-halpern-gendispatch-consensusinformational-02.txt>\n\n      This document proposes that the IETF never publish any IETF stream\n      RFCs without IETF rough consensus.  This updates RFC 2026.\n\n  "Compute First Networking (CFN) Scenarios and Requirements", Liang Geng,\n  Peter Willis, 2019-11-04, <draft-geng-rtgwg-cfn-req-00.txt>\n\n      Service providers are exploring the edge computing to achieve better\n      response times and transfer rate by moving the computing towards the\n      edge of the network in scenarios like 5G MEC, virtualized central\n      office, etc. Providing services by sharing computing resources from\n      multiple edges is emerging. The service nodes from multiple edges\n      normally have two key features, service equivalency and service\n      dynamics. When the computing resources attached to a single edge site\n      is overloaded, static service dispatch can possibly keep allocating\n      the service request to it and cause inefficient utilization. The\n      service request to edge computing needs to be dispatched to and\n      served by the most suitable edge to improve user experience and\n      system utilization by taking both the available computing resources\n      and network conditions into account.\n      \n      This draft describes scenarios and requirements of Compute First\n      Networking (CFN) to make the computing and network resource to be\n      considered in a collaborative way to achieve a more balanced network-\n      based distributed service dispatching.\n\n  "A privacy analysis on DoH deployment", Daniel Migault, 2019-11-04,\n  <draft-mglt-abcd-doh-privacy-analysis-00.txt>\n\n      This document provides an analysis on DoH impact on privacy\n\n  "Communicating Warning Information in HTTP APIs", Andre Cedik, Erik Wilde,\n  2019-11-04, <draft-cedik-http-warning-00.txt>\n\n      This document defines a warning code and a standard response format\n      for warning information in HTTP APIs.\n      \n      Note to Readers\n      \n      This draft should be discussed on the rfc-interest mailing list\n      (<https://www.rfc-editor.org/mailman/listinfo/rfc-interest>).\n      \n      Online access to all versions and files is available on GitHub\n      (<https://github.com/dret/I-D/tree/master/http-warning>).\n\n  "Selecting Resolvers from a Set of Distributed DNS Resolvers", Jari Arkko,\n  Martin Thomson, Ted Hardie, 2019-11-04,\n  <draft-arkko-abcd-distributed-resolver-selection-00.txt>\n\n      This memo discusses the use of a set of different DNS resolvers to\n      reduce privacy problems related to resolvers learning the Internet\n      usage patterns of their clients.\n\n  "Discovery Mechanism for QUIC-based, Non-transparent Proxy Services", Mirja\n  Kuehlewind, Zaheduzzaman Sarker, 2020-01-27,\n  <draft-kuehlewind-quic-proxy-discovery-01.txt>\n\n      Often an intermediate instance (such as a proxy server) is used to\n      connect to a web server or a communicating peer if a direct end-to-\n      end IP connectivity is not possible or the proxy can provide a\n      support service like, e.g., address anonymisation.  To use a non-\n      transparent proxy a client explicitly connects to it and requests\n      forwarding to the final target server.  The client either knows the\n      proxy address as preconfigured in the application or can dynamically\n      learn about available proxy services.  This document describes\n      different discovery mechanisms for non-transparent proxies that are\n      either located in the local network, e.g. home or enterprise network,\n      in the access network, or somewhere else on the Internet usually\n      close to the target server or even in the same network as the target\n      server.\n      \n      This document assumes that the non-transparent proxy server is\n      connected via QUIC and discusses potential discovery mechanisms for\n      such a QUIC-based, non-transparent proxy.\n\n  "Resource Transfer in the Resource Public Key Infrastructure", Rob Austein,\n  Randy Bush, Geoff Huston, George Michaelson, 2019-11-04,\n  <draft-ymbk-sidrops-transfer-00.txt>\n\n      Transfer within the RPKI of actual address space and/or autonomous\n      system number resources between two Internet registries (ISPs, RIRs,\n      NIRs, etc.) is reasonably achievable for most useful operational\n      needs.  In this paper, we describe, at a high level, how this may be\n      accomplished.\n\n  "pretty Easy privacy (pEp): Key Synchronization Protocol (KeySync)", Volker\n  Birk, Bernie Hoeneisen, Kelly Bristol, 2019-11-04,\n  <draft-pep-keysync-00.txt>\n\n      This document describes the pEp KeySync protocol, which is designed\n      to perform secure peer-to-peer synchronization of private keys across\n      devices belonging to the same user.\n      \n      Modern users of messaging systems typically have multiple devices for\n      communicating, and attempting to use encryption on all of these\n      devices often leads to situations where messages cannot be decrypted\n      on a given device due to missing private key data.  Current\n      approaches to resolve key synchronicity issues are cumbersome and\n      potentially unsecure.  The pEp KeySync protocol is designed to\n      facilitate this personal key synchronization in a user-friendly\n      manner.\n\n  "OSPFv3 CodePoint for MPLS LSP Ping", Nagendra Kumar, Carlos Pignataro,\n  Mustapha Aissaoui, 2019-11-04,\n  <draft-nainar-mpls-lsp-ping-ospfv3-codepoint-00.txt>\n\n      IANA has created "Protocol in the Segment IS Sub-TLV" registry and\n      "Protocol in the Label Stack Sub-TLV of the Downstream Detailed\n      Mapping TLV" under the "Multi-Protocol Label Switching (MPLS) Label\n      Switched Paths (LSPs) Ping Parameters" registry.  RFC8287 defines the\n      code point for different Interior Gateway Protocol (IGP).\n      \n      This document proposes the code point to be used in the Segment ID\n      Sub-TLV and Downstream Detailed Mapping TLV when the IGP protocol is\n      OSPFv3.\n\n  "Challenges and Changes in the Internet Threat Model", Jari Arkko, Stephen\n  Farrell, 2019-12-15, <draft-arkko-farrell-arch-model-t-01.txt>\n\n      Communications security has been at the center of many security\n      improvements in the Internet.  The goal has been to ensure that\n      communications are protected against outside observers and attackers.\n      \n      This memo suggests that the existing threat model, while important\n      and still valid, is no longer alone sufficient to cater for the\n      pressing security issues in the Internet.  For instance, it is also\n      necessary to protect systems against endpoints that are compromised,\n      malicious, or whose interests simply do not align with the interests\n      of the users.  While such protection is difficult, there are some\n      measures that can be taken.\n      \n      It is particularly important to ensure that as we continue to develop\n      Internet technology, non-communications security related threats, and\n      privacy issues, are properly understood.\n\n  "Transport Protocol Issues of In-Network Computing Systems", Ike Kunze,\n  Klaus Wehrle, 2019-11-04, <draft-kunze-coinrg-transport-issues-00.txt>\n\n      Today\'s transport protocols offer a variety of functionality based on\n      the notion that the network is to be treated as an unreliable\n      communication medium.  Some, like TCP, establish a reliable\n      connection on top of the unreliable network while others, like UDP,\n      simply transmit datagrams without a connection and without guarantees\n      into the network.  These fundamental differences in functionality\n      have a significant impact on how COIN approaches can be designed and\n      implemented.  Furthermore, traditional transport protocols are not\n      designed for the multi-party communication principles that underlie\n      many COIN approaches.  This document discusses selected\n      characteristics of transport protocols which have to be adapted to\n      support COIN functionality.\n\n  "Considerations for defining a Transport Slice NBI", Luis Contreras,\n  Shunsuke Homma, Jose Ordonez-Lucena, 2019-11-04,\n  <draft-contreras-teas-slice-nbi-00.txt>\n\n      The transport network is an essential component in the end-to-end\n      delivery of services and, consequently, with the advent of network\n      slicing it is necessary to understand what could be the way in which\n      the transport network is consumed as a slice.  This document analyses\n      the needs of potential transport slice consumers in order to identify\n      the functionality required on the North Bound Interface (NBI) of a\n      transport slice producer for satisfying such transport slcie\n      requests.\n\n  "IS-IS Flooding Scale Considerations", Les Ginsberg, Peter Psenak, Acee\n  Lindem, 2019-11-21, <draft-ginsberg-lsr-isis-flooding-scale-01.txt>\n\n      Link State PDU flooding rates in use are much slower than what modern\n      networks can support.  The use of IS-IS at larger scale requires\n      faster flooding rates to achieve desired convergence goals.  This\n      document discusses issues associated with increasing flooding rates\n      and some recommended practices which allow faster flooding rates to\n      be used safely.\n\n  "Protected Headers for Cryptographic E-mail", Bjarni Einarsson, juga,\n  Daniel Gillmor, 2019-12-20,\n  <draft-autocrypt-lamps-protected-headers-02.txt,.pdf>\n\n      This document describes a common strategy to extend the end-to-end\n      cryptographic protections provided by PGP/MIME, etc. to protect\n      message headers in addition to message bodies.  In addition to\n      protecting the authenticity and integrity of headers via signatures,\n      it also describes how to preserve the confidentiality of the Subject\n      header.\n\n  "IANA Registration of Content-Type Header Field Parameter \'forwarded\'",\n  Alexey Melnikov, Bernie Hoeneisen, 2019-11-04,\n  <draft-melnikov-iana-reg-forwarded-00.txt>\n\n      This document defines a new Content-Type header field parameter named\n      "forwarded" for "message/rfc822" and "message/global" media types,\n      and its registration with IANA.\n\n  "IGMPv3/MLDv2 Message Extension", Mahesh Sivakumar, Stig Venaas, Zheng\n  Zhang, 2019-11-04, <draft-venaas-pim-igmp-mld-extension-00.txt>\n\n      IGMP and MLD protocols are extensible, but no extensions have been\n      defined so far.  This document provides a well-defined way of\n      extending IGMP and MLD, including a new extension type to distinguish\n      between different extensions.  This document also defines an\n      extension for use with IGMP and MLD over BIER, that allows for\n      identifying the sender.  This will in turn enable MLD (resp.  IGMP)\n      to be used in the BIER multicast flow overlay.\n\n  "Admin Interface for the OSCORE Group Manager", Marco Tiloca, Rikard\n  Hoeglund, Peter van der Stok, Francesca Palombini, 2019-11-04,\n  <draft-tiloca-ace-oscore-gm-admin-00.txt>\n\n      Group communication for CoAP can be secured using Group Object\n      Security for Constrained RESTful Environments (Group OSCORE).  A\n      Group Manager is responsible to handle the joining of new group\n      members, as well as to manage and distribute the group key material.\n      This document defines a RESTful admin interface at the Group Manager,\n      that allows an Administrator entity to create and delete OSCORE\n      groups, as well as to retrieve and update their configuration.  The\n      ACE framework for Authentication and Authorization is used to enforce\n      authentication and authorization of the Administrator at the Group\n      Manager.  Protocol-specific transport profiles of ACE are used to\n      achieve communication security, proof-of-possession and server\n      authentication.\n\n  "Notification of Revoked Access Tokens in the Authentication and\n  Authorization for Constrained Environments (ACE) Framework", Marco Tiloca,\n  Ludwig Seitz, Francesca Palombini, Sebastian Echeverria, Grace Lewis,\n  2019-11-04, <draft-tiloca-ace-revoked-token-notification-00.txt>\n\n      This document specifies a method of the Authentication and\n      Authorization for Constrained Environments (ACE) framework, which\n      allows an Authorization Server to notify Clients and Resource Servers\n      (i.e., registered devices) about revoked Access Tokens.  The method\n      relies on resource observation for the Constrained Application\n      Protocol (CoAP), with Clients and Resource Servers observing a\n      dedicated, device-specific Token Revocation List on the Authorization\n      Server.  Resulting unsolicited notifications of revoked Access Tokens\n      complement alternative approaches such as token introspection, while\n      not requiring additional endpoints on Clients and Resource Servers.\n\n  "Flex Algorithm for BIER", Nagendra Kumar, IJsbrand Wijnands, mankamana\n  mishra, 2019-11-04, <draft-nainar-bier-flex-algo-00.txt>\n\n      Bit Index Explicit Replication (BIER) is an architecture that\n      provides optimal multicast forwarding through a "BIER domain" without\n      requiring intermediate routers to run explicit tree-building protocol\n      or to maintain multicast-related, per-flow state.  IGP protocols are\n      extended to carry BFR-Id and other encapsulation informations that\n      are used by traditional path computing algorithm using link metric\n      for a loop-free best path selection.\n      \n      This document defines a constrained based path selection using IGP\n      flexible Algorithm for BIER.\n\n  "Enhanced DiffServ by In-band Signaling", Lin Han, Yingzhen Qu, Renwei Li,\n  2019-11-04, <draft-han-tsvwg-enhanced-diffserv-00.txt>\n\n      There are real-time applications requiring deterministic services in\n      terms of bandwidth and latency in various industries, such as network\n      based AR/VR (Augmented Reality and Virtual Reality), industrial\n      internet.  This document proposes a solution which enhances DiffServ\n      in IPv6 to provide end to end bandwidth guaranteed service and\n      latency guaranteed service.\n\n  "Tunneling Internet protocols inside QUIC", Maxime Piraux, Olivier\n  Bonaventure, 2019-11-04, <draft-piraux-quic-tunnel-00.txt>\n\n      This document specifies methods for tunneling Internet protocols such\n      as TCP, UDP, IP and QUIC inside a QUIC connection.\n\n  "Use of ALTO for Determining Service Edge", Luis Contreras, Danny Perez,\n  Christian Rothenberg, 2019-11-04, <draft-contreras-alto-service-edge-00.txt>\n\n      Service providers are starting to deploy and interconnect computing\n      capabilities across the network for hosting network functions and\n      applications.  In distributed computing environments, both computing\n      and topological information are necessary in order to determine the\n      more convenient infrastructure where to deploy such a service or\n      application.  This document raises an initial approach towards the\n      use of ALTO to provide such information and assist in the selection\n      of proper execution environments.\n\n  "Ephemeral Diffie-Hellman Over COSE (EDHOC)", Goeran Selander, John\n  Mattsson, Francesca Palombini, 2019-11-04,\n  <draft-selander-lake-edhoc-00.txt>\n\n      This document specifies Ephemeral Diffie-Hellman Over COSE (EDHOC), a\n      very compact, and lightweight authenticated Diffie-Hellman key\n      exchange with ephemeral keys.  EDHOC provides mutual authentication,\n      perfect forward secrecy, and identity protection.  EDHOC is intended\n      for usage in constrained scenarios and a main use case is to\n      establish an OSCORE security context.  By reusing COSE for\n      cryptography, CBOR for encoding, and CoAP for transport, the\n      additional code footprint can be kept very low.\n\n  "The OAuth 2.0 Authorization Framework: Claims", Travis Spencer,\n  2019-11-23, <draft-spencer-oauth-claims-01.txt>\n\n      This document extends the OAuth 2.0 framework to include a simple\n      query language that can be used by clients to request certain claims\n      from an authorization server.  This mechanism can be used during the\n      authorization request and refresh request.  It also defines a\n      response parameter of the token and introspection endpoints that\n      indicates to the caller which claims were authorized by the resource\n      owner.  Lastly, it stipulates how this request parameter can be used\n      during token exchange, and how clients may request that certain\n      claims be placed in an access token intended for a particular\n      resource server.\n\n  "Impact of TLS 1.3 to Operational Network Security Practices", Nancy\n  Cam-Winget, Eric Wang, Roman Danyliw, Roelof DuToit, 2019-11-04,\n  <draft-camwinget-tls-proxy-impact-00.txt>\n\n      Network-based security solutions are used by enterprises, the public\n      sector, internet-service providers, and cloud-service providers to\n      both complement and enhance host-based security solutions.  As the\n      most widely deployed protocol to secure communication, these network-\n      based security solutions must necessarily interact with TLS.  This\n      document describes this interaction for current operational security\n      practices and notes the impact of TLS 1.3 on them.\n\n  "Report from the IAB workshop on Design Expectations vs. Deployment Reality\n  in Protocol Development", Jari Arkko, Ted Hardie, 2019-11-04,\n  <draft-arkko-arch-dedr-report-00.txt>\n\n      The Design Expectations vs. Deployment Reality in Protocol\n      Development Workshop was convened by the Internet Architecture Board\n      (IAB) in June 2019.  This report summarizes its significant points of\n      discussion and identifies topics that may warrant further\n      consideration.\n\n  "YANG Modules for Service Assurance", Benoit Claise, Jean Quilbeuf, Paolo\n  Lucente, Paolo Fasano, 2020-01-13,\n  <draft-claise-opsawg-service-assurance-yang-03.txt>\n\n      This document proposes YANG modules for the Service Assurance for\n      Intent-based Networking Architecture.\n\n  "Communication Network Perspective on Malware Lifecycle", Joachim Fabini,\n  2019-11-04, <draft-fabini-smart-malware-lifecycle-00.txt>\n\n      Today\'s systems, networks, and protocols are complex and include\n      unknown vulnerabilities that adversaries can exploit.  The large-\n      scale deployment of network security protocols establishes an\n      additional threat by implementing a substrate for hidden\n      communications like covert or subliminal channels.  The resulting\n      ecosystem builds a convenient platform for malicious, automated\n      software (malware) to infiltrate critical infrastructures, to\n      gradually infect large parts of the system and to coordinate\n      distributed malware operation.\n      \n      Based on the observation that malware depends on network\n      communications to discover, propagate, coordinate, and unleash its\n      functionality, this memo recommends methods to identify potential\n      interfaces and interactions between malware and protocols.  It\n      proposes a generic malware lifecycle model that defines a set of\n      generic malware states and possible transitions between these states.\n      Coordinated activities of distributed malware can be mapped to state\n      transitions in malware instances, supporting the identification of\n      (potentially hidden) network communication as a trigger for actions\n      and hints on protocols that enabled the communication.  Eventually,\n      the proposed model aims at supporting the identification of\n      architectures, protocols, interfaces, and points in time that a)\n      either inhibit hidden malware communication or b) allow for optimized\n      detection of anomalies as main prerequisite for timely\n      countermeasures.\n      \n      While earlier work focused on protecting single hosts from\n      compromise, this memo adopts a holistic view and considers the health\n      of the overall networked system to be of highest priority.  Presuming\n      vulnerable systems, we stress that components or subsystems must be\n      disconnected on suspected infection in an attempt to continue (even\n      partial) operation of the overall (non-infected) system after the\n      disconnect.  Containment - the isolation of an infected subsystem -\n      becomes an essential security feature in the context of critical\n      infrastructures that influences on deployed protocols, interfaces and\n      architectures.\n\n  "TLS 1.3 Extended Key Schedule", Jonathan Hoyland, Christopher Wood,\n  2019-11-04, <draft-jhoyla-tls-extended-key-schedule-00.txt>\n\n      TLS 1.3 is sometimes used in situations where it is necessary to\n      inject extra key material into the handshake.  This draft aims to\n      describe methods for doing so securely.  This key material must be\n      injected in such a way that both parties agree on what is being\n      injected and why, and further, in what order.\n\n  "User Assigned ISO 3166-1 Alpha-2 Codes and the DNS Root Zone", Edward\n  Lewis, Roy Arends, 2019-11-04, <draft-arends-private-use-tld-00.txt>\n\n      The ISO 3166 standard is used for the definition of eligible\n      designations\n      for country code Top Level Domains. This standard is\n      maintained by the ISO 3166\n      Maintenance Agency. The ISO 3166 standard\n      contains a set of User-Assigned\n      code elements. This document describes\n      that these values can be used as top\n      level domains for private DNS\n      resolution.\n\n  "Publish/Subscribe over the Constrained Application Protocol (CoAP) using\n  the Constrained RESTful Application Language (CoRAL)", Klaus Hartke,\n  2019-11-04, <draft-hartke-t2trg-coral-pubsub-00.txt>\n\n      This document explores how the Constrained RESTful Application\n      Language (CoRAL) might be used for enabling publish/subscribe-style\n      communication over the Constrained Application Protocol (CoAP), which\n      allows CoAP nodes with long breaks in connectivity and/or up-time to\n      exchange data via a publish/subscribe broker.\n\n  "ForCES-based BNG", Evangelos Haleplidis, Jamal Hadi Salim, Jae Chung,\n  2019-11-04, <draft-haleplidis-forces-bng-00.txt>\n\n      This document provides an approach for the separation of the\n      forwarding and control plane for the Broadband Network Gateway (BNG)\n      using IETF\'s ForCES architecture.  The document provides an initial\n      primer on ForCES as well as an initial ForCES XML model that\n      describes some basic functions of the BNG.\n\n  "MVPN and EVPN BUM Signaling with Controllers", Zheng Zhang, Zhaohui Zhang,\n  Rishabh Parekh, Hooman Bidgoli, 2019-11-04,\n  <draft-zzhang-mvpn-evpn-controller-00.txt>\n\n      This document specifies optional procedures for BGP-MVPN and EVPN BUM\n      signaling with controllers.  When P2MP tunnels used for BGP-MVPN and\n      EVPN BUM are to be signaled from controllers, the controllers can\n      learn tunnel information (identifier, root, leaf) by participating\n      BGP-MVPN and EVPN BUM signaling, instead of relying on ingress PEs to\n      collect the information and then pass to the controllers.\n      Additionally, Inclusive/Selective PMSI Auto Discovery Routes can be\n      originated from controllers based on central provisioning, instead of\n      from PEs based on local provisioning.\n\n  "MVPN and EVPN BUM Signaling with Controllers", Zheng Zhang, Zhaohui Zhang,\n  Rishabh Parekh, Hooman Bidgoli, 2019-11-04,\n  <draft-zzhang-bess-mvpn-evpn-controller-00.txt>\n\n      This document specifies optional procedures for BGP-MVPN and EVPN BUM\n      signaling with controllers.  When P2MP tunnels used for BGP-MVPN and\n      EVPN BUM are to be signaled from controllers, the controllers can\n      learn tunnel information (identifier, root, leaf) by participating\n      BGP-MVPN and EVPN BUM signaling, instead of relying on ingress PEs to\n      collect the information and then pass to the controllers.\n      Additionally, Inclusive/Selective PMSI Auto Discovery Routes can be\n      originated from controllers based on central provisioning, instead of\n      from PEs based on local provisioning.\n\n  "TLS Proxy Best Practice", Eric Wang, Andrew Ossipov, Roelof DuToit,\n  2019-11-04, <draft-wang-tls-proxy-best-practice-00.txt>\n\n      TLS proxies are widely deployed by organizations to enable security\n      features and apply enterprise policies.  This document defines a TLS\n      proxy and discusses a wide range of security requirements to guide\n      TLS proxy implementations.\n\n  "Bijective MAC for Constraint Nodes", Pascal Urien, 2019-12-12,\n  <draft-urien-core-bmac-05.txt>\n\n      In this draft context, things are powered by micro controllers units\n      (MCU) comprising a set of memories such as static RAM (SRAM), FLASH\n      and EEPROM. The total memory size, ranges from 10KB to a few\n      megabytes. In this context code and data integrity are major\n      security issues, for the deployment of Internet of Things\n      infrastructure. The goal of the bijective MAC (bMAC) is to compute\n      an integrity value, which cannot be guessed by malicious software.\n      In classical keyed MACs, MAC is computing according to a fixed\n      order.\n      In the bijective MAC, the content of N addresses is hashed according\n      to a permutation P (i.e. bijective application).\n      The bijective MAC key is the permutation P.\n      The number of permutations for N addresses is N!. So the computation\n      of the bMAC requires the knowledge of the whole space memory; this\n      is trivial for genuine software, but could very difficult for\n      corrupted software, especially for time stamped bMAC.\n\n  "Internet-Drafts Don\'t Expire", Martin Thomson, 2019-11-04,\n  <draft-thomson-gendispatch-no-expiry-00.txt>\n\n      The long-standing insistence that Internet-Drafts carry expiration\n      dates is a concept that is no longer necessary.  This document\n      removes requirements for expiration for Internet-Drafts from RFC\n      2418/BCP 25.\n      \n      Note to Readers\n      \n      Discussion of this document takes place on the GENDISPATCH Working\n      Group mailing list (gendispatch@ietf.org), which is archived at\n      https://mailarchive.ietf.org/arch/browse/gendispatch/ [1].\n      \n      Source for this draft and an issue tracker can be found at\n      https://github.com/martinthomson/no-expiry [2].\n\n  "Personal Information Tagging for Logs (PITFoL)", Sandeep Rao, Shivan\n  Sahib, Ryan Guest, 2019-11-04, <draft-rao-pitfol-00.txt>\n\n      Software applications typically generate a large amount of log data\n      in the course of their operation in order to help with monitoring,\n      troubleshooting, etc.  However, like all data generated and operated\n      upon by software systems, logs can contain information sensitive to\n      users.  Personal data identification and anonymization in logs is\n      thus crucial to ensure that no personal data is being inadvertently\n      logged and retained which would make the logging application run\n      afoul of laws around storing private information.  This document\n      focuses on exploring mechanisms to specify personal or sensitive data\n      in logs, to enable any server collecting, processing or analyzing\n      logs to identify personal data and thereafter, potentially enforce\n      any redaction.\n\n  "SIP Call-Info Parameters for Rich Call Data", Chris Wendt, Jon Peterson,\n  2019-11-04, <draft-wendt-sipcore-callinfo-rcd-00.txt>\n\n      This document describes a SIP Call-Info parameter defined to include\n      rich data associated with the identity of the calling party that can\n      be rendered to called party for providing more useful information\n      about the caller or the specific reason for the call.  This includes\n      extended comprehensive information about the caller such as what a\n      jCard object can represent for describing the calling party.  The\n      element defined for this purpose is intended to be extensible to\n      accommodate related information about calls that helps people decide\n      whether to pick up the phone and additionally with the use of jCard\n      be compatible with the STIR/PASSporT Rich Call Data framework.\n\n  "UAS Remote ID", Stuart Card, Adam Wiethuechter, Robert Moskowitz,\n  2019-11-04, <draft-card-tmrid-uas-00.txt>\n\n      This document is an Applicability Statement for various IETF\n      Technical Specifications, including the Host Identity Protocol\n      (HIPv2) and the Domain Name System (DNS), complementing emerging\n      external standards for Unmanned Aircraft System (UAS) remote\n      identification (RID).  The objectives are: to facilitate use of\n      existing Internet services to support UAS RID and to enable enhanced\n      RID related services; and to enable verification that UAS RID\n      information is trustworthy (to some extent, even in the absence of\n      Internet connectivity at the receiving node).\n\n  "The DANE Authentication Chain Extension for TLS", Viktor Dukhovni, Shumon\n  Huque, Willem Toorop, Paul Wouters, Melinda Shore, 2019-12-17,\n  <draft-dukhovni-tls-dnssec-chain-01.txt>\n\n      This draft describes a new TLS extension for in-band transport of the\n      complete set of DNSSEC validated records needed to perform DANE\n      authentication of a TLS server without the need to perform separate\n      out-of-band DNS lookups.  When the requisite DNS records do not\n      exist, the extension conveys a validated denial of existence proof.\n\n  "Delegation Revalidation by DNS Resolvers", Shumon Huque, Paul Vixie,\n  2019-11-04, <draft-huque-dnsop-ns-revalidation-00.txt>\n\n      This document recommends improved DNS [RFC1034] [RFC1035] resolver\n      behavior with respect to the processing of Name Server (NS) resource\n      record sets (RRset) during iterative resolution.  When following a\n      referral response from an authoritative server to a child zone, DNS\n      resolvers should explicitly query the authoritative NS RRset at the\n      apex of the child zone and cache this in preference to the NS RRset\n      on the parent side of the zone cut.  Resolvers should also\n      periodically revalidate the child delegation by re-quering the parent\n      zone at the expiration of the TTL of the parent side NS RRset.\n\n  "Homomorphic Multiplication for X25519 and X448", Richard Barnes, Joel\n  Alwen, Sandro Corretti, 2019-11-04, <draft-barnes-cfrg-mult-for-7748-00.txt>\n\n      In some contexts it is useful for holders of the private and public\n      parts of an elliptic curve key pair to be able to independently apply\n      an updates to those values, such that the resulting updated public\n      key corresponds to the updated private key.  Such updates are\n      straightforward for older elliptic curves, but for X25519 and X448,\n      the "clamping" prescribed for scalars requires some additional\n      processing.  This document defines a multiplication procedure that\n      can be used to update X25519 and X448 key pairs.  This algorithm can\n      fail to produce a result, but only with negligible probability.\n      Failures can be detected by the holder of the private key.\n\n  "Centralised Architectures in Internet Infrastructure", Jari Arkko,\n  2019-11-04, <draft-arkko-arch-infrastructure-centralisation-00.txt>\n\n      Centralised deployment models for Internet services and Internet\n      business consolidation are well-known Internet trends, at least when\n      it comes to popular and user-visible service.  This memo discusses\n      the impacts of similar trends within the Internet infrastructure, on\n      functions such as DNS resolution.\n\n  "User Plane Message Encoding", Tetsuya Murakami, Satoru Matsushima, Kentaro\n  Ebisawa, Pablo Camarillo, Ravi Shekhar, 2019-11-04,\n  <draft-murakami-dmm-user-plane-message-encoding-00.txt,.ps,.pdf>\n\n      This document defines the encoding of User Plane messages into\n      Segment Routing Header (SRH).  The SRH carries the User Plane\n      messages over SRv6 Network.\n\n  "Requirement for the transparency of RPKI", Yaping Liu, Shuo Zhang,\n  Qingyuan Li, Sufang, 2019-11-05, <draft-qingyuan-transparencyrpki-00.txt>\n\n      This document provides the transparency requirement of a Certificate\n      Authority (CA) or Repository resource management agency in Resource\n      Public Key Infrastructure (RPKI), which references multiple content  in\n      some RFCs related to RPKI. It is easier for implementers to be   aware\n      of these requirements\n\n  "L-band Digital Aeronautical Communications System (LDACS)", Nils Maeurer,\n  Thomas Graeupl, Corinna Schmitt, 2019-11-05,\n  <draft-maeurer-raw-ldacs-00.txt>\n\n      This document provides an overview of the architecture of the L-band\n      Digital Aeronautical Communications System (LDACS), which provides a\n      secure, scalable and spectrum efficient terrestrial data link for\n      civil aviation.  LDACS is a scheduled, reliable multi-application\n      cellular broadband system with support for IPv6.\n\n  "Deadline-aware Transport Protocol", Yong Cui, Zhiwen Liu, Hang Shi, Jie\n  Zhang, Kai Zheng, Wei Wang, 2020-01-20, <draft-shi-quic-dtp-01.txt>\n\n      This document defines Deadline-aware Transport Protocol (DTP) to\n      provide block-based deliver-before-deadline transmission.  The\n      intention of this memo is to describe a mechanism to fulfill\n      unreliable transmission based on QUIC as well as how to enhance\n      timeliness of data delivery.\n\n  "YANG Schema Comparison", Robert Wilton, 2019-11-16,\n  <draft-verdt-netmod-yang-schema-comparison-00.txt>\n\n      This document specifies an algorithm for comparing two revisions of a\n      YANG schema to determine the scope of changes, and a list of changes,\n      between the revisions.  The output of the algorithm can be used to\n      help select an appropriate revision-label or YANG semantic version\n      number for a new revision.  This document defines a YANG extension\n      that provides YANG annotations to help the tool accurately determine\n      the scope of changes between two revisions.\n\n  "Negotiation of multiple Child Security Association with the Internet Key\n  Exchange Protocol Version 2 (IKEv2)", Daniel Migault, Steffen Klassert,\n  2019-11-17, <draft-mglt-ipsecme-multiple-child-sa-00.txt>\n\n      IPsec packet processing with one Security Association (SA) per core\n      is more efficient than having a SA shared by the multiple cores.\n      \n      This document optimizes the negotiation of multiple unidirectional\n      SAs in order to minimize the impact SAs being shared by multiple\n      cores.\n\n  "SR-MPLS Data Plane with IPv6 Control Plane", Clarence Filsfils, Francois\n  Clad, Ketan Talaulikar, 2019-11-17,\n  <draft-filsfils-spring-sr-mpls-ipv6-control-plane-00.txt>\n\n      This document reminds the existence of the "Segment Routing (SR) MPLS\n      data-plane with IPv6 control-plane" solution that is mature from a\n      standardization, productization and commercial deployment viewpoint.\n\n  "Simple Datagram Usability and Connectivity Kata", Lucas Pardue,\n  2019-11-17, <draft-pardue-quic-siduck-00.txt>\n\n      This document describes a simple application protocol for testing\n      implementations of the QUIC DATAGRAM frame.  SiDUCK (Simple Datagram\n      Usability and Connectivity Kata) defines a new ALPN ID, "siduck-00",\n      along with a basic offer and acknowledgement interaction using\n      datagram payload data.\n\n  "BGP Extensions for IPv6 Compressed Routing Header (CRH)", Andrew Alston,\n  Daniam Henriques, Ron Bonica, 2019-11-17,\n  <draft-alston-idr-crh-bgp-signalling-00.txt>\n\n      This document describes a new BGP extension for signalling the\n      mapping between Segment Identifiers (SID\'s), as used by a SRm6\n      Compressed Routing Header (CRH) and the IPv6 Addresses they\n      represent.  The extension defines both a new optional BGP attribute\n      to signal the Maximum SID Value (MSV) and a new Sub-Address Family\n      (SAFI) of the IPv6 Address family.\n\n  "CBOR Object Signing and Encryption (COSE): Additional Algorithms", Jim\n  Schaad, 2019-11-17, <draft-schaad-cose-more-algs-00.txt>\n\n      The CBOR Object Signing and Encryption (COSE) syntax\n      [I-D.ietf-cose-rfc8152bis-struct] allows for adding additional\n      algorithms to the registries.  This document adds one additional key\n      wrap algorithm to the registry using the AES Wrap with Padding\n      Algorithm [RFC5649].\n\n  "National Identifier Top-level Node Interface Protocol", Yuying Chen,\n  Jiagui Xie, Zhiping Li, Hongyan Liu, 2019-11-17,\n  <draft-chen-top-level-interface-protocol-00.txt>\n\n      This document describes an Extensible Provisioning Protocol (EPP)\n      for the provisioning and management of enterprises and identifiers\n      between the server which is called Business Management System(BMS)\n      and is entitled to manage the identifier top-level node and the\n      client which is also referred to as Second Node Management System\n      (SNMS).Specified in XML, the mapping defines EPP command syntax and\n      semantics as applied to enterprise and identifier management.\n\n  "The Transport-Info Response Header", Piers O\'Hanlon, James Gruessing,\n  2019-11-17, <draft-ohanlon-transport-info-header-00.txt>\n\n      The Transport-Info header provides a mechanism to inform a client of\n      the last-mile server\'s view of the network transport related\n      information such as current delivery rate and round-trip time.  This\n      information has a wide range of uses such as client monitoring and\n      diagnostics, or allowing a client to adapt to current network\n      conditions.\n      \n      Note to Readers\n      \n      _RFC Editor: please remove this section before publication_\n      \n      Source code and issues for this draft can be found at\n      https://github.com/bbc/draft-ohanlon-transport-info-header [1].\n\n  "Registration Policy for TCP Header Flags", Mirja Kuehlewind, 2019-11-17,\n  <draft-kuehlewind-tcpm-flags-registry-00.txt>\n\n      RFC2780 specifies the registration policy for reserved TCP header\n      flags as Standards Action.  RFC3168 created an IANA registry for\n      these header flags and registered bit 8 (CWR) and 9 (ECE).  This\n      draft changes the registration policy of the registration to IETF\n      Review as usually new TCP mechanisms that could use the remaining\n      reserved flags will be first specified as experimental.  Not noting\n      any of those experiments in the registry would undermine the purpose\n      of having a registry.  However, care must be taken, as only a few\n      reserved flags are left and if a new (experimental) mechanism sees\n      deployment in the Internet, the flag cannot be unassigned anymore or\n      used for something else.\n\n  "Range Patch", Mitar Milutinovic, Michael Toomim, Bryn Bellomy, 2019-11-18,\n  <draft-toomim-httpbis-range-patch-00.txt>\n\n      A uniform approach for expressing changes to state over HTTP.\n\n  "Provide for method to know accepted and rejected NLRI.", Jared Mauch,\n  2019-11-18, <draft-mauch-bgp-accepted-00.txt>\n\n      This document defines a method to receive accepted and rejected NLRI\n      over a BGP peering session.\n\n  "Braid-HTTP: Synchronization for HTTP", Michael Toomim, Greg Little, Rafie\n  Walker, Bryn Bellomy, 2019-11-18, <draft-toomim-httpbis-braid-http-01.txt>\n\n      Braid is a set of extensions that generalize HTTP from a state\n      transfer protocol into a state synchronization protocol.\n      \n      Braid adds to HTTP:\n\n  "S/MIME Example Keys and Certificates", Daniel Gillmor, 2019-12-24,\n  <draft-dkg-lamps-samples-02.txt,.pdf>\n\n      The S/MIME development community benefits from sharing samples of\n      signed or encrypted data.  This document facilitates such\n      collaboration by defining a small set of X.509v3 certificates and\n      keys for use when generating such samples.\n\n  "A YANG Model for User-Network Interface (UNI) Topologies", Oscar de Dios,\n  Samier Barguil, Qin WU, Mohamed Boucadair, 2019-11-18,\n  <draft-ogondio-opsawg-uni-topology-00.txt>\n\n      This document defines a YANG data model for representing an abstract\n      view of the Service Provider network topology containing the points\n      from which its services can be attached (e.g., basic connectivity,\n      VPN, SDWAN).  The data model augments ietf-network model by adding\n      the concept of service-attachment-points.The service-attachment-\n      points are an abstraction of the points to which network services\n      (such as L3 VPNs or L2 VPNs) can be attached.\n\n  "Using One-Arm BFD in Cloud Network", Ruixue Wang, Weiqiang Cheng, Yanhua\n  Zhao, Liu Aihua, 2019-11-18, <draft-wang-bfd-one-arm-use-case-00.txt>\n\n      Bidirectional Forwarding Detection (BFD) is a fault detection\n      protocol that can quickly determine a communication failure between\n      devices and notify upper-layer applications [RFC5880].  BFD has\n      asynchronous detecting mode and demand detection mode to satisfy\n      different scenarios, also supports echo function to reduce the device\n      requirement for BFD.  One-Arm BFD this draft descripted supports\n      another BFD detecting function rather than the echo as described in\n      [RFC5880] [RFC5881], it needs nothing BFD capability to one of the\n      devices deployed BFD detecting.  Using One-Arm BFD function, the one\n      device works on BFD detecting normally and the other device just\n      loopback the BFD packets like echo function.  One-Arm BFD is suitable\n      for the cloud virtualization network, the One-Arm BFD is deploy on\n      NFV gateways, and NFV virtual machine vNICs just enable the echo/\n      loopback process.\n\n  "Merge Types", Michael Toomim, Mitar Milutinovic, Bryn Bellomy, 2019-11-18,\n  <draft-toomim-httpbis-merge-types-00.txt>\n\n      Merge Types specify how to merge multiple simultaneous edits to a\n      resource.  This happens when two computers edit the same state over a\n      network with latency.  A Merge Type specifies how to merge\n      conflicting changes.  If the computers implement and agree upon the\n      same Merge Type, then they can guarantee to reach a consistent state,\n      after arbitrary edits, eventually.\n      \n      You can define new Merge Types.  This document defines Merge Types,\n      the structure of the Merge Type system, and IANA registration\n      procedures for Merge Types.\n\n  "Signing HTTP Requests via JSON Web Signatures", Annabelle Backman,\n  2019-11-18, <draft-richanna-http-jwt-signature-00.txt>\n\n      This document defines a method for generating and validating a\n      digital signature or Message Authentication Code (MAC) over a set of\n      protocol elements within an HTTP Request, using JSON Web Signatures\n      (JWS).\n\n  "Proof-of-Possession Tokens for OAuth Using JWS HTTP Signatures", Annabelle\n  Backman, 2019-11-18, <draft-richanna-oauth-http-signature-pop-00.txt>\n\n      This document describes a method of generating and validating proof-\n      of-possession tokens for use with OAuth 2.0.  The required proof is\n      provided via a JSON Web Signature (JWS) representing a signature of a\n      minimal subset of elements from the HTTP request.\n\n  "Mode of Operation extension", Rahul Jadhav, Pascal Thubert, Michael\n  Richardson, 2019-11-25, <draft-jadhav-roll-mopex-01.txt>\n\n      RPL allows different mode of operations which allows nodes to have a\n      consensus on the basic primitives that must be supported to join the\n      network.  The MOP field in RFC6550 is of 3 bits and is fast\n      depleting.  This document extends the MOP for future use.\n\n  "Segment Routing Mapped To IPv6 (SRm6)", Ron Bonica, Shraddha Hegde, Yuji\n  Kamite, Andrew Alston, Daniam Henriques, Luay Jalil, Joel Halpern, Jen\n  Linkova, Gang Chen, 2019-11-19, <draft-bonica-spring-sr-mapped-six-00.txt>\n\n      This document describes Segment Routing mapped to IPv6 (SRm6).  SRm6\n      is a Segment Routing (SR) solution that leverages IPv6.  It supports\n      a wide variety of use-cases while remaining in strict compliance with\n      IPv6 specifications.  SRm6 is optimized for ASIC-based forwarding\n      devices that operate at high data rates.\n\n  "Advertising IPv4 Network Layer Reachability Information with an IPv6 Next\n  Hop", Stephane Litkowski, Swadesh Agrawal, krishnaswamy ananthamurthy,\n  Keyur Patel, 2019-11-19, <draft-litkowski-bess-rfc5549revision-00.txt>\n\n      Multiprotocol BGP (MP-BGP) [RFC4760] specifies that the set of\n      network-layer protocols to which the address carried in the Next Hop\n      field may belong is determined by the Address Family Identifier (AFI)\n      and the Subsequent Address Family Identifier (SAFI).  The current\n      AFI/SAFI definitions for the IPv4 address family only have provisions\n      for advertising a Next Hop address that belongs to the IPv4 protocol\n      when advertising IPv4 Network Layer Reachability Information (NLRI)\n      or VPN-IPv4 NLRI.  This document specifies the extensions necessary\n      to allow advertising IPv4 NLRI or VPN-IPv4 NLRI with a Next Hop\n      address that belongs to the IPv6 protocol.  This comprises an\n