https://tools.ietf.org/html/ New Current Internet Drafts (All Categories) en Wed, 30 Sep 2020 20:59:28 GMT 1 hourly 1970-01-01T00:00+00:00 60 henrik@levkowetz.com http://www.interglacial.com/rss/about.html https://tools.ietf.org/html/draft-ietf-roll-turnon-rfc8138-17 2020-09-30, rev -17: This document updates RFC 8138 by defining a bit in the RPL DODAG Configuration Option to indicate whether compression is used within the RPL Instance, and specify the behavior of RFC 8138-capable nodes when the bit is set and unset. https://tools.ietf.org/html/draft-ietf-rats-yang-tpm-charra-03 2020-09-30, rev -03: This document defines a YANG RPC and a minimal datastore required to retrieve attestation evidence about integrity measurements from a device following the operational context defined in [I-D.ietf-rats-tpm-based-network-device-attest]. Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement. The module defined requires at least one TPM 1.2 or TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on. https://tools.ietf.org/html/draft-ietf-cbor-tags-oid-01 2020-09-30, rev -01: The Concise Binary Object Representation (CBOR, draft-ietf-cbor- 7049bis) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. https://tools.ietf.org/html/draft-ietf-cbor-7049bis-16 2020-09-30, rev -16: The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. https://tools.ietf.org/html/draft-fairhurst-tsvwg-udp-options-dplpmtud-03 2020-09-30, rev -03: This document specifies how a UDP Options sender implements Datagram Packetization Layer Path Maximum Transmission Unit Discovery (DPLPMTUD) as a robust method for Path Maximum Transmission Unit Discovery. This is a robust method for Path MTU Discovery (PMTUD) that uses the UDP Options Packetization Layer (PL). It allows a datagram application that uses this PL, to discover the largest size of datagram that can be sent across a network path. https://tools.ietf.org/html/draft-ietf-ipsecme-iptfs-02 2020-09-30, rev -02: This document describes a mechanism to enhance IPsec traffic flow security by adding traffic flow confidentiality to encrypted IP encapsulated traffic. Traffic flow confidentiality is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well. https://tools.ietf.org/html/draft-ietf-cbor-packed-00 2020-09-30, rev -00: The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-08 2020-09-30, rev -08: Pairing-based cryptography, a subfield of elliptic curve cryptography, has received attention due to its flexible and practical functionality. Pairings are special maps defined using elliptic curves and it can be applied to construct several cryptographic protocols such as identity-based encryption, attribute- based encryption, and so on. At CRYPTO 2016, Kim and Barbulescu proposed an efficient number field sieve algorithm named exTNFS for the discrete logarithm problem in a finite field. Several types of pairing-friendly curves such as Barreto-Naehrig curves are affected by the attack. In particular, a Barreto-Naehrig curve with a 254-bit characteristic was adopted by a lot of cryptographic libraries as a parameter of 128-bit security, however, it ensures no more than the 100-bit security level due to the effect of the attack. In this memo, we list the security levels of certain pairing-friendly curves, and motivate our choices of curves. First, we summarize the adoption status of pairing-friendly curves in standards, libraries and applications, and classify them in the 128-bit, 192-bit, and 256-bit security levels. Then, from the viewpoints of "security" and "widely used", we select the recommended pairing-friendly curves considering exTNFS. https://tools.ietf.org/html/draft-ietf-pim-dr-improvement-10 2020-09-30, rev -10: Protocol Independent Multicast - Sparse Mode (PIM-SM) is a widely deployed multicast protocol. As deployment for the PIM protocol is growing day by day, a user expects lower packet loss and faster convergence regardless of the cause of the network failure. This document defines an extension to the existing protocol, which improves the PIM protocol's stability with respect to packet loss and convergence time when the PIM Designated Router (DR) role changes. https://tools.ietf.org/html/draft-sas-idr-maxprefix-outbound-00 2020-09-30, rev -00: This document updates RFC4271 by adding a control mechanism which limits the negative impact of outbound route leaks (RFC7908) in order to prevent resource exhaustion in Border Gateway Protocol (BGP) implementations. https://tools.ietf.org/html/draft-ietf-roll-unaware-leaves-21 2020-09-30, rev -21: This specification extends RFC6550 and RFC8505 to provide routing services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND but do not participate in RPL. This specification also enables the RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG. https://tools.ietf.org/html/draft-ietf-spring-srv6-network-programming-23 2020-09-30, rev -23: The SRv6 Network Programming framework enables a network operator or an application to specify a packet processing program by encoding a sequence of instructions in the IPv6 packet header. https://tools.ietf.org/html/draft-ietf-spring-segment-protection-sr-te-paths-00 2020-09-30, rev -00: Segment routing supports the creation of explicit paths using Adj- Segment-ID (SID), Node-SIDs, and BSIDs. It is important to provide fast reroute (FRR) mechanisms to respond to failures of links and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point of local repair (PLR) can provide FRR protection against the failure of a link in an SR-TE path by examining only the first (top) label in the SR label stack. In order to protect against the failure of a node, a PLR may need to examine the second label in the stack as well, in order to determine SR-TE path beyond the failed node. This document specifies how a PLR can use the first and second label in the SR-MPLS label stack describing an SR-TE path to provide protection against node failures. https://tools.ietf.org/html/draft-ietf-6man-rfc4941bis-11 2020-09-30, rev -11: This document describes an extension to IPv6 Stateless Address Autoconfiguration that causes nodes to generate global scope addresses with randomized interface identifiers that change over time. Changing global scope addresses over time limits the window of time during which eavesdroppers and other information collectors may trivially perform address-based network activity correlation when the same address is employed for multiple transactions by the same node. Additionally, it reduces the window of exposure of a node via an address that becomes revealed as a result of active communication. This document obsoletes RFC4941. https://tools.ietf.org/html/draft-ietf-lsr-ospfv3-extended-lsa-yang-05 2020-09-30, rev -05: This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisement (LSA) Extensibility as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340. https://tools.ietf.org/html/draft-peng-apn-security-privacy-consideration-00 2020-09-29, rev -00: APN (Application-aware Networking) architecture aims to convey Application-aware Information including application/user/flow identifiers and SLA/service requirements along with the data packets into the network and make the network aware of applications and their requirements in order to provide corresponding application-aware network services and guarantee their SLA requirements. https://tools.ietf.org/html/draft-tuexen-tsvwg-sctp-udp-encaps-cons-03 2020-09-29, rev -03: RFC 6951 specifies the UDP encapsulation of SCTP packets. The described handling of received packets requires the check of the verification tag. However, RFC 6951 misses a specification for the handling of received packets for which this check is not possible. https://tools.ietf.org/html/draft-ietf-cbor-cddl-control-00 2020-09-29, rev -00: The Concise Data Definition Language (CDDL), standardized in RFC 8610, provides "control operators" as its main language extension point. https://tools.ietf.org/html/draft-irtf-qirg-principles-05 2020-09-29, rev -05: The vision of a quantum internet is to fundamentally enhance Internet technology by enabling quantum communication between any two points on Earth. To achieve this goal, a quantum network stack should be built from the ground up to account for the fundamentally new properties of quantum entanglement. The first realisations of quantum networks are imminent, but there is no practical proposal for how to organise, utilise, and manage such networks. In this memo, we attempt to lay down the framework and introduce some basic architectural principles for a quantum internet. This is intended for general guidance and general interest, but also to provide a foundation for discussion between physicists and network specialists. https://tools.ietf.org/html/draft-rathi-mpls-egress-tlv-for-nil-fec-00 2020-09-29, rev -00: Segment routing supports the creation of explicit paths using adjacency- sids, node-sids, and anycast-sids. The SR-TE paths are built by stacking the labels that represent the nodes and links in the explicit path. A very useful Operations And Maintenance (OAM) requirement is to be able to ping and trace these paths. A simple mpls ping/traceroute mechanism comprises of ability to traverse the SR-TE path without having to validate the control plane state. This document describes mpls ping and traceroute procedures using Nil FEC with additional extensions. https://tools.ietf.org/html/draft-komolafe-pim-igmp-mld-survey-report-00 2020-09-29, rev -00: The PIM WG intends to progress IGMPv3 and MLDv2 from Proposed Standards to Internet Standards. The WG decided to conduct a survey of operators, vendors and implementors of these and related protocols to gather information about their implementation and deployment. This document presents the results of the survey and briefly summarizes the key findings. The survey indicates that there is widespread deployment and usage of of IGMPv3 and MLDv2, with numerous independent implementations interoperating successfully. No major issues with either protocol were identified and, similarly, no major unused features in the specifications were highlighted. These findings suggest that IGMPv3 and MLDv2 are indeed ready for progression to Internet Standards. https://tools.ietf.org/html/draft-bonica-lsr-ip-flexalgo-00 2020-09-29, rev -00: An IGP Flexible Algorithm computes a constraint-based path and maps that path to an identifier. As currently defined, Flexalgo can only map the paths that it computes to Segment Routing (SR) identifiers. Therefore, Flexalgo cannot be deployed in the absence of SR. https://tools.ietf.org/html/draft-ietf-calext-jscalendar-31 2020-09-29, rev -31: This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative and, over time, successor to the widely deployed iCalendar data format, and to be unambiguous, extendable, and simple to process. In contrast to the jCal format, which is also JSON-based, JSCalendar is not a direct mapping from iCalendar, but defines the data model independently and expands semantics where appropriate. https://tools.ietf.org/html/draft-ietf-lisp-rfc6833bis-29 2020-09-29, rev -29: This document describes the Control-Plane and Mapping Service for the Locator/ID Separation Protocol (LISP), implemented by two types of LISP-speaking devices -- the LISP Map-Resolver and LISP Map-Server -- that provides a simplified "front end" for one or more Endpoint ID to Routing Locator mapping databases. https://tools.ietf.org/html/draft-ietf-dnsop-dns-zone-digest-12 2020-09-29, rev -12: This document describes a protocol and new DNS Resource Record that provides a cryptographic message digest over DNS zone data. The ZONEMD Resource Record conveys the digest data in the zone itself. When a zone publisher includes a ZONEMD record, recipients can verify the zone contents for accuracy and completeness. This provides assurance that received zone data matches published data, regardless of how the zone data has been transmitted and received. https://tools.ietf.org/html/draft-ietf-roll-mopex-02 2020-09-29, rev -02: RPL allows different mode of operations which allows nodes to have a consensus on the basic primitives that must be supported to join the network. The MOP field in [RFC6550] is of 3 bits and is fast depleting. This document extends the MOP for future use. https://tools.ietf.org/html/draft-ietf-pce-association-policy-12 2020-09-29, rev -12: This document introduces a simple mechanism to associate policies to a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) Communication Protocol (PCEP). The extension allows a PCEP speaker to advertise to a PCEP peer that a particular LSP belongs to a particular Policy Association Group. https://tools.ietf.org/html/draft-ietf-roll-dao-projection-13 2020-09-29, rev -13: This document updates RFC 6550 to enable a RPL Root to install and maintain Projected Routes within its DODAG, along a selected set of nodes that may or may not include self, for a chosen duration. This potentially enables routes that are more optimized or resilient than those obtained with the classical distributed operation of RPL, either in terms of the size of a source-route header or in terms of path length, which impacts both the latency and the packet delivery ratio. https://tools.ietf.org/html/draft-templin-intarea-6706bis-65 2020-09-28, rev -65: This document specifies the operation of IP over Overlay Multilink Network (OMNI) interfaces using the Asymmetric Extended Route Optimization (AERO) internetworking and mobility management service. AERO/OMNI use an IPv6 link-local address format that supports operation of the IPv6 Neighbor Discovery (ND) protocol and links ND to IP forwarding. Prefix delegation/registration services are employed for network admission and to manage the routing system. Multilink operation, mobility management, quality of service (QoS) signaling and route optimization are naturally supported through dynamic neighbor cache updates. Standard IP multicasting services are also supported. AERO is a widely-applicable mobile internetworking service especially well-suited to aviation services, intelligent transportation systems, mobile Virtual Private Networks (VPNs) and many other applications. https://tools.ietf.org/html/draft-ietf-idr-bgpls-inter-as-topology-ext-09 2020-09-28, rev -09: This document describes the process to build Border Gateway Protocol- Link State (BGP-LS) key parameters in inter-domain scenario, defines one new BGP-LS Network Layer Reachability Information (NLRI) type (Stub Link NLRI) and some new inter Autonomous (inter-AS) Traffic Engineering (TE) related Type-Length-Values (TLVs) for BGP-LS to let Software Definition Network (SDN) controller retrieve the network topology automatically under various inter-AS environments. https://tools.ietf.org/html/draft-ietf-bier-ipv6-requirements-09 2020-09-28, rev -09: There have been several proposed solutions with BIER being used in IPv6. But there hasn't been a document which describes the problem and lists the requirements. The goal of this document is to describe the general BIER IPv6 encapsulation problem and detail solution requirements, thereby assisting the working group in the development of acceptable solutions. https://tools.ietf.org/html/draft-ietf-ntp-mode-6-cmds-10 2020-09-28, rev -10: This document describes the structure of the control messages that were historically used with the Network Time Protocol before the advent of more modern control and management approaches. These control messages have been used to monitor and control the Network Time Protocol application running on any IP network attached computer. The information in this document was originally described in Appendix B of RFC 1305. The goal of this document is to provide an updated description of the control messages described in RFC 1305 in order to conform with the updated Network Time Protocol specification documented in RFC 5905. https://tools.ietf.org/html/draft-ietf-dnsop-rfc7816bis-06 2020-09-28, rev -06: This document describes techniques called "QNAME minimisation" to improve DNS privacy, where the DNS resolver no longer always sends the full original QNAME to the upstream name server. This document obsoletes RFC 7816. https://tools.ietf.org/html/draft-ietf-dots-telemetry-12 2020-09-28, rev -12: This document aims to enrich DOTS signal channel protocol with various telemetry attributes allowing optimal Distributed Denial-of- Service attack mitigation. It specifies the normal traffic baseline and attack traffic telemetry attributes a DOTS client can convey to its DOTS server in the mitigation request, the mitigation status telemetry attributes a DOTS server can communicate to a DOTS client, and the mitigation efficacy telemetry attributes a DOTS client can communicate to a DOTS server. The telemetry attributes can assist the mitigator to choose the DDoS mitigation techniques and perform optimal DDoS attack mitigation. https://tools.ietf.org/html/draft-ietf-v6ops-cpe-slaac-renum-05 2020-09-28, rev -05: In scenarios where network configuration information becomes invalid without any explicit signaling of that condition (such as when a Customer Edge Router crashes and reboots without knowledge of the previously-employed configuration information), hosts on the local network will continue using stale network configuration information for an unacceptably long period of time, thus resulting in connectivity problems. This document specifies improvements to Customer Edge Routers that help mitigate the aforementioned problem for typical residential and small office scenarios. This document updates RFC7084. https://tools.ietf.org/html/draft-vanrein-internetwide-realm-crossover-00 2020-09-28, rev -00: Domains and domain user identities are available in many protocols, and can be expressed as part of the URI grammar. This document outlines how clients can bring their self-controlled identities over when crossing over to foreign realms that rely on authenticated user identities. https://tools.ietf.org/html/draft-tuexen-opsawg-pcapng-02 2020-09-28, rev -02: This document describes a format to record captured packets to a file. This format is extensible; Wireshark can currently read and write it, and libpcap can currently read some pcapng files. https://tools.ietf.org/html/draft-wang-lsr-passive-interface-attribute-04 2020-09-28, rev -04: This document describes the mechanism that can be used to differentiate the passive interfaces from the normal interfaces within ISIS or OSPF domain. https://tools.ietf.org/html/draft-ce-lsr-ppr-graph-04 2020-09-28, rev -04: This document defines a graph structure for the Preferred Path Route (PPR) for IS-IS, OSPFv2 and OSPFv3 protocols. This structure helps further scale of the PPR and reduce domain level global entries needed in some data planes. https://tools.ietf.org/html/draft-chunduri-lsr-isis-preferred-path-routing-06 2020-09-28, rev -06: This document specifies Preferred Path Routing (PPR), an extensible method of providing path based dynamic routing for a number of packet types including IPv4, IPv6 and MPLS. PPR uses a simple encapsulation to add the path identity to the packet. PPR can also be used to mitigate the MTU and data plane processing issues that may result from Segment Routing (SR) packet overhead; and also supports further extensions along the paths. https://tools.ietf.org/html/draft-ietf-v6ops-slaac-renum-04 2020-09-28, rev -04: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long time (on the order of several days), thus resulting in connectivity problems. This document documents this issue and discusses operational workarounds that may help to improve network robustness. Additionally, it highlights areas where further work may be needed. https://tools.ietf.org/html/draft-chen-pim-srv6-p2mp-path-01 2020-09-28, rev -01: This document describes a solution for a SRv6 Point-to-Multipoint (P2MP) Path/Tree to deliver the traffic from the ingress of the path to the multiple egresses/leaves of the path in a SR domain. There is no state stored in the core of the network for a SR P2MP path like a SR Point-to-Point (P2P) path in this solution. https://tools.ietf.org/html/draft-irtf-cfrg-opaque-00 2020-09-28, rev -00: This document describes the OPAQUE protocol, a secure asymmetric password-authenticated key exchange (aPAKE) that supports mutual authentication in a client-server setting without reliance on PKI and with security against pre-computation attacks upon server compromise. In addition, the protocol provides forward secrecy and the ability to hide the password from the server, even during password registration. This document specifies the core OPAQUE protocol, along with several instantiations in different authenticated key exchange protocols. https://tools.ietf.org/html/draft-clt-dmm-tn-aware-mobility-07 2020-09-28, rev -07: This document specifies a framework and mapping from slices in 5G mobile systems to transport slices in IP and Layer 2 transport networks. Slices in 5G systems are characterized by latency bounds, reservation guarantees, jitter, data rates, availability, mobility speed, usage density, criticality and priority should be mapped to transport slice characteristics that include bandwidth, latency and criteria such as isolation, directionality and disjoint routes. Mobile slice criteria need to be mapped to the appropriate transport slice and capabilities offered in backhaul, midhaul and fronthaul connectivity segments between radio side network functions and user plane function (gateway). https://tools.ietf.org/html/draft-ietf-dnsop-rfc5933-bis-02 2020-09-28, rev -02: This document describes how to produce digital signatures and hash functions using the GOST R 34.10-2012 and GOST R 34.11-2012 algorithms for DNSKEY, RRSIG, and DS resource records, for use in the Domain Name System Security Extensions (DNSSEC). https://tools.ietf.org/html/draft-ietf-lisp-vendor-lcaf-07 2020-09-28, rev -07: This document describes a new LISP Canonical Address Format (LCAF), the Vendor Specific LCAF. This LCAF enables organizations to have internal encodings for LCAF addresses. https://tools.ietf.org/html/draft-dontula-lsr-yang-dynamic-flooding-04 2020-09-28, rev -04: This document defines YANG data models that can be used to configure and manage Dynamic Flooding for IS-IS and OSPF. https://tools.ietf.org/html/draft-deevi-spring-bgp-sr-yang-00 2020-09-28, rev -00: This document defines a YANG data model that can be used to configure and manage Segment Routing extensions in BGP. https://tools.ietf.org/html/draft-deevi-idr-bgp-srte-yang-00 2020-09-28, rev -00: This document defines a YANG data model that can be used to configure and manage Segment Routing TE extensions in BGP. https://tools.ietf.org/html/draft-ietf-dots-server-discovery-11 2020-09-27, rev -11: This document specifies mechanisms to configure Districuted Denial of Service Open Threat Signaling (DOTS) clients with their DOTS servers. The discovery procedure also covers the DOTS Signal Channel Call Home. Knowing the appropriate DOTS server for a given location can be useful to engage mitigation actions even in cases where the DOTS client cannot localize the attack, but only knows that some resources are under attack and that help is needed. https://tools.ietf.org/html/draft-chen-pce-pcep-extension-pce-controller-bier-00 2020-09-27, rev -00: This draft specify the procedures and PCEP protocol extensions for using the PCE as the central controller for BIER. https://tools.ietf.org/html/draft-chen-pce-controller-bier-te-00 2020-09-27, rev -00: This document specifies extensions to PCEP protocol when a PCE-based controller is also responsible for configuring the forwarding actions on the routers, in addition to computing the paths for packet flows in a BIER-TE network and telling the edge routers what instructions to attach to packets as they enter the network. https://tools.ietf.org/html/draft-moskowitz-drip-secure-nrid-c2-01 2020-09-27, rev -01: This document provides the mechanisms for secure transport of UAS Network-RemoteID and Command-and-Control messaging. Both HIP and DTLS based methods are described. https://tools.ietf.org/html/draft-yang-tls-tls13-sm-suites-06 2020-09-27, rev -06: This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3. https://tools.ietf.org/html/draft-bormann-t2trg-rel-impl-02 2020-09-27, rev -02: For debugging, it is often helpful to have information about the implementation of a peer. The present specification defines a link relation type, "impl-info", that can be used to convey such information via self-description, such as in the "/.well-known/core" resource. https://tools.ietf.org/html/draft-peng-lsr-algorithm-related-adjacency-sid-01 2020-09-26, rev -01: Segment Routing architecture supports the use of multiple routing algorithms, i.e, different constraint-based shortest-path calculations can be supported. There are two standard algorithms: SPF and Strict-SPF, defined in Segment Routing architecture. There are also other user defined algorithms according to Flex-algo applicaiton. However, an algorithm identifier is often included as part of a Prefix-SID advertisement, that maybe not satisfy some scenarios where multiple algorithm share the same link resource. This document complement that the algorithm identifier can be also included as part of a Adjacency-SID advertisement https://tools.ietf.org/html/draft-ietf-roll-nsa-extension-09 2020-09-26, rev -09: Packet Replication and Elimination is a method in which several copies of a data packet are sent in the network in order to achieve high reliability and low jitter. This document details how to apply Packet Replication and Elimination in RPL, especially how to exchange information within RPL control packets to let a node better select the different parents that will be used to forward the multiple copies of a packet. This document also describes the Objective Function which takes advantage of this information to implement multi-path routing. https://tools.ietf.org/html/draft-gandhi-spring-sr-enhanced-plm-03 2020-09-26, rev -03: Segment Routing (SR) leverages the source routing paradigm. SR is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document defines procedure for Enhanced Performance Delay and Liveness Monitoring (PDLM) in Segment Routing networks. The procedure leverages the probe messages compatible with the delay measurement message formats defined in RFC 5357 (Two-Way Active Measurement Protocol (TWAMP)) and RFC 8762 (Simple Two-Way Active Measurement Protocol (STAMP)) and is applicable to end-to-end SR Paths including SR Policies for both SR-MPLS and SRv6 data planes. https://tools.ietf.org/html/draft-sidrops-bgpsec-validation-signaling-05 2020-09-25, rev -05: This document defines a new BGP non-transitive extended community to carry the BGPsec path validation state. BGP speakers that receive this community string can use the embedded BGPsec validation state in conjunction with configured local policies to influence their decision process. The ability to accept and act on BGPsec path validation state from a neighbor allows for a reduction of path validation processing load and/or increased resilience in the event that a router is temporarily unable to perform local path validation. https://tools.ietf.org/html/draft-ecrit-location-profile-registry-policy-01 2020-09-25, rev -01: This document changes the policy of the Location-to-Service Translation (LoST) Location Profile registry established by RFC5222 from Standards Action to Specification Required. This allows standards development organizations (SDOs) other than the IETF to add new values.