Internet Drafts - Sorted by name


    
draft-6tisch-enrollment-enhanced-beacon-00.txt
 IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information
 
 draft-6tisch-enrollment-enhanced-beacon-00.txt
 Date: 16/07/2018
 Authors: Diego Dujovne, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml
In TSCH mode of IEEE802.15.4, as described by [RFC8180], opportunities for broadcasts are limited to specific times and specific channels. Nodes in a TSCH network typically frequently send Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which small details critical for new nodes (pledges) and long sleeping nodes may be carried within the Enhanced Beacon.
    
draft-accilent-at-sign-00.txt
 Clarification of Proper Use of "@" (at sign) in URI-style Components
 
 draft-accilent-at-sign-00.txt
 Date: 30/07/2010
 Authors: Robert Simpson
 Working Group: Individual Submissions (none)
 Formats: xml txt
Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses.
    
draft-acee-idr-lldp-peer-discovery-03.txt
 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery
 
 draft-acee-idr-lldp-peer-discovery-03.txt
 Date: 30/06/2018
 Authors: Acee Lindem, Keyur Patel, Shawn Zandi, Jeffrey Haas, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt
Link Layer Discovery Protocol (LLDP) or IEEE 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses.
    
draft-acee-lsr-ospfv3-extended-lsa-yang-00.txt
 Yang Model for OSPFv3 Extended LSAs
 
 draft-acee-lsr-ospfv3-extended-lsa-yang-00.txt
 Date: 27/06/2018
 Authors: Acee Lindem, Sharmila Palani
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisment (LSA) Extensibility as defined in RFC 8263. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340.
    
draft-acg-mboned-deprecate-interdomain-asm-02.txt
 Deprecating ASM for Interdomain Multicast
 
 draft-acg-mboned-deprecate-interdomain-asm-02.txt
 Date: 02/07/2018
 Authors: Mikael Abrahamsson, Tim Chown, Leonard Giuliano, Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications, and that hosts and routers that are expected to handle such applications fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organisation or domain, and are especially easy to adopt when already using the preferred ASM protocol options there (PIM-SM).
    
draft-alavarez-hamelin-tictoc-sic-01.txt
 Synchronizing Internet Clock frequency protocol (sic)
 
 draft-alavarez-hamelin-tictoc-sic-01.txt
 Date: 29/06/2018
 Authors: Jose Alvarez-Hamelin, David Samaniego, Alfredo Ortega, Ruediger Geib
 Working Group: Individual Submissions (none)
 Formats: txt xml
Synchronizing Internet Clock Frequency specifies a new secure method to synchronize difference clocks on the Internet, assuring smoothness (i.e., frequency stability) and robustness to man-in-the-middle attacks. In 90% of all cases, Synchronized Internet Clock Frequency is highly accurate, with a Maximum Time Interval Error less than 25 microseconds by a minute. Synchronized Internet Clock Frequency is based on a regular packet exchange and works with commodity terminal hardware.
    
draft-ali-spring-bfd-sr-policy-00.txt
 Bidirectional Forwarding Detection (BFD) for Segment Routing Policies for Traffic Engineering
 
 draft-ali-spring-bfd-sr-policy-00.txt
 Date: 05/03/2018
 Authors: Zafar Ali, Ketan Talaulikar, Clarence Filsfils
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path using a segment list which is referred to as a SR Policy. Intermediate per-flow states are eliminated thanks to source routing. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. Bidirectional Forwarding Detection (BFD) is used to monitor different kinds of paths between node. BFD mechanisms can be also used to monitor the availability of the path indicated by a SR Policy and to detect any failures. Seamless BFD (SBFD) extensions provide a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale. This document describes the use of Seamless BFD (SBFD) mechanism to monitor the SR Policies that are used for Traffic Engineering (TE) in SR deployments.
    
draft-ali-spring-network-slicing-building-blocks-00.txt
 Building blocks for Slicing in Segment Routing Network
 
 draft-ali-spring-network-slicing-building-blocks-00.txt
 Date: 02/07/2018
 Authors: Zafar Ali, Clarence Filsfils, Pablo Camarillo
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how to build network slice using the Segment Routing based technology. It explains how the existing building blocks specified for the Segment Routing can be used for this purpose.
    
draft-ali-spring-sr-traffic-accounting-02.txt
 Traffic Accounting in Segment Routing Networks
 
 draft-ali-spring-sr-traffic-accounting-02.txt
 Date: 07/06/2018
 Authors: Zafar Ali, Clarence Filsfils, Ketan Talaulikar, Siva Sivabalan, Martin Horneffer, Robert Raszuk, Stephane Litkowski, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
Capacity planning is the continuous art of forecasting traffic load and failures to evolve the network topology, its capacity, and its routing to meet a defined Service-Level Agreement (SLA). This document takes a holistic view of network capacity planning and identifies the role of traffic accounting in network operation and capacity planning, without creating any additional states in the SR fabric.
    
draft-ali-spring-srv6-oam-01.txt
 Operations,Administration,and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
 
 draft-ali-spring-srv6-oam-01.txt
 Date: 02/07/2018
 Authors: Zafar Ali, Clarence Filsfils, Nagendra Kumar, Carlos Pignataro, faiqbal@cisco.com, Rakesh Gandhi, John Leddy, Satoru Matsushima, Robert Raszuk, daniel.voyer@bell.ca, Gaurav Dawra, Bart Peirens, Mach Chen, Gaurav Naik
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines building blocks that can be used for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane (SRv6). The document also describes some SRv6 OAM mechanisms that can be realized using these building blocks.
    
draft-ali-spring-srv6-pm-02.txt
 Performance Measurement in Segment Routing Networks with IPv6 Data Plane (SRv6)
 
 draft-ali-spring-srv6-pm-02.txt
 Date: 27/02/2018
 Authors: Zafar Ali, Clarence Filsfils, Rakesh Gandhi, Nagendra Kumar, Dirk Steinberg, Stefano Salsano, Pier Ventre, Gaurav Naik, daniel.voyer@bell.ca, daniel.bernier@bell.ca
 Working Group: Individual Submissions (none)
RFC 6374 specifies protocol mechanisms to enable efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay variation and channel throughput in MPLS networks. This document describes how these mechanisms can be used for performance measurement of delay and loss in Segment Routing with IPv6 data plane (SRv6) networks.
    
draft-allan-pim-sr-mpls-multicast-framework-00.txt
 A Framework for Computed Multicast Applied to SR-MPLS
 
 draft-allan-pim-sr-mpls-multicast-framework-00.txt
 Date: 01/06/2018
 Authors: Dave Allan, Jeff Tantsura, Ian Duncan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a multicast solution for SR-MPLS. It is consistent with the Segment Routing architecture in that an IGP is augmented to distribute information in addition to the link state. In this solution it is multicast group membership information sufficient to synchronize state in a given network domain. Computation is employed to determine the topology of any loosely specified multicast distribution tree.
    
draft-amsuess-core-rd-replication-01.txt
 Resource Directory Replication
 
 draft-amsuess-core-rd-replication-01.txt
 Date: 02/03/2018
 Authors: Christian Amsuess
 Working Group: Individual Submissions (none)
 Formats: xml txt
Discovery of endpoints and resources in M2M applications over large networks is enabled by Resource Directories, but no special consideration has been given to how such directories can scale beyond what can be managed by a single device. This document explores different ways in which Resource Directories can be scaled up from single network to enterprise and global scale. It does not attempt to standardize any of those methods, but only to demonstrate the feasibility of such extensions and to provide terminology and exploratory groundwork for later documents.
    
draft-an-savi-mib-15.txt
 Definition of Managed Objects for SAVI Protocol
 
 draft-an-savi-mib-15.txt
 Date: 18/07/2018
 Authors: Changqing An, Jiahai Yang, Jianping Wu, Jun Bi
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing SAVI (Source Address Validation Improvements) protocol instance.
    
draft-an-savi-yang-03.txt
 A Yang Data Model for SAVI Management
 
 draft-an-savi-yang-03.txt
 Date: 08/02/2018
 Authors: Changqing An, Jiahai Yang, Jianping Wu, Jun Bi
 Working Group: Individual Submissions (none)
 Formats: txt
This document contains a specification of YANG modules for the management of SAVI (Source Address Validation Improvements) protocol. The core SAVI data module ietf-savi serves as a framework for configuring and managing SAVI instance and provides common building blocks. It is expected to be augmented by additional YANG modules for specific IP address assignment methods. The other four modules augment the core SAVI data module and define data models for different IP address assignment methods. Module ietf-savi-fcfs defines module specific for Stateless Address Auto Configuration (SLAAC), module ietf-savi-dhcpv4 and ietf-savi-dhcpv6 define modules specific for Dynamic Host Configuration Protocol version 4 and version 6 (DHCPv4 and DHCPv6), and module ietf-savi- send defines module specific for Secure Neighbor Discovery (SEND).
    
draft-anand-ippm-po-ioam-00.txt
 Integrated Packet-Optical In-Situ OAM
 
 draft-anand-ippm-po-ioam-00.txt
 Date: 26/02/2018
 Authors: Madhukar Anand, Sanjoy Bardhan, Radha Valiveti, Ramesh Subrahmaniam, Carlos Pignataro, Shwetha Bhandari, Randy Zhang, Rajiv Asati
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a way to extend in-situ OAM techniques to include operational data from multiple network layers with a view to create an integrated record of OAM information as the data flows between two network entities. An instance of this technique that is elaborated here focuses on packet-optical networks that are traditionally transport centric. The mechanisms described are general enough to allow future extensibility of in-situ OAM techniques into other non-packet domains.
    
draft-anand-spring-poi-sr-05.txt
 Packet-Optical Integration in Segment Routing
 
 draft-anand-spring-poi-sr-05.txt
 Date: 06/02/2018
 Authors: Madhukar Anand, Sanjoy Bardhan, Ramesh Subrahmaniam, Jeff Tantsura, Utpal Mukhopadhyaya, Clarence Filsfils
 Working Group: Individual Submissions (none)
 Formats: txt
This document illustrates a way to integrate a new class of nodes and links in segment routing to represent transport networks in an opaque way into the segment routing domain. An instance of this class would be optical networks that are typically transport centric. In the IP centric network, this will help in defining a common control protocol for packet optical integration that will include optical paths as 'transport segments' or sub-paths as an augmentation to packet paths. The transport segment option also defines a general mechanism to allow for future extensibility of segment routing into non-packet domains.
    
draft-andersdotter-intarea-update-to-rfc6302-00.txt
 An update to RFC6302 on Logging Recommendations for Internet-Facing Servers
 
 draft-andersdotter-intarea-update-to-rfc6302-00.txt
 Date: 22/04/2018
 Authors: Amelia Andersdotter
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft seeks to update RFC6302 on Logging Recommendations for Internet-Facing Servers. The new recommendations aim to be a best practice for service providers and server maintainers, by following recommendations outlined in RFC6973 and taking into account new regulatory requirements in the privacy area.
    
draft-andersen-historic-4406-etal-01.txt
 Status Change for RFCs 4405,4406,4407 to Historic
 
 draft-andersen-historic-4406-etal-01.txt
 Date: 24/03/2018
 Authors: Kurt Andersen
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
This document acknowledges that Sender ID did not pass its experiment, and changes the status of RFCs 4405 [RFC4405], 4406 [RFC4406], and 4407 [RFC4407] to Historic.
    
draft-anilj-icnrg-icn-qos-00.txt
 Supporting QoS aware Data Delivery in Information Centric Networks
 
 draft-anilj-icnrg-icn-qos-00.txt
 Date: 14/07/2018
 Authors: Anil Jangam, Prakash suthar, Milan Stolic
 Working Group: Individual Submissions (none)
 Formats: txt
Information Centric Networking (ICN) is shaping up as an alternative networking mechanism for the TCP/IP based host-centric networking paradigm. Content delivery or streaming is one of important use cases where the real value and potential of ICN architecture is being investigated. While a number of studies on an optimal and efficient routing of Interest requests have been published, more discussion is needed on the mechanisms for implementation and enforcement of the quality of service (QoS) in the ICN based data delivery path. In this document, we focus on two most popular ICN architectures, CCN (Content Centric Networking) and NDN (Named Data Networking) and describe how we can achieve the QoS aware data delivery in the ICN network. We propose to use the differentiated services (DiffServ) QoS model based on DSCP codes, which is also used in the IP based Internet design. We further present how QoS parameter syntax can be added to the current CCNx messages.
    
draft-anish-reliable-pim-registers-02.txt
 Reliable Transport For PIM Register States
 
 draft-anish-reliable-pim-registers-02.txt
 Date: 19/03/2018
 Authors: Anish Peter, Robert Kebler, Vikram Nagarajan, Toerless Eckert, Stig Venaas
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a hard-state, reliable transport for the existing PIM-SM registers states. This eliminates the needs for periodic NULL-registers and register-stop in response to each data- register or NULL-registers. This specification uses the existing PIM reliability mechanisms defined by PIM Over Reliable Transport [RFC6559]. This is simply a means to transmit reliable PIM messages and does not require the support for Join/Prune messages over PORT as defined in [RFC6559].
    
draft-annee-dprive-oblivious-dns-00.txt
 Oblivious DNS - Strong Privacy for DNS Queries
 
 draft-annee-dprive-oblivious-dns-00.txt
 Date: 02/07/2018
 Authors: Annie Edmundson, Paul Schmitt, Nick Feamster, Allison Mankin
 Working Group: Individual Submissions (none)
 Formats: txt
Recognizing the privacy vulnerabilities associated with DNS queries, a number of standards have been developed and services deployed that that encrypt a user's DNS queries to the recursive resolver and thus obscure them from some network observers and from the user's Internet service provider. However, these systems merely transfer trust to a third party. We argue that no single party should be able to associate DNS queries with a client IP address that issues those queries. To this end, this document specifies Oblivious DNS (ODNS), which introduces an additional layer of obfuscation between clients and their queries. To accomplish this, ODNS uses its own authoritative namespace; the authoritative servers for the ODNS namespace act as recursive resolvers for the DNS queries that they receive, but they never see the IP addresses for the clients that initiated these queries. The ODNS experimental protocol is compatible with existing DNS infrastructure.
    
draft-ao-nvo3-multi-encap-interconnect-00.txt
 Multi-encapsulation interconnection for Overlay Virtual Network
 
 draft-ao-nvo3-multi-encap-interconnect-00.txt
 Date: 01/03/2018
 Authors: Ting Ao, Gregory Mirsky, Fan Yongbing
 Working Group: Individual Submissions (none)
 Formats: txt
For an virtualized overlay network, there are many encapsulations that may be used. Different customer have their own preference. So if some of these different encapsulation can be interconnected together, the virtualized overlay network would be more compatible and have loose strict on access. This document is going to provide an architecture of different overlay encapsulation interconnection and an tranformer gateway for these end station connected to the virtual network.
    
draft-ao-sfc-oam-path-consistency-02.txt
 SFC OAM for path consistency
 
 draft-ao-sfc-oam-path-consistency-02.txt
 Date: 28/02/2018
 Authors: Ting Ao, Gregory Mirsky, Zhonghua Chen
 Working Group: Individual Submissions (none)
 Formats: txt
Service Function Chain (SFC) defines an ordered set of service functions (SFs) to be applied to packets and/or frames and/or flows selected as a result of classification. SFC Operation, Administration and Maintenance can monitor the continuity of the SFC, i.e., that all elements of the SFC are reachable to each other in the downstream direction. But SFC OAM must support verification that the order of traversing these SFs corresponds to the state defined by the SFC control plane or orchestrator, the metric referred in this document as the path consistency of the SFC. This document defines a new SFC OAM method to support SFC consistency, i.e. verification that all elements of the given SFC are being traversed in the expected order.
    
draft-aranda-dispatch-q4s-06.txt
 The Quality for Service Protocol
 
 draft-aranda-dispatch-q4s-06.txt
 Date: 15/07/2018
 Authors: Jose Garcia, Monica Cortes, Joaquin Salvachua, Tecnalia Innovation, Inaki Sarriegui
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This memo describes an application level protocol for the standard communication of e2e QoS compliance information using a protocol based on Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web, and Session Description Protocol (SDP). Quality for Service Protocol (Q4S) provides a mechanism for latency, jitter, bandwidth and packet loss negotiation and monitoring, alerting whenever one of the negotiated conditions is violated. Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this draft, it is application dependent (e.g. increase quality, reduce bit-rate) or even network dependent (e.g. change connection's quality profile).
    
draft-aranda-nfvrg-recursive-vnf-05.txt
 High-level VNF Descriptors using NEMO
 
 draft-aranda-nfvrg-recursive-vnf-05.txt
 Date: 26/02/2018
 Authors: Pedro Gutierrez, Diego Lopez, Stefano Salsano, Elena Batanero
 Working Group: Individual Submissions (none)
 Formats: xml txt
Current efforts in the scope of Network Function Virtualisation(NFV) propose YAML-based descriptors for Virtual Network Functions (VNFs) and for their composition in Network Services (NS) These descriptors are human-readable but hardly understandable by humans. On the other hand, there has been an effort proposed to the IETF to define a human-readable (and understandable) representation for networks, known as NEMO. In this draft, we propose a simple extension to NEMO to accommodate VNF Descriptors (VNFDs) in a similar manner as inline assembly is integrated in higher-level programming languages. This approach enables the creation of recursive VNF forwarding graphs in Service Descriptors, practically making them recursive. An implementation generating VNF Descriptors (VNFDs) for OpenMANO and OSM is available.
    
draft-arias-noguchi-dnrd-objects-mapping-09.txt
 Domain Name Registration Data (DNRD) Objects Mapping
 
 draft-arias-noguchi-dnrd-objects-mapping-09.txt
 Date: 28/06/2018
 Authors: Gustavo Lozano, James Gould, Chethan Thippeswamy
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) Escrow deposits for a Domain Name Registry.
    
draft-arias-noguchi-registry-data-escrow-10.txt
 Registry Data Escrow Specification
 
 draft-arias-noguchi-registry-data-escrow-10.txt
 Date: 28/06/2018
 Authors: Gustavo Lozano
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. However, the specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for purposes other than domain name registries.
    
draft-arkko-arch-virtualization-01.txt
 Considerations on Network Virtualization and Slicing
 
 draft-arkko-arch-virtualization-01.txt
 Date: 05/03/2018
 Authors: Jari Arkko, Jeff Tantsura, Joel Halpern, Balazs Varga
 Working Group: Individual Submissions (none)
 Formats: txt
This document makes some observations on the effects of virtualization on Internet architecture, as well as provides some guidelines for further work at the IETF relating to virtualization. This document also provides a summary of IETF technologies that relate to network virtualization. An understanding of what current technologies there exist and what they can or cannot do is the first step in developing plans for possible extensions.
    
draft-arkko-eap-aka-pfs-02.txt
 Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)
 
 draft-arkko-eap-aka-pfs-02.txt
 Date: 02/07/2018
 Authors: Jari Arkko, Karl Norrman, Vesa Torvinen
 Working Group: Individual Submissions (none)
 Formats: txt
Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. This specification is an optional extension to the EAP-AKA' authentication method which was defined in RFC 5448. The extension provides Perfect Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from merely passively eavesdropping the EAP-AKA' exchanges and deriving associated session keys, forcing attackers to use active attacks instead.
    
draft-arkko-iasa2-trust-rationale-00.txt
 Discussion of the IASA 2.0 Changes as They Relate to the IETF Trust
 
 draft-arkko-iasa2-trust-rationale-00.txt
 Date: 27/06/2018
 Authors: Jari Arkko
 Working Group: Individual Submissions (none)
 Formats: txt
The IASA 2.0 changes will have an impact in the IETF Trust as well, because members of the IET Administrative Oversight Committee (IAOC) IAOC have also served as trustees of the IETF Trust. A proposal for a minimal change regarding this has been provided separately in [I-D.arkko-iasa2-trust-update]. This companion memo provides some background on the details of the current IETF Trust arrangements, explains the effect of the rules in the founding documents during a transition to a new arrangement, and provides a rationale for the update. This memo is provided only for discussion.
    
draft-arkko-iasa2-trust-update-00.txt
 Update to the Selection of Trustees for the IETF Trust
 
 draft-arkko-iasa2-trust-update-00.txt
 Date: 27/06/2018
 Authors: Jari Arkko, Ted Hardie
 Working Group: Individual Submissions (none)
 Formats: txt
This memo updates the selection of trustees for the IETF Trust. Previously, Administrative Oversight Committee (IAOC) members also acted as trustees. This memo specifies that the trustees shall be selected separately. This memo updates RFCs 4071 and 4371 with regards to the selection of trustees. All other aspects of the IETF Trust remain as they are today.
    
draft-arkko-trip-registry-update-00.txt
 Update to the TRIP IANA Registry Rules Regarding Postal Addresses
 
 draft-arkko-trip-registry-update-00.txt
 Date: 18/07/2018
 Authors: Jari Arkko, Ted Hardie
 Working Group: Individual Submissions (none)
 Formats: txt
This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information. This memo updates RFC 3219.
    
draft-asaeda-icnrg-ccninfo-01.txt
 CCNinfo: Discovering Content and Network Information in Content-Centric Networks
 
 draft-asaeda-icnrg-ccninfo-01.txt
 Date: 30/06/2018
 Authors: Hitoshi Asaeda, Xun Shao
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN routing path information per name prefix, device name, and function/ application, 2) the Round-Trip Time (RTT) between content forwarder and consumer, and 3) the states of in-network cache per name prefix. In addition, it discovers a gateway that supports different protocols such as CCN and Named-Data Networks (NDN).
    
draft-asciirfc-minimal-02.txt
 A Minimal Internet-Draft In AsciiRFC
 
 draft-asciirfc-minimal-02.txt
 Date: 12/04/2018
 Authors: Josiah Carberry, Truman Grayson
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the "asciidoctor-rfc" Ruby gem.
    
draft-asechoud-rtgwg-qos-model-07.txt
 YANG Model for QoS
 
 draft-asechoud-rtgwg-qos-model-07.txt
 Date: 14/07/2018
 Authors: Aseem Choudhary, Mahesh Jethanandani, Norm Strahle, Ebben Aries, Ing-Wher Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG model for Quality of Service (QoS) configuration and operational parameters.
    
draft-asechoud-rtgwg-qos-oper-model-02.txt
 YANG Model for QoS Operational Parameters
 
 draft-asechoud-rtgwg-qos-oper-model-02.txt
 Date: 02/07/2018
 Authors: Aseem Choudhary, Ing-Wher Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG model for Quality of Service (QoS) operational parameters.
    
draft-asechoud-rtgwg-qos-telemetry-req-00.txt
 QoS Telemetry Requirements
 
 draft-asechoud-rtgwg-qos-telemetry-req-00.txt
 Date: 12/05/2018
 Authors: Aseem Choudhary
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses QoS requirements for data model based network telemetry. QoS configuration and operational models have been defined as part of [I-D.asechoud-rtgwg-qos-model] and [I-D.asechoud-rtgwg-qos-oper-model] respectively. This document describes the requirement to extend the models to support QoS Telemetry.
    
draft-asmithee-tls-dnssec-downprot-00.txt
 TLS Downgrade protection extension for TLS DNSSEC Authentication Chain Extension
 
 draft-asmithee-tls-dnssec-downprot-00.txt
 Date: 15/05/2018
 Authors: Paul Wouters, Viktor Dukhovni
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft specifies a TLS extension that adds downgrade protection for another TLS extension, [dnssec-chain-extension]. Without the downgrade protection specified in this TLS extension, the only effect of deploying [dnssec-chain-extension] is to reduce TLS security from the standard "WebPKI security" to "WebPKI or DANE, whichever is weaker". This draft dictates that [dnssec-chain-extension] MUST only be used in combination with this TLS extension, whose only content is a two octet SupportLifetime value. A value of 0 prohibits the TLS client from unilaterally requiring ongoing use of both TLS extensions based on prior observation of their use (pinning). A non-zero value is the value in hours for which this TLS extension as well as [dnssec-chain-extension] MUST appear in subsequent TLS handshakes to the same TLS hostname and port. If this TLS extention or [dnssec-chain-extension] is missing from the TLS handshake within this observed pinning time, the TLS client MUST assume it is under attack and abort the TLS connection.
    
draft-asveren-dispatch-http-overload-control-00.txt
 HTTP Overload Control Mechanism
 
 draft-asveren-dispatch-http-overload-control-00.txt
 Date: 14/04/2018
 Authors: Tolga Asveren
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a generic overload control mechanism for HTTP/HTTPS applications.
    
draft-asveren-stir-p-charge-info-00.txt
 PASSPorT Extension for P-Charge-Info Header
 
 draft-asveren-stir-p-charge-info-00.txt
 Date: 08/05/2018
 Authors: Tolga Asveren
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document extends the PASSporT (Personal Assertion Token) specification defined in [RFC8225] to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the 'Session Initiation Protocol (SIP) P-Charge-Info' header, which is used for conveying information about the entity to be charged for a particular real time session.
    
draft-atarius-dispatch-meid-urn-18.txt
 A Uniform Resource Name Namespace for the Device Identity and the Mobile Equipment Identity (MEID)
 
 draft-atarius-dispatch-meid-urn-18.txt
 Date: 10/06/2018
 Authors: Roozbeh Atarius
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the Third Generation Partnership Project 2 (3GPP2) (see [S.R0048-A]) to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.
    
draft-atarius-dispatch-meid-urn-as-instanceid-08.txt
 Using the Mobile Equipment Identity (MEID) Uniform Resource Name (URN) as an Instance ID
 
 draft-atarius-dispatch-meid-urn-as-instanceid-08.txt
 Date: 10/06/2018
 Authors: Roozbeh Atarius
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
This specification specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior.
    
draft-auge-dmm-hicn-mobility-00.txt
 Anchorless mobility through hICN
 
 draft-auge-dmm-hicn-mobility-00.txt
 Date: 20/06/2018
 Authors: Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents how mobility management is handled in Hybrid- ICN [I-D.muscariello-intarea-hicn]. The objective of the document is to present how end-points mobility is managed in two main cases: the end-point sends data (data producer ) or the end-point receive data (data consumer). These two cases are taken into account entirely to provide anchorless mobility management in hICN.
    
draft-auge-dmm-hicn-mobility-deployment-options-00.txt
 Anchorless mobility management through hICN (hICN-AMM): Deployment options
 
 draft-auge-dmm-hicn-mobility-deployment-options-00.txt
 Date: 19/06/2018
 Authors: Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini
 Working Group: Individual Submissions (none)
 Formats: txt
A novel mobility management approach is described in [I-D.auge-dmm-hicn-mobility], that leverages routable location- independent identifiers (IDs) and an Information-Centric Networking (ICN) communication model integrated in IPv6, (also referred to as Hybrid ICN, hICN, [I-D.muscariello-intarea-hicn]. Such approach belongs to the category of pure ID-based mobility management schemes whose objective is (i) to overcome the limitations of traditional locator-based solutions like Mobile IP, (ii) to remove the need for a global mapping system as the one required by locator- identifier separation solutions like LISP [I-D.ietf-lisp-introduction] or ILA [I-D.herbert-intarea-ila]. ID-based networking as proposed by ICN architectures allows to disentangle forwarding operations from changes of network location, hence removing tunnels and user plane or control plane anchors. In virtue of its anchorless property, we denote this approach as hICN- AMM (hICN Anchorless Mobility Management) hereinafter. This document discusses hICN-AMM deployment options and related tradeoffs in terms of cost/benefits. Particular attention is devoted to the insertion in the recently proposed 5G Service Based Architecture under study at 3GPP where an hICN-AMM solution might present a more efficient alternative to the traditional tunnel-based mobility architecture through GTP-U.
    
draft-aura-eap-noob-03.txt
 Nimble out-of-band authentication for EAP (EAP-NOOB)
 
 draft-aura-eap-noob-03.txt
 Date: 02/07/2018
 Authors: Tuomas Aura, Mohit Sethi
 Working Group: Individual Submissions (none)
 Formats: txt xml
Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. This EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have a minimal user interface and no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB channel between the peer device and authentication server.
    
draft-authors-lpwan-schc-802154-00.txt
 SCHC for 802.15.4 lpwan applications
 
 draft-authors-lpwan-schc-802154-00.txt
 Date: 16/07/2018
 Authors: Joerg Robert, Charles Perkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides guidelines for creating Rules for Static Context Header Compression for IEEE 802.15.4. Since 802.15.4 provides layer-2 acknowledgements, some complexities that were designed for more general systems can be avoided.
    
draft-ayers-low-power-interop-00.txt
 Design Considerations For Low Power Internet Protocols
 
 draft-ayers-low-power-interop-00.txt
 Date: 29/06/2018
 Authors: Hudson Ayers, Paul Crews, Hubert Teo, Conor McAvity, Amit Levy, Philip Levis
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses guidelines for specifying low-power Internet protocols in order to improve implementation interoperability. These guidelines are based around the importance of balancing memory usage and energy efficiency, and the importance of not relying on Postel's law when dealing with low resource devices. This document applies these guidelines to the IPv6 over low-power wireless personal area networks (6LoWPAN) Internet Standard, suggesting changes that would make it more likely for implementations to interoperate.
    
draft-azgin-icnrg-mobility-00.txt
 DMS: Dynamic Inter- and Intra-Domain Mobility Support Framework for Information Centric Networking
 
 draft-azgin-icnrg-mobility-00.txt
 Date: 02/07/2018
 Authors: Aytac Azgin, Ravi Ravindran
 Working Group: Individual Submissions (none)
 Formats: xml txt
The objective of this proposal is to introduce a mobility support framework for information centric networking (ICN) that is capable of supporting dynamic mobility scenarios associated with both consumer and producer applications, in a mobile device connected to a wireless LAN or WAN point of attachment (PoA). Due to rapidly evolving user trends that shift towards increased mobility and increased access to mobile content delivery (as both content producer and consumer), it is essential for an ICN architecture to offer active mobility support to end hosts, and present them with varying degrees of quality of experience. We enable this through the use of a network-driven mobility support architecture, which operates in a distributed and anchorless manner, and relies on late-binding and in--band signaling with the use of forwarding labels.
    
draft-azimov-sidrops-aspa-profile-00.txt
 A Profile for Autonomous System Provider Authorization
 
 draft-azimov-sidrops-aspa-profile-00.txt
 Date: 28/06/2018
 Authors: Alexander Azimov, Eugene Uskov, Randy Bush, Keyur Patel, Job Snijders, Russ Housley
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a standard profile for Autonomous System Provider Authorization in the Resource Public Key Infrastructure. An Autonomous System Provider Authorization is a digitally signed object that provides a means of verifying that a Customer Autonomous System holder has authorized a Provider Autonomous System to be its upstream provider and for the Provider to send prefixes received from the Customer Autonomous System in all directions including providers and peers.
    
draft-azimov-sidrops-aspa-verification-00.txt
 Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization
 
 draft-azimov-sidrops-aspa-verification-00.txt
 Date: 28/06/2018
 Authors: Alexander Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Job Snijders
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the AS_PATH attribute of routes advertised in the Border Gateway Protocol.
    
draft-baba-iot-interconnection-00.txt
 Study Report on a Framework for Cloud Inter-connection toward the Realization of IoT
 
 draft-baba-iot-interconnection-00.txt
 Date: 02/07/2018
 Authors: Hiroyuki BABA, Izaya Miyake, Jun Matsumura, Yoshiki Ishida
 Working Group: Individual Submissions (none)
 Formats: xml txt
This paper describes issues for solutions through cloud inter- connection to structural problems, which are called as "silo effects" found in cloud-connected electric home appliances, housing equipment and sensors in the face of increasingly accelerated connection of them. Specifically, this paper explains an inter-connection agreement considered to be required for enhancement of cloud inter- connection, what performance guarantee as well as IoT supervising and management should be, necessity of inter-connection HUB which is able to provide inter-connection amongst the preponderance of private cloud groups.
    
draft-baba-iot-problems-05.txt
 Problems in and among industries for the prompt realization of IoT and safety considerations
 
 draft-baba-iot-problems-05.txt
 Date: 01/05/2018
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Koichi KUNITAKE, Kaoru Maeda
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document contains opinions gathered from enterprises engaging in the IoT business as stated in the preceding version hereof, and also examines the possibilities of new social problems in the IoT era. Recognition of the importance of information security has grown in step with the rising use of the Internet. Closer examination reveals that the IoT era may see a new direct physical threat to users. For instance, the situation at a smart house may lead it to judge that the owner has only temporarily stepped out, causing it to unlock the front door, which in turn makes it easier for thieves to enter. These kinds of scenarios may occur without identity fraud, hacking, and other means of compromising information security. Therefore, for the purpose of this document, this issue shall be referred to as "IoT Safety" to distinguish it from Information Security. We believe that it is necessary to deepen our understanding of these new IoT-related threats through discussion and ensure there are measures to address these threats in the future. At the same time, we must also coordinate these measures with the solutions to the problems described in the previous version of this document.
    
draft-baba-iot-webapi-03.txt
 Report on Problem Solving Experiment for Realization of Web-API-based IoT
 
 draft-baba-iot-webapi-03.txt
 Date: 01/05/2018
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Hiroshi Masuda, Shintaro Ogura, Koichi KUNITAKE
 Working Group: Individual Submissions (none)
 Formats: xml txt
The University of Tokyo (UOT) is currently performing a demonstration experiment in COMMA House, the experimental smart-house owned by UOT and used as a connected house. The things installed in the house (Things) are operated using applications on smartphones and other devices. The various Things in the smart-house are operated online via a Web API that has been created as a prototype. This report is an overview of the experimental demonstration, which is gradually clarifying that Web API should be effective for solving issues for IoT.
    
draft-balarajah-bmwg-ngfw-performance-04.txt
 Benchmarking Methodology for Network Security Device Performance
 
 draft-balarajah-bmwg-ngfw-performance-04.txt
 Date: 02/07/2018
 Authors: Balamuhunthan Balarajah, Carsten Rossenhoevel
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides benchmarking terminology and methodology for next-generation network security devices including next-generation firewalls (NGFW), intrusion detection and prevention solutions (IDS/ IPS) and unified threat management (UTM) implementations. The document aims to strongly improve the applicability, reproducibility and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 application use cases. The main areas covered in this document are test terminology, traffic profiles and benchmarking methodology for NGFWs to start with.
    
draft-banghart-mile-rolie-discovery-00.txt
 ROLIE Discovery Mechanism
 
 draft-banghart-mile-rolie-discovery-00.txt
 Date: 05/03/2018
 Authors: Stephen Banghart, David Waltermire
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a mechanism that allows consistent discovery of ROLIE repositories. This discovery is extremely important for automated tools that cannot use out-of-band Service Document discovery. Any human operators are also able to use this mechanism to avoid relying on inconsistent human to human communication. This document updates the ROLIE core specification.
    
draft-baraq-roll-drizzle-00.txt
 Drizzle Algorithm
 
 draft-baraq-roll-drizzle-00.txt
 Date: 23/03/2018
 Authors: Baraq Ghaleb, Ahmed Al-Dubai, Imed Romdhani, Mamoun Qasem
 Working Group: Individual Submissions (none)
 Formats: txt
Trickle algorithm used in RPL routing protocol suffers from some issues related to power, network convergence time and overhead and load-distribution. To optimize this algorithm for Low-power and Lossy Networks (LLNs), a new algorithm called Drizzle is introduced. Drizzle uses an adaptive suppression mechanism that permits the nodes to have different transmission probabilities, which are consistent with their transmission history. Compared to Trickle, Drizzle removes the listen-only period from Drizzle's intervals, thus, leading to faster convergence time. Furthermore, a new policy for setting the redundancy coefficient has been used to mitigate the negative effect of the short-listen problem presented when removing the listen-only period and to further boost the fairness in the network.
    
draft-barkai-lisp-nfv-12.txt
 LISP Based FlowMapping for Scaling NFV
 
 draft-barkai-lisp-nfv-12.txt
 Date: 18/06/2018
 Authors: Sharon Barkai, Dino Farinacci, David Meyer, Fabio Maino, Vina Ermagan, Alberto Rodriguez-Natal, Albert Cabellos-Aparicio
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes an RFC 6830 Locator ID Separation Protocol (LISP) based distributed flow-mapping-fabric for dynamic scaling of virtualized network functions (NFV). Network functions such as subscriber-management, content-optimization, security and quality of service, are typically delivered using proprietary hardware appliances embedded into the network as turn-key service-nodes or service-blades within routers. Next generation network functions are being implemented as pure software instances running on standard servers - unbundled virtualized components of capacity and functionality. LISP-SDN based flow-mapping, dynamically assembles these components to whole solutions by steering the right traffic in the right sequence to the right virtual function instance.
    
draft-barnes-acme-token-challenge-02.txt
 ACME Token Identifier and Challenges
 
 draft-barnes-acme-token-challenge-02.txt
 Date: 05/03/2018
 Authors: Mary Barnes
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an identifier and challenge type required to enable the Automated Certificate Management Environment (ACME) to issue certificates using a token for the challenge response. This token is issued by a administrative authority with whom the Certification Authority (CA) has a trust relationship. The entity requesting a certificate also has a relationship with the administrative authority, such that the administrative authority assigns a unique code to the entity. This entity code is included as part of the token that the administrative authority issues.
    
draft-barnes-mls-protocol-01.txt
 The Messaging Layer Security (MLS) Protocol
 
 draft-barnes-mls-protocol-01.txt
 Date: 02/07/2018
 Authors: Richard Barnes, Jon Millican, Emad Omara, Katriel Cohn-Gordon, Raphael Robert
 Working Group: Individual Submissions (none)
 Formats: xml txt
Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.
    
draft-barnes-stir-passport-div-hi-callflows-01.txt
 Session Initiation Protocol (SIP) Call Flow Examples with PASSporT Diversion and History-Info
 
 draft-barnes-stir-passport-div-hi-callflows-01.txt
 Date: 02/07/2018
 Authors: Mary Barnes
 Working Group: Individual Submissions (none)
 Formats: txt
This document focuses on use cases and call flows which include the History-Info header field and a SIP Identity header field with a PASSport with a "div" claim in cases of retargeting. These use cases are derived from those provided in the SIP History-Info call flows document. The objective is to describe the optimal way to correlate the History-Info header fields with a PASSporT with diversion information to increase the level of confidence in the History-Info header field by the terminating entity making use of the information.
    
draft-barnes-tls-pake-04.txt
 Usage of PAKE with TLS 1.3
 
 draft-barnes-tls-pake-04.txt
 Date: 16/07/2018
 Authors: Richard Barnes, Owen Friel
 Working Group: Individual Submissions (none)
 Formats: xml txt
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3.
    
draft-barre-mptcp-tfo-03.txt
 TFO support for Multipath TCP
 
 draft-barre-mptcp-tfo-03.txt
 Date: 29/05/2018
 Authors: Sebastien Barre, Gregory Detal, Olivier Bonaventure, Christoph Paasch
 Working Group: Individual Submissions (none)
 Formats: txt xml
TCP Fast Open (TFO) is a TCP extension that allows sending data in the SYN, instead of waiting until the TCP connection is established. This document describes what parts of Multipath TCP must be adapted to support it, and how TFO and MPTCP can operate together.
    
draft-barth-pce-segment-routing-policy-cp-00.txt
 PCEP extension to support Segment Routing Policy Candidate Paths
 
 draft-barth-pce-segment-routing-policy-cp-00.txt
 Date: 18/06/2018
 Authors: Colby Barth, Mike Koldychev, Dhruv Dhody, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a mechanism to specify an SR policy, as a collection of SR candidate paths. An SR policy is identified by tuple. An SR policy can be associated with one or more candidate paths where each candidate path is represented in PCEP by an LSP. This document proposes extension to PCEP to support association among candidate paths of a given SR policy. The mechanism proposed in this document is applicable to both MPLS and IPv6 data plane.
    
draft-bashandy-isis-srv6-extensions-03.txt
 IS-IS Extensions to Support Routing over IPv6 Dataplane
 
 draft-bashandy-isis-srv6-extensions-03.txt
 Date: 29/06/2018
 Authors: Les Ginsberg, Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu
 Working Group: Individual Submissions (none)
 Formats: txt xml
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane.
    
draft-bashandy-rtgwg-segment-routing-ti-lfa-04.txt
 Topology Independent Fast Reroute using Segment Routing
 
 draft-bashandy-rtgwg-segment-routing-ti-lfa-04.txt
 Date: 02/04/2018
 Authors: Ahmed Bashandy, Clarence Filsfils, Bruno Decraene, Stephane Litkowski, Pierre Francois, daniel.voyer@bell.ca
 Working Group: Routing Area Working Group (rtgwg)
 Formats: txt
This document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any IGP network. A key aspect of TI-LFA is the FRR path selection approach establishing protection over post-convergence paths from the point of local repair, dramatically reducing the operational need to control the tie-breaks among various FRR options.
    
draft-bashandy-rtgwg-segment-routing-uloop-03.txt
 Loop avoidance using Segment Routing
 
 draft-bashandy-rtgwg-segment-routing-uloop-03.txt
 Date: 02/04/2018
 Authors: Ahmed Bashandy, Clarence Filsfils, Stephane Litkowski, Pierre Francois
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination.
    
draft-bellis-dnsext-multi-qtypes-06.txt
 DNS Multiple QTYPEs
 
 draft-bellis-dnsext-multi-qtypes-06.txt
 Date: 02/07/2018
 Authors: Ray Bellis
 Working Group: Domain Name System Operations (dnsop)
 Formats: xml txt
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query.
    
draft-bellis-dnsop-xpf-04.txt
 DNS X-Proxied-For
 
 draft-bellis-dnsop-xpf-04.txt
 Date: 05/03/2018
 Authors: Ray Bellis, Peter van Dijk, Remi Gacogne
 Working Group: Individual Submissions (none)
 Formats: txt xml
It is becoming more commonplace to install front end proxy devices in front of DNS servers to provide (for example) load balancing or to perform transport layer conversions. This document defines a meta resource record that allows a DNS server to receive information about the client's original transport protocol parameters when supplied by trusted proxies.
    
draft-belyavskiy-certificate-limitation-policy-06.txt
 Certificate Limitation Policy
 
 draft-belyavskiy-certificate-limitation-policy-06.txt
 Date: 28/05/2018
 Authors: Dmitry Belyavsky
 Working Group: Individual Submissions (none)
 Formats: xml txt
The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself.
    
draft-benhadjsaid-detnet-gptp-yang-00.txt
 YANG Model of IEEE 802.1AS
 
 draft-benhadjsaid-detnet-gptp-yang-00.txt
 Date: 29/03/2018
 Authors: Siwar Sad, Michael Boc
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a YANG data model for the management of IEEE 802.1AS module in network devices. This data model includes configuration data and state data (status information and counters for the collection of statistics).
    
draft-berger-manet-dlep-ether-credit-extension-00.txt
 DLEP IEEE 802.1Q Aware Credit Window Extension
 
 draft-berger-manet-dlep-ether-credit-extension-00.txt
 Date: 01/05/2018
 Authors: David Wiggins, Lou Berger
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an extension to the DLEP protocol that enables a Ethernet IEEE 802.1Q aware credit-window scheme for destination- specific and shared flow control.
    
draft-bernardos-nfvrg-multidomain-04.txt
 Multi-domain Network Virtualization
 
 draft-bernardos-nfvrg-multidomain-04.txt
 Date: 05/03/2018
 Authors: Carlos Bernardos, Luis Contreras, Ishan Vaishnavi, Robert Szabo, Xi Li, Francesco Paolucci, Andrea Sgambelluri, Barbara Martini, Luca Valcarenghi, Giada Landi, Dmitriy Andrushko, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the problem of multi-provider multi-domain orchestration, by first scoping the problem, then looking into potential architectural approaches, and finally describing the solutions being developed by the European 5GEx and 5G-TRANSFORMER projects.
    
draft-bernardos-nfvrg-vim-discovery-00.txt
 IPv6-based discovery and association of Virtualization Infrastructure Manager (VIM) and Network Function Virtualization Orchestrator (NFVO)
 
 draft-bernardos-nfvrg-vim-discovery-00.txt
 Date: 05/03/2018
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Virtualized resources do not need to be limited to those available in traditional data centers, where the infrastructure is stable, static, typically homogeneous and managed by a single admin entity. Computational capabilities are becoming more and more ubiquitous, with terminal devices getting extremely powerful, as well as other types of devices that are close to the end users at the edge (e.g., vehicular onboard devices for infotainment, micro data centers deployed at the edge, etc.). It is envisioned that these devices would be able to offer storage, computing and networking resources to nearby network infrastructure, devices and things (the fog paradigm). These resources can be used to host functions, for example to offload/complement other resources available at traditional data centers, but also to reduce the end-to-end latency or to provide access to specialized information (e.g., context available at the edge) or hardware. This document describes mechanisms allowing dynamic discovery of virtualization resources and orchestrators in IPv6-based networks. New IPv6 neighbor discovery options are defined.
    
draft-bernardos-sfc-discovery-00.txt
 Service Function discovery in fog environments
 
 draft-bernardos-sfc-discovery-00.txt
 Date: 05/03/2018
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. Service functions provide an specific treatment of received packets, therefore they need to be known so they can be used in a given service composition via SFC. This document discusses the need for service function discovery mechanisms and propose some solutions for sfc-aware nodes to discover available service functions in fog environments.
    
draft-bernardos-sfc-fog-ran-03.txt
 Service Function Chaining Use Cases in Fog RAN
 
 draft-bernardos-sfc-fog-ran-03.txt
 Date: 05/03/2018
 Authors: Carlos Bernardos, Akbar Rahman, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Fog Radio Access Networks (RAN) refers to the part of the RAN that is virtualized at the very edge of the network, even at the end-user device. Fog RAN support is considered critical for the 5G mobile network architectures currently being developed in various research, standardization and industry forums. Since fog RAN builds on top of virtualization and can involve several virtual functions running on different virtualized resources, Service function chaining (SFC) support for the fog RAN will be critical. This document describes the overall fog RAN approach and also gives some use cases. Finally it proposes some requirements to be considered in the development of the SFC architecture and related protocols.
    
draft-bertola-dns-openid-pidi-architecture-01.txt
 An Architecture for a Public Identity Infrastructure Based on DNS and OpenID Connect
 
 draft-bertola-dns-openid-pidi-architecture-01.txt
 Date: 14/03/2018
 Authors: Vittorio Bertola, Marcos Sanz
 Working Group: Individual Submissions (none)
 Formats: txt xml
The following document describes an architecture for an open, global, federated Public Identity Infrastructure (PIDI), based on the Domain Name System (DNS) and on the OpenID Connect framework built over the OAuth protocol.
    
draft-bertz-dime-policygroups-06.txt
 Diameter Policy Groups and Sets
 
 draft-bertz-dime-policygroups-06.txt
 Date: 18/06/2018
 Authors: Lyle Bertz, Mark Bales
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines optional Diameter attributes for efficient policy provisioning.
    
draft-bertz-dime-predictunits-04.txt
 Diameter Predicted Units
 
 draft-bertz-dime-predictunits-04.txt
 Date: 18/06/2018
 Authors: Lyle Bertz
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the conveyance of predicted usage information for proper dimensioning of network services that use Diameter based authorization.
    
draft-bhattacharyya-dice-less-on-coap-01.txt
 Lightweight Establishment of Secure Session (LESS) on CoAP
 
 draft-bhattacharyya-dice-less-on-coap-01.txt
 Date: 04/03/2018
 Authors: Abhijan Bhattacharyya, Tulika Bose, Arijit Ukil, Soma Bandyopadhyay, Arpan Pal
 Working Group: Individual Submissions (none)
 Formats: txt
Secure yet lightweight protocol for communication over the Internet for constrained node networks (CNN) is a pertinent problem. Constrained Application Layer Protocol (CoAP) mandates the use of Datagram Transport Layer Security (DTLS) for a secure transaction over CoAP. But DTLS is not a candidate technology for CNNs by design. The DTLS handshake overhead to establish the credentials for a session between two end-points in a CNN may not be resource efficient. There are ongoing efforts to secure one-time exchanges by ensuring object security at the application layer. But a composite standardized mechanism for resource-efficient end-to-end security credential establishment is much needed to cater both one-time exchanges as well as exchanges over a session. DTLS is essentially a combination of two operations: (1) the session protocol to establish the credentials (and this is the resource heavy part), (2) the record protocol to protect the information (this is the cryptographic part). This draft proposes to distribute the security responsibilities such that the session establishment happens in the application layer, leveraging the lightweight semantics of CoAP, and the record layer encryption happens by reusing the existing DTLS record-layer protocol. This way the proposed mechanism enables a resource-efficient session establishment mechanism besides reusing the existing DTLS encryption. Assuming a Pre-Shared Key (PSK) environment, this draft proposes an embedding of handshake for resource efficient end-to-end session establishment into CoAP. The session establishment procedure produces the necessary and sufficient inputs for seamless operation of the DTLS record-layer to secure the channel. Also, this mechanism ensures a direct security association between the end-applications for systems using middleboxes like proxies and/or gateways which may not be always trusted. The proposed approach provides a mechanism to securely traverse through such middleboxes through an end-to-end trusted channel.
    
draft-bhjl-x509-srv-04.txt
 Using a DNS SRV Record to Locate an X.509 Certificate Store
 
 draft-bhjl-x509-srv-04.txt
 Date: 16/07/2018
 Authors: Brian Haberman, John Levine
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a method to allow parties to locate X.509 certificate stores with Domain Name System Service records in order to retrieve certificates and certificate revocation lists. The primary purpose of such retrievals is to facilitate the association of X.509 and PGP public keys with e-mail addresses to allow for encrypted e-mail exchanges.
    
draft-bi-savi-wlan-15.txt
 A SAVI Solution for WLAN
 
 draft-bi-savi-wlan-15.txt
 Date: 28/06/2018
 Authors: Jun Bi, Jianping Wu, You Wang, Tao Lin
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP packets to bind IP address to MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI(Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another.
    
draft-birk-pep-02.txt
 pretty Easy privacy (pEp): Privacy by Default
 
 draft-birk-pep-02.txt
 Date: 26/06/2018
 Authors: Volker Birk, Hernani Marques, Shelburn
 Working Group: Individual Submissions (none)
 Formats: xml txt
Building on already available security formats and message transports (like PGP/MIME for email), and with the intention to stay interoperable to systems widespreadly deployed, pretty Easy privacy (pEp) describes protocols to automatize operations (key management, key discovery, private key handling including peer-to-peer synchronization of private keys and other user data across devices) that have been seen to be barriers to deployment of end-to-end secure interpersonal messaging. pEp also relies on "Trustwords" (as a word mapping of of fingerprints) to verify communication peers and proposes a trust rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. In this document, the general design choices and principles of pEp are outlined.
    
draft-birk-pep-trustwords-02.txt
 IANA Registration of Trustword Lists: Guide,Template and IANA Considerations
 
 draft-birk-pep-trustwords-02.txt
 Date: 26/06/2018
 Authors: Volker Birk, Hernani Marques, Bernie Hoeneisen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the IANA Registration Guidelines for Trustwords, describes corresponding registration procedures, and provides a guideline for creating Trustword list specifications. Trustwords are common words in a natural language (e.g., English) to which the hexadecimal strings are mapped to. This makes verification processes (e.g., comparison of fingerprints), more practical and less prone to misunderstandings.
    
draft-birkholz-attestation-terminology-02.txt
 Reference Terminology for Remote Attestation Procedures
 
 draft-birkholz-attestation-terminology-02.txt
 Date: 02/07/2018
 Authors: Henk Birkholz, Monty Wiseman, Hannes Tschofenig
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is intended to illustrate and remediate the impedance mismatch of terms related to remote attestation procedures used in different domains today. New terms defined by this document provide a consolidated basis to support future work on attestation procedures in the IETF and beyond.
    
draft-birkholz-core-coid-00.txt
 Concise Identities
 
 draft-birkholz-core-coid-00.txt
 Date: 02/07/2018
 Authors: Henk Birkholz, Carsten Bormann, Max Pritikin, Robert Moskowitz
 Working Group: Individual Submissions (none)
 Formats: txt
There is an increased demand of trustworthy claim sets -- a set of system entity characteristics tied to an entity via signatures -- in order to provide information. Claim sets represented via CBOR Web Tokens (CWT) can compose a variety of evidence suitable for constrained-node networks and to support secure device automation. This document focuses on sets of identifiers and attributes that are tied to a system entity and are typically used to compose identities appropriate for Constrained RESTful Environment (CoRE) authentication needs.
    
draft-birkholz-i2nsf-tuda-03.txt
 Time-Based Uni-Directional Attestation
 
 draft-birkholz-i2nsf-tuda-03.txt
 Date: 02/05/2018
 Authors: Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo documents the method and bindings used to conduct time- based uni-directional attestation between distinguishable endpoints over the network.
    
draft-birkholz-reference-ra-interaction-model-00.txt
 Reference Interaction Model for Challenge-Response-based Remote Attestation
 
 draft-birkholz-reference-ra-interaction-model-00.txt
 Date: 02/07/2018
 Authors: Henk Birkholz, Michael Eckel
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an interaction model for a basic remote attestation procedure. Additionally, the required information elements are illustrated.
    
draft-birkholz-sacm-yang-content-01.txt
 YANG subscribed notifications via SACM Statements
 
 draft-birkholz-sacm-yang-content-01.txt
 Date: 18/01/2018
 Authors: Henk Birkholz, Nancy Cam-Winget
 Working Group: Individual Submissions (none)
 Formats: txt
This document summarizes a subset of the emerging generic SACM Data Model for inter-component distribution of SACM Content in and between SACM Domains. The subset defined in this document is covering every information element that can be acquired using YANG based protocols, i.e. NETCONF, RESTCONF, COMI or derived mechanisms that transfer YANG modeled data, such as MUD. As subscriptions to data origins in a SACM domain are one of the architectural corner-stones of the SACM architecture, this document recommends the use of YANG Push, YANG subscribed Notifications and corresponding Notification Headers and Bundles. Analogously, a mapping of Notification Header content to SACM Metadata is provided in this document.
    
draft-birkholz-suit-coswid-manifest-00.txt
 A SUIT Manifest Extension for Concise Software Identifiers
 
 draft-birkholz-suit-coswid-manifest-00.txt
 Date: 17/07/2018
 Authors: Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a resource extension for Concise Software Identifiers (CoSWID) that represents a SUIT firmware manifest. This extension combines the information elements of the SUIT information model with the semantic expressiveness of Software Identifiers. In consequence, this composite enables the integration of Firmware Updates for the Internet of Things (SUIT) in existing work-flows for updates of software components in general.
    
draft-birkholz-yang-basic-remote-attestation-00.txt
 YANG Module for Basic Challenge-Response-based Remote Attestation Procedures
 
 draft-birkholz-yang-basic-remote-attestation-00.txt
 Date: 02/07/2018
 Authors: Henk Birkholz, Michael Eckel, Shwetha Bhandari, Bill Sulzen, Eric Voit, Guy Fedorkow
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines YANG RPC and a minimal datastore required to retrieve integrity evidence about software from the device running the YANG datastore. The module presented requires a TPM 2.0 and corresponding Trusted Software Stack included in the system entity the YANG datastore is running on.
    
draft-birkholz-yang-core-telemetry-01.txt
 Concise YANG Telemetry
 
 draft-birkholz-yang-core-telemetry-01.txt
 Date: 16/07/2018
 Authors: Henk Birkholz, Eric Voit
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines CoAP operations that implement the capabilities of YANG Datastore Subscriptions and YANG Customized Subscriptions for the CoAP Management Interface (CoMI). The '/s' resource, as defined in CoMI, is extended analogously to include a set of sub-resources, each of them representing an observable resource identified by its subscription-id. Specific additions include but are not limited to new FETCH Body definitions and simplified subtree subscriptions to intermediate data nodes in YANG datastore modules using SID.
    
draft-birkholz-yang-swid-01.txt
 YANG module for Software Identifiers
 
 draft-birkholz-yang-swid-01.txt
 Date: 02/05/2018
 Authors: Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides a YANG module definition that enables a computing context to provide detailed information about installed software components. The structure of the module is based on the Concise Software Identifier draft and therefore also strongly related to the ISO 19770-2:2015 Software Identifiers standard. Both standards provide no interface to transport the SWID tag information between system entities and this document leverages the wide adoption of YANG based management interfaces.
    
draft-birrane-dtn-adm-03.txt
 AMA Application Data Model
 
 draft-birrane-dtn-adm-03.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a physical data model that captures the information necessary to asynchronously manage applications. This model provides a set of common type definitions, data structures, and a template for publishing standardized representations of model elements.
    
draft-birrane-dtn-adm-agent-04.txt
 Asynchronous Management Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-agent-04.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an Application Data Model (ADM) for an Asynchronous Management Protocol (AMP) Agent. The AMP Agent represents a managed device in the Asynchronous Management Architecture. This document is in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-bp-02.txt
 Bundle Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-bp-02.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Application Data Model (ADM) for a Bundle Protocol Agent (BPA) in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-bpsec-01.txt
 Bundle Protocol Security Application Data Model
 
 draft-birrane-dtn-adm-bpsec-01.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Application Data Model (ADM) for the Bundle Protocol Security (BPSEC) in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ion-bpadmin-00.txt
 Bundle Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-ion-bpadmin-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the administration of Bundle Protocol (BP) ION in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ion-ipnadmin-00.txt
 ION Application Data Model
 
 draft-birrane-dtn-adm-ion-ipnadmin-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the configuration of the routing of bundles to ipn endpoint ID scheme conformant endpoints from a local ION node. provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ion-ltpadmin-00.txt
 ION Licklider Transmission Protocol Admin Application Data Model
 
 draft-birrane-dtn-adm-ion-ltpadmin-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the configuration of licklider transmission protocol (LTP) in ION in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ionadmin-00.txt
 ION Administration Application Data Model
 
 draft-birrane-dtn-adm-ionadmin-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the administration of ION in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ionsec-00.txt
 ION Security Application Data Model
 
 draft-birrane-dtn-adm-ionsec-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for ION Security in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ltp-00.txt
 Licklider Transmission Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-ltp-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Application Data Model (ADM) for a Licklider Transmission Protocol Agent (LTPA) in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-ama-07.txt
 Asynchronous Management Architecture
 
 draft-birrane-dtn-ama-07.txt
 Date: 24/06/2018
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an asynchronous management architecture (AMA) suitable for providing application-level network management services in a challenged networking environment. Challenged networks are those that require fault protection, configuration, and performance reporting while unable to provide humans-in-the-loop with synchronous feedback or otherwise preserve transport-layer sessions. In such a context, networks must exhibit behavior that is both determinable and autonomous while maintaining compatibility with existing network management protocols and operational concepts.
    
draft-birrane-dtn-amp-05.txt
 Asynchronous Management Protocol
 
 draft-birrane-dtn-amp-05.txt
 Date: 02/07/2018
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a binary encoding of the Asynchronous Management Model (AMM) and a protocol for the exchange of these encoded items over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing network management on resource constrained devices.
    
draft-birrane-dtn-ampmgr-sql-01.txt
 AMP Manager SQL Interface
 
 draft-birrane-dtn-ampmgr-sql-01.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko, Mark Sinkiat
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a proposed public interface through which an application, such as a network management console, interacts with an Asynchronous Management Protocol (AMP) Manager via a database supporting the Structured Query Language (SQL). The use of SQL as an interfacing layer provides a natural way to describe interactions with an AMP Manager independent of a particular implementation of either the Manager or the application. Specifically, this document presents a database schema capturing how to send controls to a Manager and how to accept reports received by a Manager from one or more AMP Agents.
    
draft-birrane-dtn-bpsec-interop-cs-02.txt
 BPSec Interoperability Cipher Suites
 
 draft-birrane-dtn-bpsec-interop-cs-02.txt
 Date: 02/07/2018
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a set of integrity and confidentiality cipher suites suitable for testing the interoperability of Bundle Protocol Security (BPSec) implementations.
    
draft-bishop-httpbis-grease-00.txt
 GREASE for HTTP/2
 
 draft-bishop-httpbis-grease-00.txt
 Date: 24/05/2018
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: txt xml
Reserves several values in the HTTP/2 registries to exercise the requirement that clients and servers ignore unknown values.
    
draft-bishop-httpbis-priority-placeholder-01.txt
 Priority Placeholders in HTTP/2
 
 draft-bishop-httpbis-priority-placeholder-01.txt
 Date: 07/02/2018
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: txt xml
RFC7540 defines HTTP/2, including a method for communicating priorities. Some implementations have begun using closed streams as placeholders when constructing their priority tree, but this has unbounded state commitments and interacts poorly with HTTP/QUIC. This document proposes an extension to the HTTP/2 priority scheme for both protocols.
    
draft-bishop-httpbis-push-cases-00.txt
 HTTP/2 Server Push Use Cases
 
 draft-bishop-httpbis-push-cases-00.txt
 Date: 29/06/2018
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: xml txt
HTTP/2 defines the wire mechanics of Server Push. Though the mechanics of how a pushed resource is delivered are well-specified, the use cases that describe which resources can be pushed, in what states, and for what purpose are not described in HTTP/2. As a result, support between implementations varies widely. This document attempts to enumerate interesting scenarios, in hopes that a more concrete taxonomy can assist the community in arriving at a standard set of supported scenarios.
    
draft-bishop-httpbis-sni-altsvc-02.txt
 The "SNI" Alt-Svc Parameter
 
 draft-bishop-httpbis-sni-altsvc-02.txt
 Date: 24/05/2018
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: txt xml
HTTP Alternative Services provides a mechanism for an origin to declare that its content is accessible via some other combination of host, port, and protocol. In the process of using such an alternative, an observer can identify that the client is requesting resources from a particular hostname. This document extends HTTP Alternative Services, in combination with Secondary Certificate Authentication, to enable clients not to disclose the origin to which they intend to connect.
    
draft-bng-radext-virtual-nas-for-dnas-02.txt
 Virtual NAS (vNAS) Support for DNAS
 
 draft-bng-radext-virtual-nas-for-dnas-02.txt
 Date: 04/06/2018
 Authors: Raghunadha Pocha, Chandrashekhar Jamadarkhani, Satyanarayana Danda, Nishad M, Nagappa Chinnannavar
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines a framework for interacting North bound (AAA/Policy) servers of the Client resides in Cloud and/or Distributed Network environment with High-Availability to achieve fewer use-cases. First, NAS Client resides in Cloud or Virtualized or Distributed Network Access System to perform Authorization, Authentication and Accounting procedures with AAA Servers. Second, AAAA/Policy Servers provide dynamic policy information for subscribers of supporting in NAS Clients resides in Cloud or Virtualized or Distributed Network environment. Finally, Handling of Accounting related issues in better way for subscribers supported in Cloud or Virtualized or Distributed Network environment under High- Available conditions.
    
draft-bogineni-dmm-optimized-mobile-user-plane-01.txt
 Optimized Mobile User Plane Solutions for 5G
 
 draft-bogineni-dmm-optimized-mobile-user-plane-01.txt
 Date: 29/06/2018
 Authors: Kalyani Bogineni, Arashmid Akhavain, Tom Herbert, Dino Farinacci, Alberto Rodriguez-Natal, Giovanna Carofiglio, Jordan Auge, Luca Muscariello, Pablo Camarillo, Shunsuke Homma
 Working Group: Individual Submissions (none)
 Formats: txt
3GPP CT4 has approved a study item to study different mobility management protocols for potential replacement of GTP tunnels between UPFs (N9 Interface) in the 3GPP 5G system architecture. This document provides an overview of 5G system architecture in the context of N9 Interface which is the scope of the 3GPP CT4 study item [CP-173160-1], [TS.23.501-3GPP], [TS.23.502-3GPP], [TS.23.503-3GPP], [TS.29.244-3GPP], [TS.29.281-3GPP], [TS.38.300-3GPP], and [TS.38.401-3GPP]. Architecture requirements for evaluation of candidate protocols are provided. Optimization of the user plane can be in different ways - packet overhead, transport integration, etc. Several IETF protocols are considered for comparison: SRv6, LISP, ILA and several combinations of control plane and user plane protocols.
    
draft-bonica-6man-unrecognized-opt-01.txt
 The IPv6 Unrecognized Option
 
 draft-bonica-6man-unrecognized-opt-01.txt
 Date: 08/06/2018
 Authors: Ron Bonica, John Leddy
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a method by which a source node can determine whether the underlying network can a) convey a packet that contains IPv6 destination options from itself to a destination node, and b) convey an ICMPv6 Parameter Problem message in the reverse direction. In order to support this method, this document defines a new IPv6 option, called the Unrecognized option. The Unrecognized option is not recognized by any destination node and always elicits an ICMPv6 Parameter Problem message.
    
draft-bonica-6man-vpn-dest-opt-00.txt
 The IPv6 Virtual Private Network (VPN) Context Information Option
 
 draft-bonica-6man-vpn-dest-opt-00.txt
 Date: 11/06/2018
 Authors: Ron Bonica, Chris Lenart, Greg Presbury
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a new IPv6 Destination Option that can be used to encode Virtual Private Network (VPN) context information. It is applicable when VPN payload is transported over IPv6.
    
draft-bonica-intarea-frag-fragile-02.txt
 IP Fragmentation Considered Fragile
 
 draft-bonica-intarea-frag-fragile-02.txt
 Date: 11/06/2018
 Authors: Ron Bonica, Fred Baker, Geoff Huston, Robert Hinden, Ole Troan, Fernando Gont
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides an overview of IP fragmentation. It explains how IP fragmentation works and why it is required. As part of that explanation, this document also explains how IP fragmentation reduces the reliability of Internet communication. This document also proposes alternatives to IP fragmentation. Finally, it provides recommendations for application developers and network operators.
    
draft-bormann-cbor-cddl-freezer-00.txt
 A feature freezer for the Concise Data Definition Language (CDDL)
 
 draft-bormann-cbor-cddl-freezer-00.txt
 Date: 27/01/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document collects nice-to-have features that did not make it into the first RFC for CDDL.
    
draft-bormann-core-ace-aif-05.txt
 An Authorization Information Format (AIF) for ACE
 
 draft-bormann-core-ace-aif-05.txt
 Date: 18/01/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
Constrained Devices as they are used in the "Internet of Things" need security. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, need to ascertain that the authorization to request the operation does apply to the actual requester, and need to ascertain that other devices they place requests on are the ones they intended. On the ACE mailing list, an activity to create specifications for such authenticated authorization for constrained devices is contemplated, leading to protocol proposals such as [I-D.ietf-ace-dtls-authorize] or [I-D.seitz-ace-oscoap-profile]. One potential work item complementing this protocol work is an Authorization Information Format (AIF). This document provides a strawman for such a format that should enable further discussion of the objectives for its development.
    
draft-bormann-core-proactive-ct-00.txt
 Proactively Assigning CoAP Content-Format Numbers to Registered Media Types
 
 draft-bormann-core-proactive-ct-00.txt
 Date: 02/07/2018
 Authors: Carsten Bormann, Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
In order to use a media type with the Constrained Application Protocol (CoAP), a numeric identifier needs to be registered for it, the Content-Format number. RFC 7252 defines registration procedures for Content-Format numbers. The present document defines a proactive procedure to register a Content-Format number for many of the media types that are registered and discusses the benefits and limitations of that approach.
    
draft-bormann-lpwan-cbor-template-02.txt
 Concise Binary Object Representation (CBOR) Tag for CBOR Templates
 
 draft-bormann-lpwan-cbor-template-02.txt
 Date: 16/01/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document makes use of this extensibility to define a CBOR tag for a variable within a CBOR data item, which then could be filled in by a separate process (e.g., from another CBOR data item).
    
draft-bormann-lwig-7228bis-03.txt
 Terminology for Constrained-Node Networks
 
 draft-bormann-lwig-7228bis-03.txt
 Date: 02/07/2018
 Authors: Carsten Bormann, Mehmet Ersue, Ari Keranen, Carles Gomez
 Working Group: Individual Submissions (none)
 Formats: txt
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.
    
draft-bormann-t2trg-rel-impl-00.txt
 impl-info: A link relation type for disclosing implementation information
 
 draft-bormann-t2trg-rel-impl-00.txt
 Date: 28/01/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
When debugging an interoperability problem, it is often helpful to have information about the implementation version of a peer. To enable the disclosure of such information, HTTP defines header fields such as Server and User-Agent. In CoAP, it is rarely appropriate to send information of this kind in every request or response. Instead, the present specification defines a link relation type, impl-info, that can be used to convey this information via the self-description capabilities of the /.well- known/core resource and the CoRE resource directory.
    
draft-bormann-t2trg-slipmux-02.txt
 Slipmux: Using an UART interface for diagnostics,configuration,and packet transfer
 
 draft-bormann-t2trg-slipmux-02.txt
 Date: 17/01/2018
 Authors: Carsten Bormann, Tobias Kaupat
 Working Group: Individual Submissions (none)
 Formats: txt
Many research and maker platforms for Internet of Things experimentation offer a serial interface. This is often used for programming, diagnostic output, as well as a crude command interface ("AT interface"). Alternatively, it is often used with SLIP (RFC1055) to transfer IP packets only. The present report describes how to use a single serial interface for diagnostics, configuration commands and state readback, as well as packet transfer.
    
draft-bormann-t2trg-stp-01.txt
 The Series Transfer Pattern (STP)
 
 draft-bormann-t2trg-stp-01.txt
 Date: 02/07/2018
 Authors: Carsten Bormann, Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
Many applications make use of Series of data items, i.e., an array of data items where new items can be added over time. Where such Series are to be made available using REST protocols such as CoAP or HTTP, the Series has to be mapped into a structure of one or more resources and a protocol for a client to obtain the Series and to learn about new items. Various protocols have been standardized that make Series-shaped data available, with rather different properties and objectives. The present document is an attempt to extract a common underlying pattern and to define media types and an access scheme that can be used right away for further protocols that provide Series-shaped data.
    
draft-bortzmeyer-dname-root-05.txt
 Using DNAME in the DNS root zone for sinking of special-use TLDs
 
 draft-bortzmeyer-dname-root-05.txt
 Date: 17/01/2018
 Authors: Stephane Bortzmeyer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This documents asks IANA to add DNAME records in the DNS root zone for TLDs which are in the Special-Use Domain Names registry, in order to ensure they receive an appropriate reply (NXDOMAIN) and that the root nameservers are not too bothered by them. REMOVE BEFORE PUBLICATION: there is no obvious place to discuss this document. May be the IETF DNSOP (DNS Operations) group, through its mailing list (the author reads it). Or may AS112 operators mailing lists? The source of the document, as well as a list of open issues, is currently kept at Github [1].
    
draft-bortzmeyer-dprive-resolver-to-auth-01.txt
 Encryption and authentication of the DNS resolver-to-authoritative communication
 
 draft-bortzmeyer-dprive-resolver-to-auth-01.txt
 Date: 20/03/2018
 Authors: Stephane Bortzmeyer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a mechanism for securing (privacy-wise) the communication between the DNS resolver and the authoritative name server. REMOVE BEFORE PUBLICATION: this document should be discussed in the IETF DPRIVE group, through its mailing list. The source of the document, as well as a list of open issues, is currently kept at Github [1].
    
draft-bortzmeyer-dprive-rfc7626-bis-01.txt
 DNS Privacy Considerations
 
 draft-bortzmeyer-dprive-rfc7626-bis-01.txt
 Date: 16/07/2018
 Authors: Stephane Bortzmeyer, Sara Dickinson
 Working Group: DNS PRIVate Exchange (dprive)
 Formats: txt
This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions.
    
draft-bortzmeyer-regext-epp-dname-02.txt
 EPP Mapping for DNAME delegation of domain names
 
 draft-bortzmeyer-regext-epp-dname-02.txt
 Date: 19/03/2018
 Authors: Stephane Bortzmeyer
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide the ability to delegate a domain names through DNAME resource records, thus making the new domain an alias of a previous domain. REMOVE BEFORE PUBLICATION This document should be discussed on the Registration Protocols Extensions (regext) mailing list. The source of this document is kept on a Gitlab at Framagit [1]. A list of open issues is there as well [2].
    
draft-bortzmeyer-rfc7816bis-00.txt
 DNS Query Name Minimisation to Improve Privacy
 
 draft-bortzmeyer-rfc7816bis-00.txt
 Date: 17/07/2018
 Authors: Stephane Bortzmeyer, Paul Hoffman
 Working Group: Domain Name System Operations (dnsop)
 Formats: txt
This document describes a technique to improve DNS privacy, a technique called "QNAME minimisation", where the DNS resolver no longer sends the full original QNAME to the upstream name server. RFC EDITOR: PLEASE REMOVE BEFORE PUBLICATION. The original [RFC7816] had the experimental status. This document is intended for the standards track. It should be discussed in the IETF DNSOP (DNS Operations) Working Group, through its mailing list. The source of the document, as well as a list of open issues, is currently kept at Framagit [1].
    
draft-boucadair-dots-multihoming-03.txt
 Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)
 
 draft-boucadair-dots-multihoming-03.txt
 Date: 09/04/2018
 Authors: Mohamed Boucadair, Tirumaleswar Reddy
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses multi-homing considerations for Distributed- Denial-of-Service Open Threat Signaling (DOTS). The goal is to provide a set of guidance for DOTS clients/gateways when multihomed.
    
draft-boucadair-dots-server-discovery-04.txt
 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server Discovery
 
 draft-boucadair-dots-server-discovery-04.txt
 Date: 09/04/2018
 Authors: Mohamed Boucadair, Tirumaleswar Reddy, Prashanth Patil
 Working Group: Individual Submissions (none)
 Formats: txt xml
It may not be possible for a network to determine the cause for an attack, but instead just realize that some resources seem to be under attack. To fill that gap, Distributed-Denial-of-Service Open Threat Signaling (DOTS) allows a network to inform a DOTS server that it is under a potential attack so that appropriate mitigation actions are undertaken. This document specifies mechanisms to configure nodes with DOTS servers.
    
draft-boucadair-ipsecme-ipv6-ipv4-codes-02.txt
 IKEv2 Notification Codes for IPv4/IPv6 Coexistence
 
 draft-boucadair-ipsecme-ipv6-ipv4-codes-02.txt
 Date: 07/05/2018
 Authors: Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies new IKEv2 notification codes to better manage IPv4 and IPv6 co-existence.
    
draft-boucadair-lisp-bulk-07.txt
 LISP Mapping Bulk Retrieval
 
 draft-boucadair-lisp-bulk-07.txt
 Date: 03/04/2018
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document extends Locator/ID Separation Protocol (LISP) with a capability for bulk mapping retrieval. It does so by defining new LISP messages that are meant to facilitate state recovery of mapping tables and improve Ingress Tunnel Routers (ITR) recovery times, in particular. Unlike base LISP, these new messages are transported over TCP. In addition, this document allows to request mappings that match destination IP prefixes, names, or AS numbers.
    
draft-boucadair-radext-tcpm-converter-00.txt
 RADIUS Extensions for 0-RTT TCP Converters
 
 draft-boucadair-radext-tcpm-converter-00.txt
 Date: 03/04/2018
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: xml txt
Because of the lack of Multipath TCP (MPTCP) support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called Converters. Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attributes that carry the IP addresses that will be returned to authorized users to reach one or multiple Converters.
    
draft-boucadair-tcpm-dhc-converter-00.txt
 DHCP Options for 0-RTT TCP Converters
 
 draft-boucadair-tcpm-dhc-converter-00.txt
 Date: 03/04/2018
 Authors: Mohamed Boucadair, Christian Jacquenet, Tirumaleswar Reddy
 Working Group: Individual Submissions (none)
 Formats: txt xml
Because of the lack of Multipath TCP (MPTCP) support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called Converters. Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document focuses on the explicit deployment scheme where the identity of the Converters is explicitly configured on connected hosts. This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Converters parameters.
    
draft-bourbaki-6man-classless-ipv6-03.txt
 IPv6 is Classless
 
 draft-bourbaki-6man-classless-ipv6-03.txt
 Date: 17/03/2018
 Authors: Nicolas Bourbaki
 Working Group: Individual Submissions (none)
 Formats: txt
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing.
    
draft-boutros-bess-evpn-geneve-02.txt
 EVPN control plane for Geneve
 
 draft-boutros-bess-evpn-geneve-02.txt
 Date: 01/03/2018
 Authors: Sami Boutros, Ali Sajassi, John Drake, Jorge Rabadan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how Ethernet VPN (EVPN) control plane can be used with Network Virtualization Overlay over Layer 3 (NVO3) Generic Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 solutions. EVPN control plane can also be used by a Network Virtualization Endpoints (NVEs) to express Geneve tunnel option TLV(s)supported in transmission and/or reception of Geneve encapsulated data packets.
    
draft-boutros-nvo3-geneve-applicability-for-sfc-01.txt
 Geneve applicability for service function chaining
 
 draft-boutros-nvo3-geneve-applicability-for-sfc-01.txt
 Date: 01/03/2018
 Authors: Sami Boutros, Dharma Rajan, Philip Kippen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of using Generic Network Virtualization Encapsulation (Geneve), to carry the service function path (SFP) information, and the network service header (NSH) encapsulation. The SFP information will be carried in Geneve option TLV(s).
    
draft-brandt-imap-replace-03.txt
 IMAP REPLACE Extension
 
 draft-brandt-imap-replace-03.txt
 Date: 30/06/2018
 Authors: Stuart Brandt
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an IMAP extension which can be used to replace an existing message in a message store with a new message. Message replacement is a common operation for clients that automatically save drafts or notes as a user composes them.
    
draft-briscoe-tsvwg-l4s-diffserv-01.txt
 Interactions between Low Latency,Low Loss,Scalable Throughput (L4S) and Differentiated Services
 
 draft-briscoe-tsvwg-l4s-diffserv-01.txt
 Date: 02/07/2018
 Authors: Bob Briscoe
 Working Group: Individual Submissions (none)
 Formats: txt xml
L4S and Diffserv offer somewhat overlapping services (low latency and low loss), but bandwidth allocation is out of scope for L4S. Therefore there is scope for the two approaches to complement each other, but also to conflict. This informational document explains how the two approaches interact, how they can be arranged to complement each other and in which cases one can stand alone without needing the other.
    
draft-brissette-bess-evpn-l2gw-proto-01.txt
 EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols
 
 draft-brissette-bess-evpn-l2gw-proto-01.txt
 Date: 26/02/2018
 Authors: Patrice Brissette, Ali Sajassi, Luc Burdet, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
Existing EVPN multi-homing load-balancing modes are limited to Single-Active and All-Active. Neither of these multi-homing mechanisms are sufficient to support access networks with Layer-2 Gateway protocols such as MST-AG, REP-AG, and G.8032. These Layer-2 Gateway protocols require a new multi-homing mechanism defined in this draft.
    
draft-brissette-bess-evpn-mh-pa-01.txt
 EVPN multi-homing port-active load-balancing
 
 draft-brissette-bess-evpn-mh-pa-01.txt
 Date: 28/02/2018
 Authors: Patrice Brissette, Samir Thoria, Ali Sajassi
 Working Group: Individual Submissions (none)
 Formats: txt
The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables the establishment of a logical port-channel connection with a redundant group of independent nodes. The purpose of multi-chassis LAG is to provide a solution to achieve higher network availability, while providing different modes of sharing/balancing of traffic. EVPN standard defines EVPN based MC-LAG with single-active and all-active multi-homing load-balancing mode. The current draft expands on existing redundancy mechanisms supported by EVPN and introduces support of port-active load-balancing mode. In the current draft, port-active load-balancing mode is also referred to as per interface active/standby.
    
draft-brockners-ippm-ioam-geneve-01.txt
 Geneve encapsulation for In-situ OAM Data
 
 draft-brockners-ippm-ioam-geneve-01.txt
 Date: 27/06/2018
 Authors: Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, David Mozes, Petr Lapukhov, Remy Chang
 Working Group: Individual Submissions (none)
 Formats: xml txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in Geneve.
    
draft-brockners-ippm-ioam-vxlan-gpe-01.txt
 VXLAN-GPE Encapsulation for In-situ OAM Data
 
 draft-brockners-ippm-ioam-vxlan-gpe-01.txt
 Date: 27/06/2018
 Authors: Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Aviv Kfir, Barak Gafni, Petr Lapukhov, Mickey Spiegel
 Working Group: Individual Submissions (none)
 Formats: xml txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in VXLAN-GPE.
    
draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-01.txt
 Elliptic curve 2y^2=x^3+x over field size 8^91+5
 
 draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-01.txt
 Date: 13/04/2018
 Authors: Dan Brown
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a special elliptic curve with complex multiplication (by i) and a compact description (see title). This curve is recommended for cryptographic use in a strongest-link combination with dissimilar elliptic curves (e.g. NIST P-256, Curve25519, extension-field curves, etc.) as a defense in depth against an unlikely, unforeseen attack on otherwise preferred elliptic curves. The curve equation 2y^2=x^3+x is the Montgomery form of a curve y^2=x^3-x in a class of curves y^2=x^3-ax suggested by Miller in the first published paper elliptic curve cryptography, and an endomorphism usable for efficiency, an idea of Koblitz. The field size 8^91+5 is prime, and is relatively efficient and compactly described for its bit-size (273 bits). The document specifies some practical details such as: encoding a point (on the curve) into 34 bytes, public key validation, encoding a private key into 34 bytes, and encoding 34 bytes into a point. The document also provides pseudocode, motivation, and security considerations.
    
draft-brown-whoami-02.txt
 WHOAMI: A Method For Identifying a Domain Operator's Contact Information
 
 draft-brown-whoami-02.txt
 Date: 01/06/2018
 Authors: Gavin Brown
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a method by which the operator of a domain may publish their contact information in a discoverable and machine- readable format.
    
draft-browne-sfc-nsh-kpi-stamp-03.txt
 Network Service Header KPI Stamping
 
 draft-browne-sfc-nsh-kpi-stamp-03.txt
 Date: 05/03/2018
 Authors: Rory Browne, Andrey Chilikin, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a method of inserting Key Performance Indicators (KPIs) into Network Service Header (NSH) encapsulated packets or frames on service chains. This method may be used to monitor latency and QoS configuration to identify problems with virtual links (vlinks), Virtual Network Functions (VNFs) or Physical Network Functions (PNFs) on the Rendered Service Path (RSP).
    
draft-brunstrom-taps-impl-00.txt
 Implementing Interfaces to Transport Services
 
 draft-brunstrom-taps-impl-00.txt
 Date: 05/03/2018
 Authors: Anna Brunstrom, Tommy Pauly, Theresa Enghardt, Karl-Johan Grinnemo, Tom Jones, Philipp Tiesel, Colin Perkins, Michael Welzl
 Working Group: Individual Submissions (none)
 Formats: txt
The Transport Services architecture [I-D.pauly-taps-arch] defines a system that allows applications to use transport networking protocols flexibly. This document serves as a guide to implementation on how to build such a system.
    
draft-bryant-detnet-mpls-dp-00.txt
 Operation of Deterministic Networks over MPLS
 
 draft-bryant-detnet-mpls-dp-00.txt
 Date: 05/03/2018
 Authors: Stewart Bryant, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies Deterministic Networking data plane operation over an MPLS Packet Switched Networks. This document is a derivative work from draft-ietf-detnet-dp-sol-01. Whether this is published as a stand-alone text, or serves as a focal point to refine the MPLS design and the key point are subsequently re-merged with draft-ietf-detnet-dp-sol-01 is a matter for the DETNET WG, as is the editorship of any WG text.
    
draft-bryskin-netconf-automation-yang-02.txt
 Generalized Network Control Automation YANG Model
 
 draft-bryskin-netconf-automation-yang-02.txt
 Date: 29/06/2018
 Authors: Igor Bryskin, Xufeng Liu, Alexander Clemm, Henk Birkholz, Tianran Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG data model for the Generalized Network Control Automation (GNCA), aimed to define an abstract and uniform semantics for NETCONF/YANG scripts in the form of Event-Condition- Action (ECA) containers.
    
draft-burger-sipcore-rejected-00.txt
 A Session Initiation Protocol (SIP) Response Code for Rejected Calls
 
 draft-burger-sipcore-rejected-00.txt
 Date: 16/07/2018
 Authors: Eric Burger
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This document defines the 608 (Rejected) SIP response code. This response code enables calling parties to learn their call was rejected by an intermediary and will not be answered. As a 6xx code, the caller will be aware that future attempts to contact the same UAS will be likely to fail. The present use case driving the need for the 608 response code is when the intermediary is an analytics engine. In other words, the rejection is by a machine or other process, as opposed to a human at the target UAS indicating the call was not wanted. This document also defines the use of the Call-Info header in 608 responses to enable rejected callers to contact entities that blocked their calls in error.
    
draft-burger-stir-iana-cert-00.txt
 Registry for Country-Specific Secure Telephone Identity (STIR) Root Certificates
 
 draft-burger-stir-iana-cert-00.txt
 Date: 05/03/2018
 Authors: Eric Burger
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document defines an IANA registry that maps country codes to secure telephone identity (STIR) root certificates authorized to create signing certificates for telephone numbers under the authority of a given country. Some countries allow carriers to block unsolicited, automatically generated nuisance calls commonly known as 'robocalls.' The use of signed STIR tokens in the Session Initiation Protocol (SIP) may be useful in such scenarios to provide positive attestations as to call origin. Legacy telephone numbering resources are administrated by national policy. Unlike the market-driven use case of Web commerce, some nations may restrict the list of STIR root certificate authorities acceptable for issuing signing certificates for STIR tokens that provide attestations for their local legacy telephone numbering resources. The registry described in this document enables call recipients in a first country to validate that signaling it receives from a caller with a telephone number claiming to be in a second country conforms to the second country's policy of (1) having a limited list of STIR root certificate authorities (or not) and (2) the certificate that produced the signature over the signaling is signed by one of those authorized STIR root certificate authorities.
    
draft-burleigh-dtn-bibect-01.txt
 Bundle-in-Bundle Encapsulation
 
 draft-burleigh-dtn-bibect-01.txt
 Date: 20/05/2018
 Authors: Scott Burleigh
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes Bundle-in-Bundle Encapsulation (BIBE), a Delay-Tolerant Networking (DTN) Bundle Protocol (BP) "convergence layer" protocol that tunnels BP "bundles" through encapsulating bundles. The services provided by the BIBE convergence-layer protocol adapter encapsulate an outbound BP "bundle" in a BIBE convergence-layer protocol data unit for transmission as the payload of a bundle. Security measures applied to the encapsulating bundle may augment those applied to the encapsulated bundle. The protocol includes a mechanism for recovery from loss of an encapsulating bundle, called "custody transfer". This mechanism is adapted from the custody transfer procedures described in the experimental Bundle Protocol specification developed by the Delay-Tolerant Networking Research group of the Internet Research Task Force and documented in RFC 5050.
    
draft-burleigh-dtnwg-dtka-01.txt
 Architecture for Delay-Tolerant Key Administration
 
 draft-burleigh-dtnwg-dtka-01.txt
 Date: 02/03/2018
 Authors: Scott Burleigh, David Horres, Kapali Viswanathan, michael.w.benson@boeing.com, Fred Templin
 Working Group: Individual Submissions (none)
 Formats: txt xml
Delay-Tolerant Key Administration (DTKA) is a system of public-key management protocols intended for use in Delay Tolerant Networking (DTN). This document outlines a DTKA proposal for space-based communications, which are characterized by long communication delays and planned communication contacts.
    
draft-busi-pals-pw-cw-stitching-00.txt
 Pseudowire (PW) Control Word (CW) Stitching
 
 draft-busi-pals-pw-cw-stitching-00.txt
 Date: 02/07/2018
 Authors: Italo Busi, Stewart Bryant, Andrew Malis, Jie Dong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the behavior of a new type of Multi-Segment Pseudowire (MS-PW) Switching PE (S-PE) which enhances the S-PE functions defined in [RFC 6073], with the capability to switch an Ethernet pseudowire (PW) segment that uses the PW Control Word (CW) [RFC 4385] with an Ethernet PW segment that does not use the CW. This new type of S-PE can be deployed in the network one hop away, at the MPLS layer, from a Terminating PE (T-PE) which does not support CW for Ethernet PW encapsulation [RFC 4448]. In this way, all the Ethernet PW packets sent though the MPLS network will have the CW and be protected against incorrect equal-cost-multi-path (ECMP) behavior as described in [I-D ETH-CW].
    
draft-bvtm-dhc-mac-assign-01.txt
 Link-Layer Addresses Assignment Mechanism for DHCPv6
 
 draft-bvtm-dhc-mac-assign-01.txt
 Date: 14/05/2018
 Authors: Bernie Volz, Tomek Mrugalski
 Working Group: Individual Submissions (none)
 Formats: txt xml
In certain environments, e.g. large scale virtualization deployments, new devices are created in an automated manner. Such devices typically have their link-layer (MAC) addresses randomized. With sufficient scale, the likelihood of collision is not acceptable. Therefore an allocation mechanism is required. This draft proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments.
    
draft-byrne-v6ops-dnssecaaaa-00.txt
 DNSSEC Resource Record Should Include AAAA
 
 draft-byrne-v6ops-dnssecaaaa-00.txt
 Date: 01/07/2018
 Authors: Cameron Byrne
 Working Group: Individual Submissions (none)
 Formats: txt
DNS64 is a widely deployed technology allowing hundreds of millions of IPv6-only hosts to reach IPv4-only resources. DNSSEC is a technology used to validate the authenticity of information in the DNS. Currently, there are scenarios where DNS64 and DNSSEC do not work well together. This document states that any DNSSEC signed resources record should include a native IPv6 resource record as the most complete and expedient path to solve any deployment conflict with DNS64 and DNSSEC.
    
draft-bz-v4goawayflag-00.txt
 IPv6 Router Advertisement IPv4 GoAway Flag
 
 draft-bz-v4goawayflag-00.txt
 Date: 31/03/2018
 Authors: Bjoern Zeeb
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a Router Advertisement Flag to indicate to end nodes that IPv4 support must be disabled on this link. In addition this document presents a policy and a timeline on how to deal with this flag and the going-away of IPv4. This document updates RFC5175.
    
draft-calconnect-vobject-i18n-00.txt
 vObject Internationalization
 
 draft-calconnect-vobject-i18n-00.txt
 Date: 07/06/2018
 Authors: Ronald Tse, Peter Tam, Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies mechanisms for the internationalization of vObject content and its realization in vFormat. This document updates the following specifications: o I-D.calconnect-vobject-vformat, The vObject Model and vFormat Syntax o RFC 6350, vCard version 4.0 o RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar) o RFC 7953, Calendar Availability Extensions This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.
    
draft-calconnect-vobject-integrity-01.txt
 Integrity Protection for vObject,vCard and iCalendar
 
 draft-calconnect-vobject-integrity-01.txt
 Date: 19/04/2018
 Authors: Ronald Tse, Peter Tam
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an integrity checking mechanism and related properties for: o vObject (I-D.calconnect-vobject-vformat) o vCard version 4 (vCard v4) (RFC 6350); and o iCalendar (Internet Calendaring and Scheduling Core Object Specification) (RFC 5545) This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.
    
draft-calconnect-vobject-vformat-04.txt
 The vObject Model and vFormat Syntax
 
 draft-calconnect-vobject-vformat-04.txt
 Date: 07/06/2018
 Authors: Ronald Tse, Peter Tam, Ken Murchison, Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the vObject data model and its corresponding syntax vFormat. vObject represents the generalized data model, and vFormat the generalized data format, of the following specifications and fully covers them: o RFC 6350, vCard version 4.0: the VCARD component; o RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar): the VCALENDAR, VEVENT, VJOURNAL, VFREEBUSY, VTIMEZONE, VALARM, VTODO, STANDARD and DAYLIGHT components; o RFC 7953, Calendar Availability Extensions: the VAVAILABILITY and AVAILABLE components; o I-Ddaboo-icalendar-vpatch, iCalendar Patching: the VPATCH component; and o alternative formats for iCalendar and vCard, including RFC 6321, xCal; RFC 7265, jCal; RFC 6351, xCard; and RFC 7095, jCard. This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.
    
draft-camarillo-dmm-srv6-mobile-pocs-00.txt
 Segment Routing IPv6 for mobile user-plane PoCs
 
 draft-camarillo-dmm-srv6-mobile-pocs-00.txt
 Date: 02/07/2018
 Authors: Pablo Camarillo, Clarence Filsfils, Lyle Bertz, Arashmid Akhavain, Satoru Matsushima, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the ongoing proof of concepts of [I-D.ietf-dmm-srv6-mobile-uplane] and their progress.
    
draft-camarilloelmalky-springdmm-srv6-mob-usecases-00.txt
 SRv6 Mobility Use-Cases
 
 draft-camarilloelmalky-springdmm-srv6-mob-usecases-00.txt
 Date: 15/07/2018
 Authors: Pablo Camarillo, Clarence Filsfils, Hani Elmalky, Dave Allan, Satoru Matsushima, daniel.voyer@bell.ca, Anna Cui, Bart Peirens
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the SRv6 use-cases in the mobile network in association with different mobile generations (3G, 4G, and 5G). It also highlights potential interworking with SR-MPLS in relevant use- cases.
    
draft-camelot-holy-grenade-01.txt
 The Holy Hand Grenade of Antioch
 
 draft-camelot-holy-grenade-01.txt
 Date: 15/04/2018
 Authors: Arthur Pendragon
 Working Group: Individual Submissions (none)
 Formats: xml txt
The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635.
    
draft-campbell-sip-messaging-smime-03.txt
 Securing Session Initiation Protocol (SIP) based Messaging with S/MIME
 
 draft-campbell-sip-messaging-smime-03.txt
 Date: 25/06/2018
 Authors: Ben Campbell, Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFC 3261, RFC 3428, and RFC 4975.
    
draft-camwinget-tls-ts13-macciphersuites-00.txt
 TLS 1.3 Authentication and Integrity only Ciphersuites
 
 draft-camwinget-tls-ts13-macciphersuites-00.txt
 Date: 28/06/2018
 Authors: Nancy Cam-Winget, Jack Visoky
 Working Group: Individual Submissions (none)
 Formats: xml txt
There are use cases, specifically in Internet of Things (IoT) and constrained environments that do not require confidentiality, though mutual authentication during tunnel establishment and message integrity is still mandated. This document defines the use of HMAC only as ciphersuites in TLS 1.3.
    
draft-camwinget-tls-use-cases-02.txt
 TLS 1.3 Impact on Network-Based Security
 
 draft-camwinget-tls-use-cases-02.txt
 Date: 02/07/2018
 Authors: Flemming Andreasen, Nancy Cam-Winget, Eric Wang
 Working Group: Individual Submissions (none)
 Formats: txt
Network-based security solutions are used by enterprises, public sector, and cloud service providers today in order to both complement and augment host-based security solutions. TLS 1.3 introduces several changes to TLS 1.2 with a goal to improve the overall security and privacy provided by TLS. However some of these changes have a negative impact on network-based security solutions. While this may be viewed as a feature, there are several real-life use case scenarios that are not easily solved without such network-based security solutions. In this document, we identify the TLS 1.3 changes that may impact network-based security solutions and provide a set of use case scenarios that are not easily solved without such solutions.
    
draft-carney-regext-domainconnect-03.txt
 Domain Connect API - Communications between DNS Provider and Services
 
 draft-carney-regext-domainconnect-03.txt
 Date: 18/01/2018
 Authors: Arnold Blinn, rcarney@godaddy.com
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides information related to the Domain Connect API that was built to support communications between DNS Providers and Service Providers (hosting, social, email, hardware, etc.).
    
draft-carpenter-6man-lap-01.txt
 The Longest Acceptable Prefix for IPv6 Links
 
 draft-carpenter-6man-lap-01.txt
 Date: 19/06/2018
 Authors: Brian Carpenter
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the concepts of a Longest Acceptable Prefix (LAP) and a Shortest Acceptable Identifier Length (SAIL) for an IPv6 link.
    
draft-carpenter-anima-asa-guidelines-05.txt
 Guidelines for Autonomic Service Agents
 
 draft-carpenter-anima-asa-guidelines-05.txt
 Date: 29/06/2018
 Authors: Brian Carpenter, Laurent Ciavaglia, Sheng Jiang, Peloso Pierre
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks. It is based on the Autonomic Network Infrastructure outlined in the ANIMA reference model, making use of the Autonomic Control Plane and the Generic Autonomic Signaling Protocol.
    
draft-carpenter-anima-grasp-bulk-02.txt
 Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP)
 
 draft-carpenter-anima-grasp-bulk-02.txt
 Date: 29/06/2018
 Authors: Brian Carpenter, Sheng Jiang, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes how bulk data may be transferred between Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol (GRASP).
    
draft-carpenter-limited-domains-01.txt
 Limited Domains and Internet Protocols
 
 draft-carpenter-limited-domains-01.txt
 Date: 30/06/2018
 Authors: Brian Carpenter, Sheng Jiang
 Working Group: Individual Submissions (none)
 Formats: txt xml
There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains and emerging solutions. It shows the needs for a precise definition of a limited domain boundary and for a corresponding protocol to allow nodes to discover where such a boundary exists.
    
draft-carpenter-request-for-comments-00.txt
 Request for Comments
 
 draft-carpenter-request-for-comments-00.txt
 Date: 05/06/2018
 Authors: Brian Carpenter
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses the Internet technical community's common document series.
    
draft-carrel-ipsecme-controller-ike-00.txt
 IPsec Key Exchange using a Controller
 
 draft-carrel-ipsecme-controller-ike-00.txt
 Date: 02/07/2018
 Authors: David Carrel, Brian Weis
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a key exchange method allowing devices managed by a controller (e.g., an SDN management station) to create private pair-wise IPsec SAs without IKEv2 or any other direct peer-to-peer session establishment messages.
    
draft-cavage-http-signatures-10.txt
 Signing HTTP Messages
 
 draft-cavage-http-signatures-10.txt
 Date: 15/05/2018
 Authors: Mark Cavage, Manu Sporny
 Working Group: Individual Submissions (none)
 Formats: txt xml
When communicating over the Internet using the HTTP protocol, it can be desirable for a server or client to authenticate the sender of a particular message. It can also be desirable to ensure that the message was not tampered with during transit. This document describes a way for servers and clients to simultaneously add authentication and message integrity to HTTP messages by using a digital signature.
    
draft-cbrt-pce-stateful-local-protection-01.txt
 PCEP Extensions for RSVP-TE Local-Protection with PCE-Stateful
 
 draft-cbrt-pce-stateful-local-protection-01.txt
 Date: 29/06/2018
 Authors: Colby Barth, Raveendra Torvi
 Working Group: Individual Submissions (none)
 Formats: xml txt
Stateful PCE [RFC8231] can apply global concurrent optimizations to optimize LSP placement. In a deployment where a PCE is used to compute all the paths, it may be beneficial for the local protection paths to also be computed by the PCE. This document defines extensions needed for the setup and management of RSVP-TE protection paths by the PCE.
    
draft-cc-isis-flooding-reduction-01.txt
 ISIS Flooding Reduction
 
 draft-cc-isis-flooding-reduction-01.txt
 Date: 29/04/2018
 Authors: Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an approach to flood ISIS link state protocol data units on a topology that is a subgraph of the complete ISIS topology per underline physical network, so that the amount of flooding traffic in the network is greatly reduced, and it would reduce convergence time with a more stable and optimized routing environment. The approach can be applied to any network topology in a single ISIS area.
    
draft-cc-ospf-flooding-reduction-02.txt
 OSPF Flooding Reduction
 
 draft-cc-ospf-flooding-reduction-02.txt
 Date: 02/07/2018
 Authors: Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an approach to flood OSPF link state advertisements on a topology that is a subgraph of the complete OSPF topology per underline physical network, so that the amount of flooding traffic in the network is greatly reduced, and it would reduce convergence time with a more stable and optimized routing environment. The approach can be applied to any network topology in a single OSPF area, and can be used in both OSPFv2 ([RFC2328]) network and OSPFv3 ([RFC5340]) network.
    
draft-cdn-loop-prevention-00.txt
 CDN Loop Prevention
 
 draft-cdn-loop-prevention-00.txt
 Date: 26/06/2018
 Authors: Stephen Ludin, Mark Nottingham, Nick Sullivan
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines the CDN-Loop request header field for HTTP.
    
draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
 Linux-related Extensions to NFS version 4.2 Security Labels
 
 draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
 Date: 10/04/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: xml txt
NFS version 4.2 introduces an optional feature known as NFSv4 Security Labels. This document extends NFSv4 Security Labels to support Linux file capabilities and the Linux Integrity Measurement Architecture.
    
draft-cel-nfsv4-reminv-design-08.txt
 Using Remote Invalidation With RPC-Over-RDMA Transports
 
 draft-cel-nfsv4-reminv-design-08.txt
 Date: 17/07/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
Remote Invalidation relieves RDMA responders of some of the burden of preparing memory to be accessed remotely, thus reducing the latency of RDMA Read and Write operations. This document considers how to introduce generic support for Remote Invalidation to RPC-over-RDMA transport protocols.
    
draft-cel-nfsv4-rpcrdma-cm-pvt-msg-03.txt
 RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1
 
 draft-cel-nfsv4-rpcrdma-cm-pvt-msg-03.txt
 Date: 19/03/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the format of RDMA-CM Private Data exchanged between RPC-over-RDMA version 1 peers as a transport connection is established. Such messages indicate peer support for Remote Invalidation and larger-than-default inline thresholds. The message format is extensible.
    
draft-cel-nfsv4-rpcrdma-reliable-reply-03.txt
 Improving the Performance and Reliability of RPC Replies on RPC-over-RDMA Transports
 
 draft-cel-nfsv4-rpcrdma-reliable-reply-03.txt
 Date: 16/07/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
RPC transports such as RPC-over-RDMA version 1 require reply buffers to be in place before an RPC Call is sent. However, RPC consumers sometimes have difficulty estimating the expected maximum size of a particular RPC reply. This introduces the risk that an RPC Reply message can overrun reply resources provided by the requester, preventing delivery of the message, through no fault of the requester. This document describes a mechanism that eliminates the need for pre-allocation of reply resources for unpredictably large replies.
    
draft-cel-nfsv4-rpcrdma-version-two-07.txt
 RPC-over-RDMA Version 2 Protocol
 
 draft-cel-nfsv4-rpcrdma-version-two-07.txt
 Date: 16/07/2018
 Authors: Chuck Lever, David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies an improved protocol for conveying Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA), based on RPC-over-RDMA version 1.
    
draft-chandra-mpls-rsvp-shared-labels-np-00.txt
 Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane
 
 draft-chandra-mpls-rsvp-shared-labels-np-00.txt
 Date: 02/07/2018
 Authors: Chandrasekar R, Vishnu Beeram, Harish Sitaraman
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routed RSVP-TE tunnels provide the ability to use a shared MPLS forwarding plane at every hop of the Label Switched Path (LSP). The shared forwarding plane is realized with the use of 'Traffic Engineering (TE) link labels' that get shared by LSPs traversing these TE links. This paradigm helps significantly reduce the forwarding plane state required to support a large number of LSPs on a Label Switching Router (LSR). These tunnels require the ingress Label Edge Router (LER) to impose a stack of labels. If the ingress LER cannot impose the full label stack, it can use the assistance of one or more delegation hops along the path of the LSP to impose parts of the label stack. The procedures for a Point of Local Repair (PLR) to provide local protection against link failures using facility backup for Segment Routed RSVP-TE tunnels are well defined and do not require specific protocol extensions. This document defines the procedures for a PLR to provide local protection against transit node failures using facility backup for these tunnels. The procedures defined in this document include protection against delegation hop failures.
    
draft-chang-6tisch-msf-02.txt
 6TiSCH Minimal Scheduling Function (MSF)
 
 draft-chang-6tisch-msf-02.txt
 Date: 02/07/2018
 Authors: Tengfei Chang, Malisa Vucinic, Xavier Vilajosana, Simon Duquennoy, Diego Dujovne
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH.
    
draft-chen-alto-survey-00.txt
 ALTO Implementations and Use Cases: A Brief Survey
 
 draft-chen-alto-survey-00.txt
 Date: 02/07/2018
 Authors: Shiwei Chen, Xiao Lin, Danny Perez, Yang Yang, Christian Rothenberg
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides a comprehensive survey of ALTO, including current ALTO implementations and ALTO used in the literature work. This document identifies possible challenges and future opportunities of ALTO.
    
draft-chen-ati-adaptive-ipv4-address-space-03.txt
 Adaptive IPv4 Address Space
 
 draft-chen-ati-adaptive-ipv4-address-space-03.txt
 Date: 10/06/2018
 Authors: Abraham Chen, Ramamurthy Ati, Abhay Karandikar
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. The EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, nor the current private networks. The EzIP is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivities, but also their interoperability. The EzIP deployment may coexist with the current Internet traffic and the IoT (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to choose either. If the IPv4 public pool allocations were allowed to be reorganized, the assignable pool could be multiplied by 512M times or even more. The EzIP may be implemented as a software / firmware enhancement to the Internet edge routers or private network routing gateways wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed herein establishes a complete sphere of routers for interfacing between the Internet core fabic and the end user premises. Incorporating the caching proxy technology in the gateway, a fairly large geographical area may enjoy an EzIP based sub-Internet operating from as few as one ordinary IPv4 public address. This will immediately resolve the IPv4 address shortage anywhere, while transparent to the current Internet operation. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording the IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.
    
draft-chen-bfd-unsolicited-02.txt
 Unsolicited BFD for Sessionless Applications
 
 draft-chen-bfd-unsolicited-02.txt
 Date: 30/01/2018
 Authors: Enke Chen, Naiming Shen, Robert Raszuk
 Working Group: Individual Submissions (none)
 Formats: txt
For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies).
    
draft-chen-bier-pce-bier-04.txt
 PCEP Extensions for BIER
 
 draft-chen-bier-pce-bier-04.txt
 Date: 06/02/2018
 Authors: Ran Chen, Zheng Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [I-D.ietf-bier-architecture]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies.BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) to handle requests and responses for the computation of paths for BIER-TE.
    
draft-chen-bier-rpcs-yang-00.txt
 YANG Data Model for BIER RPCs
 
 draft-chen-bier-rpcs-yang-00.txt
 Date: 11/02/2018
 Authors: Ran Chen, Min Gu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for BIER RPCs.
    
draft-chen-isis-black-hole-avoid-02.txt
 Avoiding Traffic Black-Holes for Route Aggregation in IS-IS
 
 draft-chen-isis-black-hole-avoid-02.txt
 Date: 05/03/2018
 Authors: Zhe Chen, Xiaohu Xu, Dean Cheng
 Working Group: Individual Submissions (none)
 Formats: xml txt
When the Intermediate System to Intermediate System (IS-IS) routing protocol is adopted by a highly symmetric network such as the Leaf- Spine or Fat-Tree network, the Leaf nodes (e.g., Top of Rack switches in datacenters) are recommended to be prevented from receiving other nodes' explicit routes in order to achieve scalability. However, such a setup would cause traffic black-holes or suboptimal routing if link failure happens in the network. This document introduces INFINITE cost to IS-IS LSPs to solve this problem.
    
draft-chen-isis-ias-lk-02.txt
 ISIS Extensions for Broadcast Inter-AS TE Link
 
 draft-chen-isis-ias-lk-02.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the ISIS protocol for advertising broadcast inter-AS Traffic Engineering (TE) links.
    
draft-chen-isis-sl-overheads-reduction-03.txt
 Overheads Reduction for IS-IS Enabled Spine-Leaf Networks
 
 draft-chen-isis-sl-overheads-reduction-03.txt
 Date: 05/03/2018
 Authors: Zhe Chen, Xiaohu Xu, Dean Cheng
 Working Group: Individual Submissions (none)
 Formats: txt xml
When a Spine-Leaf topology adopts the Intermediate System to Intermediate System (IS-IS) routing protocol, the Leaf node receives Link State Packets (LSPs) from all the other nodes thus having the entire routing information of the topology. This is usually considered unnecessary and costly. This document describes a solution to this problem by utilizing IS-IS's inherent multi-level and area partition features, which requires that an IS-IS router SHOULD check a level-1 LSP's area addresses before advertising it to a neighbor.
    
draft-chen-isis-ttz-05.txt
 IS-IS Topology-Transparent Zone
 
 draft-chen-isis-ttz-05.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Renwei Li, Alvaro Retana, Ning So, Vic liu, Mehmet Toy, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a topology-transparent zone in a domain. A zone comprises a group of routers and a number of circuits connecting them. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a circuit down inside the zone is not seen by any router outside of the zone.
    
draft-chen-ospf-abnormal-state-info-02.txt
 OSPF Abnormal State Information
 
 draft-chen-ospf-abnormal-state-info-02.txt
 Date: 05/03/2018
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain.
    
draft-chen-ospf-ias-lk-02.txt
 OSPF Extensions for Broadcast Inter-AS TE Link
 
 draft-chen-ospf-ias-lk-02.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Open Shortest Path First (OSPF) for advertising broadcast inter-AS Traffic Engineering (TE) links.
    
draft-chen-pce-bier-03.txt
 PCEP Extensions for BIER
 
 draft-chen-pce-bier-03.txt
 Date: 06/02/2018
 Authors: Ran Chen, Zheng Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [I-D.ietf-bier-architecture]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies.BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) to handle requests and responses for the computation of paths for BIER-TE.
    
draft-chen-pce-compute-backup-egress-13.txt
 Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path
 
 draft-chen-pce-compute-backup-egress-13.txt
 Date: 30/04/2018
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress.
    
draft-chen-pce-compute-backup-ingress-13.txt
 Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path
 
 draft-chen-pce-compute-backup-ingress-13.txt
 Date: 30/04/2018
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress.
    
draft-chen-pce-forward-search-p2mp-path-14.txt
 A Forward-Search P2MP TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2mp-path-14.txt
 Date: 30/04/2018
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described.
    
draft-chen-pce-forward-search-p2p-path-computation-15.txt
 A Forward-Search P2P TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2p-path-computation-15.txt
 Date: 30/04/2018
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described.
    
draft-chen-pce-h-connect-access-04.txt
 PCEP Link State Abstraction
 
 draft-chen-pce-h-connect-access-04.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a child PCE to abstract its domain information to its parent for supporting a hierarchical PCE system.
    
draft-chen-pce-h-discovery-04.txt
 Hierarchical PCE Determination
 
 draft-chen-pce-h-discovery-04.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for determining parent child relations and exchanging the information between a parent and a child PCE in a hierarchical PCE system.
    
draft-chen-pce-label-x-domains-08.txt
 Extensions to PCEP for Distributing Label Cross Domains
 
 draft-chen-pce-label-x-domains-08.txt
 Date: 30/04/2018
 Authors: Huaimo Chen, Autumn Liu, Fengman Xu, Mehmet Toy, Vic liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP).
    
draft-chen-pce-pcc-ted-04.txt
 Static PCEP Link State
 
 draft-chen-pce-pcc-ted-04.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to advertise the information about the links without running IGP and for a PCE to build a TED based on the information received.
    
draft-chen-pce-protection-applicability-12.txt
 The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks.
 
 draft-chen-pce-protection-applicability-12.txt
 Date: 30/04/2018
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE.
    
draft-cheng-spring-mpls-path-segment-02.txt
 Path Segment in MPLS Based Segment Routing Network
 
 draft-cheng-spring-mpls-path-segment-02.txt
 Date: 02/07/2018
 Authors: Weiqiang Cheng, Lei Wang, Han Li, Mach Chen, Royi Zigler, Shuangping Zhan, Rakesh Gandhi
 Working Group: Individual Submissions (none)
 Formats: txt
An SR path is identified by an SR segment list, one or partial segments of the list cannot uniquely identify the SR path. Path identification is the precondition of performance measurement (PM) of an SR path. This document introduces the concept of Path Segment that is used to identify an SR path. When used, it is inserted at the ingress node of the SR path and immediately follows the last segment of the SR path. The Path Segment will not be popped off until it reaches the egress of the SR path. Path segment can be used by the egress node to implement path identification hence to support SR path PM, end-2-end SR path protection and bidirectional SR paths correlation.
    
draft-cheshire-dnssd-roadmap-01.txt
 Service Discovery Road Map
 
 draft-cheshire-dnssd-roadmap-01.txt
 Date: 21/03/2018
 Authors: Stuart Cheshire
 Working Group: Extensions for Scalable DNS Service Discovery (dnssd)
 Formats: txt
Over the course of several years, a rich collection of technologies has developed around DNS-Based Service Discovery, described across multiple documents. This "Road Map" document gives an overview of how these related but separate technologies (and their documents) fit together, to facilitate service discovery in various environments.
    
draft-cheshire-sudn-ipv4only-dot-arpa-10.txt
 Special Use Domain Name 'ipv4only.arpa'
 
 draft-cheshire-sudn-ipv4only-dot-arpa-10.txt
 Date: 02/07/2018
 Authors: Stuart Cheshire, David Schinazi
 Working Group: Individual Submissions (none)
 Formats: txt xml
The specification for how a client discovers its network's NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but declares it to be a non-special name in that specification's Domain Name Reservation Considerations section. Consequently, despite the well articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties. As a result of this omission, in cases where software needs to give this name special treatment in order for it to work correctly, there was no clear mandate authorizing software authors to implement that special treatment. Software implementers were left with the choice between not implementing the special behavior necessary for the name queries to work correctly, or implementing the special behavior and being accused of being noncompliant with some RFC. This document formally declares the actual special properties of the name, and adds similar declarations for the corresponding reverse mapping names.
    
draft-chodorek-tsvwg-rsvp-dynamic-resv-06.txt
 RSVP Extensions for Dynamic Reservation
 
 draft-chodorek-tsvwg-rsvp-dynamic-resv-06.txt
 Date: 13/05/2018
 Authors: Robert Chodorek, Agnieszka Chodorek
 Working Group: Individual Submissions (none)
 Formats: txt
RSVP reservations are static in nature and typically last for the whole session. The proposed extension to the RSVP allows the RSVP to make elastic adjustments to reservations for the current demand of network resources. The proposed method dynamically changes the RSVP reservations on the basis of knowledge about transmitted traffic.
    
draft-choi-anima-trust-networking-00.txt
 Trust networking and procedures for Autonomic Networking
 
 draft-choi-anima-trust-networking-00.txt
 Date: 02/07/2018
 Authors: Taesang Choi, Taesoo Chung, Junkyun Choi, Jaeseob Han, Woo Chun
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes trust networking as an application of autonomic networking. The objective of trustworthy autonomic networking is providing trust networking environment where all autonomic nodes can communicate without any security concern. It defines a trust networking domain and describes how to configure and maintain the trust networking domain. While communication within the trust networking domain is done with trust, the communication with external nodes should be done via a specific autonomic service agent (ASA) called "trust gateway". The trust gateway ASA performs trust evaluation of the external nodes and enforces domain specific policies to keep the domain trustworthy.
    
draft-chuang-bimi-certificate-00.txt
 Brand Indicator for Message Identification in X.509 certificates
 
 draft-chuang-bimi-certificate-00.txt
 Date: 07/05/2018
 Authors: Wei Chuang, Thede Loder
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a X.509 certificate profile to distinguish those carrying logotypes and using email domain based authentication from other usages.
    
draft-chunduri-idr-bgp-ls-nspfid-00.txt
 BGP Link-State extensions for NSPF ID
 
 draft-chunduri-idr-bgp-ls-nspfid-00.txt
 Date: 02/04/2018
 Authors: Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: txt
Non Shortest Paths (NSPs) used in routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. NSPs help to reduce the data plane path overhead, mitigate from MTU issues as well as performance related issues in certain data planes and allows granular traffic accounting in the network. NSPs are created locally by operator or can be provisioned through PCE or Yang from outside. This document describes a mechanism by which NSP information currently active in the network using the BGP routing protocol by defining extensions to BGP Link- state address-family.
    
draft-chunduri-isis-preferred-path-routing-00.txt
 Preferred Path Routing (PPR) in IS-IS
 
 draft-chunduri-isis-preferred-path-routing-00.txt
 Date: 18/06/2018
 Authors: Uma Chunduri, Richard Li, Russ White, Jeff Tantsura, Luis Contreras, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR) mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to IS-IS advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chunduri-lsr-isis-mt-deployment-cons-00.txt
 IS-IS Multi Topology Deployment Considerations
 
 draft-chunduri-lsr-isis-mt-deployment-cons-00.txt
 Date: 24/04/2018
 Authors: Uma Chunduri, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes IS-IS Multi Topology (MT) considerations in various deployments (Core/Mobile Backhaul/Data Center underlay). This document explores nuances around various IS-IS address families, topologies and considerations while choosing the right combination for a specific DC/mobile backhaul deployment.
    
draft-chunduri-lsr-isis-preferred-path-routing-01.txt
 Preferred Path Routing (PPR) in IS-IS
 
 draft-chunduri-lsr-isis-preferred-path-routing-01.txt
 Date: 02/07/2018
 Authors: Uma Chunduri, Renwei Li, Russ White, Jeff Tantsura, Luis Contreras, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR) mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to IS-IS advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chunduri-lsr-isis-prefix-multi-algo-00.txt
 Multiple Algorithm support for IS-IS Prefixes
 
 draft-chunduri-lsr-isis-prefix-multi-algo-00.txt
 Date: 17/04/2018
 Authors: Uma Chunduri, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an extension to Intermediate System to Intermediate System (IS-IS) protocol by adding an Algorithm support for prefixes advertised. This allows multiple independent algorithm usage for computing the reachability of nodes and prefixes as opposed to only one algorithm.
    
draft-chunduri-lsr-ospf-preferred-path-routing-01.txt
 Preferred Path Routing (PPR) in OSPF
 
 draft-chunduri-lsr-ospf-preferred-path-routing-01.txt
 Date: 02/07/2018
 Authors: Uma Chunduri, Yingzhen Qu, Russ White, Jeff Tantsura, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR) mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments with OSPFv2 and OSPFv3 protocols. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to OSPF advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chunduri-ospf-lsr-preferred-path-routing-00.txt
 Preferred Path Routing (PPR) in OSPF
 
 draft-chunduri-ospf-lsr-preferred-path-routing-00.txt
 Date: 18/06/2018
 Authors: Uma Chunduri, Yingzhen Qu, Russ White, Jeff Tantsura, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR) mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments with OSPFv2 and OSPFv3 protocols. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to OSPF advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chung-dtn-extension-prophet-icn-02.txt
 Extension of Probabilistic Routing Protocol using History of Encounters and Transitivity for Information Centric Network
 
 draft-chung-dtn-extension-prophet-icn-02.txt
 Date: 02/07/2018
 Authors: Yun Chung, Min Kang, Young-Han Kim
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes extension of probabilistic routing protocol using history of encounters and transitivity (PRoPHET) for information centric network.
    
draft-clacla-netmod-model-catalog-03.txt
 YANG module for yangcatalog.org
 
 draft-clacla-netmod-model-catalog-03.txt
 Date: 03/04/2018
 Authors: Joe Clarke, Benoit Claise
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a YANG module that contains metadata related to YANG modules and vendor implementations of those YANG modules.
    
draft-clacla-netmod-yang-model-update-06.txt
 New YANG Module Update Procedure
 
 draft-clacla-netmod-yang-model-update-06.txt
 Date: 02/07/2018
 Authors: Benoit Claise, Joe Clarke, Balazs Lengyel, Kevin D'Souza
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a new YANG module update procedure in case of backward-incompatible changes, as an alternative proposal to the YANG 1.1 specifications. This document updates RFC 7950.
    
draft-claise-semver-02.txt
 Semantic Versioning and Structure for IETF Specifications
 
 draft-claise-semver-02.txt
 Date: 17/01/2018
 Authors: Benoit Claise, Richard Barnes, Joe Clarke
 Working Group: Individual Submissions (none)
 Formats: txt
In the Internet engineering ecosystem, there is increasingly a need for specifications that evolve over time, and which are encoded directly in structured formats (e.g., YANG models). Internet-Drafts are a poor fit for working groups that want to produce structured specifications, and publishing versions of an evolving specification as RFC makes it difficult to track the specification over time. This document outlines recommendations for how working groups can provide consistent, meaningful versions for specifications over time and work directly on structured documents while still fitting within established IETF processes.
    
draft-clausen-lln-rpl-experiences-11.txt
 Observations on RPL: IPv6 Routing Protocol for Low power and Lossy Networks
 
 draft-clausen-lln-rpl-experiences-11.txt
 Date: 27/03/2018
 Authors: Thomas Clausen, Axel Verdiere, Jiazi Yi, Ulrich Herberg, Yuichi Igarashi
 Working Group: Individual Submissions (none)
 Formats: txt
With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - published as a Proposed Standard after a ~2-year development cycle, this document presents an observation of the resulting protocol, of its applicability, and of its limits. The documents presents a selection of observations on the protocol characteristics, exposes experiences acquired when producing various prototype implementations of RPL, and presents results obtained from testing this protocol - by way of network simulations, in network testbeds and in deployments. The document aims at providing a better understanding of possible limits of RPL, notably the possible directions that further protocol developments should explore, in order to address these.
    
draft-clemm-netmod-nmda-diff-00.txt
 Comparison of NMDA datastores
 
 draft-clemm-netmod-nmda-diff-00.txt
 Date: 12/06/2018
 Authors: Alexander Clemm, Yingzhen Qu, Jeff Tantsura, Andy Bierman
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an RPC operation to compare management datastores that comply with the NMDA architecture.
    
draft-clemm-netmod-push-smart-filters-00.txt
 Smart Filters for Push Updates
 
 draft-clemm-netmod-push-smart-filters-00.txt
 Date: 02/07/2018
 Authors: Alexander Clemm, Eric Voit, Xufeng Liu, Igor Bryskin, Tianran Zhou, Guangying Zheng, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG model for Smart Filters for push updates. Smart Filters allow to filter push updates based on values of pushed datastore nodes and/or state, such as previous updates. Smart Filters provide an important building block for service assurance and network automation. This revision of the document is intended as a placeholder, containing the problem statement of draft-clemm-netconf-push-smart- filters-ps-00 that has recently expired. The YANG model itself still needs to be defined.
    
draft-clemm-nmrg-dist-intent-01.txt
 Clarifying the Concepts of Intent and Policy
 
 draft-clemm-nmrg-dist-intent-01.txt
 Date: 18/07/2018
 Authors: Alexander Clemm, Laurent Ciavaglia, Lisandro Granville
 Working Group: Individual Submissions (none)
 Formats: xml txt
Intent and Intent-Based Networking are taking the industry by storm. At the same time, those terms are used loosely and often inconsistently, in many cases overlapping with other concepts such as "policy". This document is therefore intended to clarify the concept of "Intent" and how it relates to other concepts. The goal is to contribute towards a common and shared understanding of terms and concepts which can then be used as foundation to guide further definition of valid research and engineering problems and their solutions.
    
draft-cls-ppr-te-attributes-00.txt
 Resources for Preferred Path Routes in IGPs
 
 draft-cls-ppr-te-attributes-00.txt
 Date: 16/07/2018
 Authors: Uma Chunduri, Renwei Li, Kevin Smith
 Working Group: Individual Submissions (none)
 Formats: txt
Preferred Path Routing (PPR) is concerned with setting up the route for a given prefix as specified in the path description along with a corresponding data plane/forwarding identifier PPR-ID. This document specifies an extension to PPR, a mechanism to perform resource reservations nodes on Preferred Path Routes (PPR) for IGPs (IS-IS, OSPFv2, OSPFv3). This is done by specifying the resources that need to be reserved along the path using PPR path attributes.
    
draft-clt-dmm-tn-aware-mobility-01.txt
 Transport Network aware Mobility for 5G
 
 draft-clt-dmm-tn-aware-mobility-01.txt
 Date: 16/07/2018
 Authors: Uma Chunduri, Renwei Li, Jeff Tantsura, Luis Contreras, Xavier de Foy
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a framework and a mapping function for 5G mobile user plane with transport network slicing, integrated with Mobile Radio Access and a Virtualized Core Network. The integrated approach specified in a way to address all the mobility scenarios defined in [TS23.501] and to be backward compatible with LTE [TS.23.401-3GPP] network deployments. It focuses on an optimized mobile user plane functionality with various transport services needed for some of the 5G traffic needing low and deterministic latency, real-time, mission-critical services. This document describes, how this objective is achieved agnostic to the transport underlay used (IPv4, IPv6, MPLS) in various deployments and with a new transport network underlay routing, called Preferred Path Routing (PPR).
    
draft-coene-rserpool-applic-ipfix-19.txt
 Reliable Server Pooling Applicability for IP Flow Information Exchange
 
 draft-coene-rserpool-applic-ipfix-19.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Lode Coene, Phillip Conrad
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol.
    
draft-contreras-layered-sdn-02.txt
 Cooperating Layered Architecture for SDN
 
 draft-contreras-layered-sdn-02.txt
 Date: 02/07/2018
 Authors: Luis Contreras, Carlos Bernardos, Diego Lopez, Mohamed Boucadair, Paola Iovanna
 Working Group: Individual Submissions (none)
 Formats: txt xml
Software Defined Networking (SDN) proposes the separation of the control plane from the data plane in the network nodes and its logical centralization on a control entity. Most of the network intelligence is moved to this functional entity. Typically, such entity is seen as a compendium of interacting control functions in a vertical, tight integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that relies upon transport capabilities. This document describes a proposal named Cooperating Layered Architecture for SDN. The idea behind that is to differentiate the control functions associated to transport from those related to services, in such a way that they can be provided and maintained independently, and can follow their own evolution path.
    
draft-cremers-cfrg-randomness-improvements-00.txt
 Randomness Improvements for Security Protocols
 
 draft-cremers-cfrg-randomness-improvements-00.txt
 Date: 01/03/2018
 Authors: Cas Cremers, Luke Garratt, Stanislav Smyshlyaev, Nick Sullivan, Christopher Wood
 Working Group: Individual Submissions (none)
 Formats: txt
Randomness is a crucial ingredient for TLS and related security protocols. Weak or predictable "cryptographically-strong" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. The Dual EC random number backdoor and Debian bugs are relevant examples of this problem. This document describes a way for security protocol participants to mix their long- term private key into the entropy pool(s) from which random values are derived. This augments and improves randomness from broken or otherwise subverted CSPRNGs.
    
draft-ct-isis-nspfid-for-sr-paths-01.txt
 Usage of Non Shortest Path Forwarding (NSPF) IDs in IS-IS
 
 draft-ct-isis-nspfid-for-sr-paths-01.txt
 Date: 23/03/2018
 Authors: Uma Chunduri, Jeff Tantsura, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the advertisement of Non Shortest Path Forwarding IDentifier (NSPF ID) TLV and the computation procedures for the same in IS-IS protocol. NSPF ID allows to simplify the data plane path description of data traffic in SR deployments. This helps mitigate the MTU issues that are caused by additional SR overhead of the packet and allows traffic statistics.
    
draft-ct-ospf-nspfid-for-sr-paths-00.txt
 Usage of Non Shortest Path Forwarding (NSPF) IDs in OSPF
 
 draft-ct-ospf-nspfid-for-sr-paths-00.txt
 Date: 24/03/2018
 Authors: Uma Chunduri, Yingzhen Qu, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the advertisement of Non Shortest Path Forwarding IDentifier (NSPF ID) TLV and the computation procedures for the same in OSPFv2 and OSPFv3 protocols. NSPF ID allows to simplify the data plane path description of data traffic in SR deployments. This helps to mitigate the MTU issues that are caused by additional SR overhead of the packet and allows traffic statistics.
    
draft-cuspdt-rtgwg-cu-separation-bng-architecture-01.txt
 Architecture for Control Plane and User Plane Separated BNG
 
 draft-cuspdt-rtgwg-cu-separation-bng-architecture-01.txt
 Date: 02/07/2018
 Authors: Shujun Hu, Fengwei Qin, Zhenqiang Li, Tee Chua, Zitao Wang, Jun Song
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the new architecture of BNG devices with control plane (CP) and user plane (UP) separation. BNG-CP is a user control management component while BNG-UP takes responsibility as the network edge and user policy implementation component. Both BNG-CP and BNG-UP are core components for fixed broadband services and deployed separately at different network layer in actual network.
    
draft-cuspdt-rtgwg-cu-separation-bng-deployment-01.txt
 Deployment Model of Control Plane and User Plane Separated BNG
 
 draft-cuspdt-rtgwg-cu-separation-bng-deployment-01.txt
 Date: 26/02/2018
 Authors: Rong Gu, Sujun Hu, Zitao Wang, fangwei hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces deployment model of BNG device with Control Plane and User Plane separation in order to give guidance of the deployment of CP and UP separated BNG devices in operators' network.
    
draft-cuspdt-rtgwg-cu-separation-bng-protocol-01.txt
 Control-Plane and User-Plane separation BNG control channel Protocol
 
 draft-cuspdt-rtgwg-cu-separation-bng-protocol-01.txt
 Date: 02/07/2018
 Authors: Shujun Hu, Zitao Wang, Fengwei Qin, Zhenqiang Li, Jun Song, Tee Chua
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the CU Separation BNG control channel Protocol (CUSP) for communications between a Control Plane (CP) and a set of User Planes (UPs). CUSP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.
    
draft-cuspdt-rtgwg-cu-separation-infor-model-02.txt
 Information Model of Control-Plane and User-Plane separation BNG
 
 draft-cuspdt-rtgwg-cu-separation-infor-model-02.txt
 Date: 02/07/2018
 Authors: Shujun Hu, Zitao Wang, Victor Lopezalvarez, Fengwei Qin, Zhenqiang Li, Tee Chua
 Working Group: Individual Submissions (none)
 Formats: xml txt
To improve network resource utilization and reduce the operation expense, the Control-Plane and User-Plane separation conception is raised [TR-384]. This document describes the information model for the interface between Control-Plane and User-Plane separation BNG. This information model may involve both control channel interface and configuration channel interface. The interface for control channel allows the Control-Plane to send several flow tables to the User- Plane, such as user's information table, user's interface table, and user's QoS table, etc. And it also allows the User-Plane to report the resources and statistics information to the Control-Plane. The interface for configuration channel is in charge of the version negotiation of protocols between the Control-Plane and User-Plane, the configuration for devices of Control-Plane and User-Plane, and the reports of User-Plane's capabilities, etc. The information model defined in this document enables defining a standardized data model. Such a data model can be used to define an interface to the CU separation BNG.
    
draft-cuspdt-rtgwg-cusp-requirements-02.txt
 Requirements for Control Plane and User Plane Separated BNG Protocol
 
 draft-cuspdt-rtgwg-cusp-requirements-02.txt
 Date: 02/07/2018
 Authors: Sujun Hu, Victor Lopezalvarez, Fengwei Qin, Zhenqiang Li, Tee Chua, Zitao Wang, Jun Song
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the Control Plane and User Plane separated BNG architecture and defines a set of associated terminology. What's more, this document focuses on defining a set of protocol requirements for the BNG-CP and BNG-UPs communication in the Control Plane and User Plane Separated BNG.
    
draft-dansarie-nts-00.txt
 Network Time Security for the Network Time Protocol
 
 draft-dansarie-nts-00.txt
 Date: 02/07/2018
 Authors: Daniel Franke, Dieter Sibold, Kristof Teichel, Marcus Dansarie, Ragnar Sundblad
 Working Group: Network Time Protocol (ntp)
 Formats: txt pdf xml
This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP). NTS is structured as a suite of two loosely coupled sub-protocols: the NTS Key Establishment Protocol (NTS-KE) and the NTS Extension Fields for NTPv4. NTS-KE handles NTS service authentication, initial handshaking, and key extraction over TLS. Encryption and authentication during NTP time synchronization is performed through the NTS Extension Fields in otherwise standard NTP packets. Except for during the initial NTS-KE process, all state required by the protocol is held by the client in opaque cookies.
    
draft-daveor-cgn-logging-04.txt
 Approaches to Address the Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
 
 draft-daveor-cgn-logging-04.txt
 Date: 12/04/2018
 Authors: David O'Reilly
 Working Group: Individual Submissions (none)
 Formats: xml txt
The use of large-scale IP address sharing technologies (commonly known as "Carrier-Grade NAT" and "A+P") presents a challenge for law enforcement agencies due to the fact that incoming source port information is not routinely logged by Internet-facing servers. The absence of this information means that it is becoming increasingly difficult for law enforcement agencies to identify suspects in criminal activity online. This document considers the reasons why source port information is not routinely logged by Internet-facing servers and makes recommendations to help improve the situation. A deployment maturity model has been developed and a study of the support for logging incoming source port information in common server software is also presented.
    
draft-daveor-ipv6-crime-attribution-00.txt
 Analysis of the Crime Attribution Characteristics of Various IPv6 Address Assignment Techniques
 
 draft-daveor-ipv6-crime-attribution-00.txt
 Date: 25/04/2018
 Authors: David O'Reilly
 Working Group: Individual Submissions (none)
 Formats: xml txt
The migration from IPv4 to IPv6 is intended to fix a large number of problems with IPv4 that have been identified through many years of global use, not least of which is the shortage of available IPv4 addresses. One of the challenges with IPv4 that has not, apparently, been adequately considered is the crime attribution characteristics of IPv6 technologies. The challenge of crime attribution on the Internet is an important one and a careful balance needs to be struck between the needs of law enforcement, the rights of crime victims and the right to privacy of the vast majority of Internet users who have no involvement in any sort of criminality. The purpose of this document is to consider the crime attribution characteristics of various IPv6 address assignment techniques.
    
draft-daveor-slaac-privacy-logging-00.txt
 A Model for Storing IPv6 Stateless Address Autoconfiguration Crime Attribution Records in a Privacy Sensitive Way
 
 draft-daveor-slaac-privacy-logging-00.txt
 Date: 28/05/2018
 Authors: David O'Reilly
 Working Group: Individual Submissions (none)
 Formats: xml txt
The need for individual right to privacy and the need for law enforcement to be able to effectively investigate crime are sometimes portrayed as being irreconcilably in direct conflict with each other. Both needs are legitimate and ignoring the challenges presented by areas of conflict will not make the problem go away. The document presents a conceptual model that allows for both sets of requirements to be met simultaneously. The reason for this publication is to show that, with some creative thinking, it is possible to identify win-win solutions that simultaneously achieve both privacy and law enforcement goals.
    
draft-davidben-tls-universal-psk-00.txt
 Universal PSKs for TLS
 
 draft-davidben-tls-universal-psk-00.txt
 Date: 14/06/2018
 Authors: David Benjamin
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes universal PSKs (Pre-Shared Keys) for TLS. Universal PSKs abstract the TLS 1.3 requirement that each PSK can only be used with a single hash function. This allows PSKs to be provisioned without depending on details of the TLS negotiation, which may change as TLS evolves. Additionally, this document describes a compatibility profile for using TLS 1.3 with PSKs provisioned for the TLS 1.2 PSK mechanism.
    
draft-dawes-sipcore-mediasec-parameter-08.txt
 Security Mechanism Names for Media
 
 draft-dawes-sipcore-mediasec-parameter-08.txt
 Date: 16/05/2018
 Authors: Peter Dawes
 Working Group: Individual Submissions (none)
 Formats: txt
Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is described in [2]. This document adds the capability to distinguish security mechanisms that apply to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label such security mechanisms.
    
draft-dawkins-panrg-what-not-to-do-01.txt
 Path Aware Networking: A Bestiary of Roads Not Taken
 
 draft-dawkins-panrg-what-not-to-do-01.txt
 Date: 18/06/2018
 Authors: Spencer Dawkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
At the first meeting of the proposed Path Aware Networking Research Group, Oliver Bonaventure led a discussion of our mostly-unsuccessful attempts to exploit Path Awareness to achieve a variety of goals, over the past decade. At the end of that discussion, the research group agreed to catalog and analyze these ideas, to extract insights and lessons for path-aware networking researchers. This document contains that catalog and analysis.
    
draft-dawra-idr-bgp-ls-sr-service-segments-00.txt
 BGP-LS Advertisement of Segment Routing Service Segments
 
 draft-dawra-idr-bgp-ls-sr-service-segments-00.txt
 Date: 16/07/2018
 Authors: Gaurav Dawra, Clarence Filsfils, daniel.bernier@bell.ca, Jim Uttaro, Bruno Decraene, Hani Elmalky, Xiaohu Xu, Francois Clad, Ketan Talaulikar
 Working Group: Individual Submissions (none)
 Formats: txt
BGP Link-State (BGP-LS) enables distribution of topology information from the network to a Path Computation Engine (PCE) or any controller/application in general so it can learn the network topology. Service functions are deployed as virtualized elements along with network elements or on servers in data centers. The advertisement of such attached service capabilities along with the network nodes that they are attached to or associated with enable their discovery and for programming of service paths that use these service functions. Segment Routing (SR) bring in the concept of segments which can be topological or service instructions. SR Policies enable setup of paths which are a mix of topological and service segments. This document specifies the extensions to BGP-LS for discovery and advertisement of service segments so as to enable setup of service programming paths using Segment Routing.
    
draft-dawra-idr-bgpls-srv6-ext-03.txt
 BGP Link State extensions for IPv6 Segment Routing(SRv6)
 
 draft-dawra-idr-bgpls-srv6-ext-03.txt
 Date: 05/03/2018
 Authors: Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Mach Chen, daniel.bernier@bell.ca, Jim Uttaro, Bruno Decraene, Hani Elmalky
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing IPv6 (SRv6) allows for a flexible definition of end- to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by the various protocols such as BGP, ISIS and OSPFv3. BGP Link-state (BGP-LS) address-family solution for SRv6 is similar to BGP-LS for SR for MPLS dataplane. This draft defines extensions to the BGP-LS to advertise SRv6 Segments along with there functions and other attributes via BGP.
    
draft-dawra-idr-srv6-vpn-04.txt
 BGP Signaling of IPv6-Segment-Routing-based VPN Networks
 
 draft-dawra-idr-srv6-vpn-04.txt
 Date: 26/06/2018
 Authors: Gaurav Dawra, Clarence Filsfils, Darren Dukes, Patrice Brissette, Pablo Camarillo, John Leddy, daniel.voyer@bell.ca, daniel.bernier@bell.ca, Dirk Steinberg, Robert Raszuk, Bruno Decraene, Satoru Matsushima, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines procedures and messages for BGP SRv6-based L3VPN and EVPN. It builds on RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 "BGP MPLS-Based Ethernet VPN" and provides a migration path from MPLS-based VPNs to SRv6 based VPNs.
    
draft-decimo-babel-dtls-01.txt
 Babel Routing Protocol over Datagram Transport Layer Security
 
 draft-decimo-babel-dtls-01.txt
 Date: 02/07/2018
 Authors: Antonin Decimo, David Schinazi, Juliusz Chroboczek
 Working Group: Individual Submissions (none)
 Formats: txt xml
This documents describes how to use Datagram Transport Layer Security (DTLS) to secure the Babel Routing Protocol.
    
draft-deconinck-quic-multipath-00.txt
 Multipath Extension for QUIC
 
 draft-deconinck-quic-multipath-00.txt
 Date: 05/03/2018
 Authors: Quentin Coninck, Olivier Bonaventure
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes extensions to the QUIC protocol to enable the usage of multiple paths over a single connection. Those changes remain compliant with the current single-path QUIC design. They allow devices to benefit from multiple network paths while preserving the privacy features of QUIC.
    
draft-defoy-coms-subnet-interconnection-03.txt
 Interconnecting (or Stitching) Network Slice Subnets
 
 draft-defoy-coms-subnet-interconnection-03.txt
 Date: 04/03/2018
 Authors: Xavier de Foy, Akbar Rahman, A. Galis, kiran.makhijani@huawei.com, Li Qiang, Shunsuke Homma, Pedro Martinez-Julia
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the network slice (NS) subnet as a general management plane concept that augments a baseline network slice model with management attributes and operations enabling interconnections (or stitching) between network slices. The description of NS subnet interconnections is technology agnostic following the approach of the COMS information model. Some interconnections may be implemented using the interplay between management plane and gateways in the data plane.
    
draft-defoy-mptcp-considerations-for-5g-01.txt
 Considerations for MPTCP operation in 5G
 
 draft-defoy-mptcp-considerations-for-5g-01.txt
 Date: 22/06/2018
 Authors: Xavier de Foy, Michelle Perras, Uma Chunduri, Kien Nguyen, Mirza Kibria, Kentaro Ishizu, Fumihide Kojima
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes scenarios where the behavior of the 5G mobility management framework is different from earlier cellular generations, and describes how it may benefit from some form of adaptation of MPTCP implementations and protocol aspects in the 5G system. This document also describes how MPTCP may be leveraged in 5G system specifications.
    
draft-dejong-remotestorage-11.txt
 remoteStorage
 
 draft-dejong-remotestorage-11.txt
 Date: 07/06/2018
 Authors: Michiel de Jong, F. Kooman
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens.
    
draft-deshpande-intarea-ipaddress-reclassification-00.txt
 IP address space reclassification
 
 draft-deshpande-intarea-ipaddress-reclassification-00.txt
 Date: 04/06/2018
 Authors: Vineet Deshpande
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes an AI based TCP-IP model. By understanding how the Network is evolving from a Wireless and Software perspective the limitations of current Internet Architecture are identified and the corrections needed for the Big Data bottleneck present in current Internet Architecture are described further. This draft explains about the implicit life cycle between the Cloud, Network and Internet. An important conclusion is drawn that the Network cannot be declassified from the Cloud. Based on the evolution of the Virtualized Datacenter within the Cloud architecture framework and the implicit fact that the Network also needs to grow and scale towards the Cloud another important conclusion that the whole Topological address space which is the current IP address space (IP as well as IPv6) needs to be reclassified or divided into a physical (or logical) address space and a new Virtual address space. The Virtual address space is a Centralized Control plane which only processes routing information. A future Internet architecture for resolving the Big Data bottleneck which introduces a Virtual address space at specific Intersection points such as Inter-AS, CsC and IXP (Internet Exchange Points) is described.
    
draft-detchart-nwcrg-tetrys-04.txt
 Tetrys,an On-the-Fly Network Coding protocol
 
 draft-detchart-nwcrg-tetrys-04.txt
 Date: 05/03/2018
 Authors: jonathan.detchart@isae.fr, Emmanuel Lochin, Jerome Lacan, Vincent Roca
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes Tetrys, an On-The-Fly Network Coding (NC) protocol that can be used to transport delay and loss sensitive data over a lossy network. Tetrys can recover from erasures within a RTT- independent delay, thanks to the transmission of coded packets. It can be used for both unicast, multicast and anycast communications.
    
draft-dharini-ccamp-dwdm-if-param-yang-05.txt
 A YANG model to manage the optical interface parameters for an external transponder in a WDM network
 
 draft-dharini-ccamp-dwdm-if-param-yang-05.txt
 Date: 25/06/2018
 Authors: Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or by in phase of specification by) ITU-T G.698.2 [ITU.G698.2] or any other ITU-T recommendation. More context about the state of the Coherent transceivers is described in draft-many- coherent-DWDM-if-control. Use cases are described in RFC7698 The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of a multi-vendor IaDI optical link.
    
draft-dharinigert-ccamp-dwdm-if-lmp-07.txt
 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application
 
 draft-dharinigert-ccamp-dwdm-if-lmp-07.txt
 Date: 25/06/2018
 Authors: Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze, Dieter Beller
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems in accordance with the Interface Application Identifier approach defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its extensions.
    
draft-dhjain-spring-bgp-sr-yang-00.txt
 YANG data model for BGP Segment Routing Extensions
 
 draft-dhjain-spring-bgp-sr-yang-00.txt
 Date: 26/06/2018
 Authors: Dhanendra Jain, Kamran Raza, Bruno Decraene, Zhichun Jiang
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage Segment Routing extensions in BGP.
    
draft-dhody-pce-pcep-pmtu-00.txt
 Support for Path MTU (PMTU) in the Path Computation Element Communication Protocol (PCEP).
 
 draft-dhody-pce-pcep-pmtu-00.txt
 Date: 01/07/2018
 Authors: Dhruv Dhody, Cheng Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available. This document specify the extension to PCE communication protocol (PCEP) to carry path (MTU) in the PCEP messages.
    
draft-dhody-pce-stateful-pce-interdomain-06.txt
 Stateful Path Computation Element (PCE) Inter-domain Considerations
 
 draft-dhody-pce-stateful-pce-interdomain-06.txt
 Date: 02/03/2018
 Authors: Dhruv Dhody, Xian Zhang
 Working Group: Individual Submissions (none)
 Formats: xml txt
A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering path calculations for its associated Path Computation Clients (PCCs). Furthermore, PCEs are used to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains. This document describes general considerations for the deployment of stateful PCE(s) in inter-domain scenarios including inter-area and inter-AS. The inter-layer considerations will be described in a separate document. This document does not specify any extensions to PCEP.
    
draft-dhody-pce-stateful-pce-optional-01.txt
 Extension for Stateful PCE to allow Optional Processing of PCEP Objects.
 
 draft-dhody-pce-stateful-pce-optional-01.txt
 Date: 20/06/2018
 Authors: Dhruv Dhody, Stephane Litkowski
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a mechanism to mark some Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints.
    
draft-dhody-pce-stateful-pce-vendor-04.txt
 Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for stateful PCE.
 
 draft-dhody-pce-stateful-pce-vendor-04.txt
 Date: 02/03/2018
 Authors: Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). RFC 7470 defines a facility to carry vendor-specific information in PCEP. This document extends this capability for the stateful PCE model.
    
draft-dhodylee-pce-pcep-ls-11.txt
 PCEP Extension for Distribution of Link-State and TE Information.
 
 draft-dhodylee-pce-pcep-ls-11.txt
 Date: 21/06/2018
 Authors: Dhruv Dhody, Young Lee, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: txt xml
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state (LS) routing protocol supporting traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information.
    
draft-dickinson-bcp-op-00.txt
 Recommendations for DNS Privacy Service Operators
 
 draft-dickinson-bcp-op-00.txt
 Date: 05/03/2018
 Authors: Sara Dickinson, Roland van Rijswijk-Deij, Allison Mankin
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents operational, policy and security considerations for DNS operators who choose to offer DNS Privacy services including, but not limited to, DNS-over-TLS [RFC7858]. This document also presents a framework to assist writers of DNS Privacy Policy and Practices Statements (analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in [RFC6841]).
    
draft-dickinson-doh-dohpe-00.txt
 DoHPE: DoH with Privacy Enhancements
 
 draft-dickinson-doh-dohpe-00.txt
 Date: 18/07/2018
 Authors: Sara Dickinson, Willem Toorop
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes DoHPE (DoH with Privacy Enhancements) - a privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] clients. The profile provides guidelines on the composition of DoH messages, designed to minimize disclosure of identifying information.
    
draft-dickinson-dprive-bcp-op-01.txt
 Recommendations for DNS Privacy Service Operators
 
 draft-dickinson-dprive-bcp-op-01.txt
 Date: 16/07/2018
 Authors: Sara Dickinson, Benno Overeinder, Roland van Rijswijk-Deij, Allison Mankin
 Working Group: DNS PRIVate Exchange (dprive)
 Formats: txt
This document presents operational, policy and security considerations for DNS operators who choose to offer DNS Privacy services. With the recommendations, the operator can make deliberate decisions which services to provide, and how the decisions and alternatives impact the privacy of users. This document also presents a framework to assist writers of DNS Privacy Policy and Practices Statements (analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in [RFC6841]).
    
draft-ding-rtgwg-arp-yang-model-02.txt
 YANG Data Model for ARP
 
 draft-ding-rtgwg-arp-yang-model-02.txt
 Date: 28/06/2018
 Authors: ding xiaojian, Feng Zheng, Robert Wilton
 Working Group: Routing Area Working Group (rtgwg)
 Formats: txt
This document defines a YANG data model to describe Address Resolution Protocol (ARP) configurations. The data model performs as a guideline for configuring ARP capabilities on a system. It is intended this model be used by service providers who manipulate devices from different vendors in a standard way.
    
draft-dinh-icnrg-sdnnfvicn-00.txt
 Considerations for Using SDN/NFV in ICN
 
 draft-dinh-icnrg-sdnnfvicn-00.txt
 Date: 01/07/2018
 Authors: Thanh Dinh, Young-Han Kim
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides considerations for using Software-Defined Networking (SDN) / Network Function Virtualization (NFV) in Information- Centric Networking (ICN).
    
draft-divination-cfapi-00.txt
 An API For Calendar-Based Fortune Heuristics Services
 
 draft-divination-cfapi-00.txt
 Date: 22/03/2018
 Authors: Gabriel Destiny, Charise Luck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a JSON HTTP API for online services that provide calendar-based fortune heuristics.
    
draft-dm-net2cloud-gap-analysis-00.txt
 Gap Analysis of Interconnecting Underlay with Cloud Overlay
 
 draft-dm-net2cloud-gap-analysis-00.txt
 Date: 02/07/2018
 Authors: Linda Dunbar, Andrew Malis
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the technological gaps when using SD-WAN to interconnect workloads & apps hosted in various locations, especially cloud data centers when the network service providers do not have or have limited physical infrastructure to reach the locations [Net2Cloud-problem].
    
draft-dm-net2cloud-problem-statement-02.txt
 Seamless Interconnect Underlay to Cloud Overlay Problem Statement
 
 draft-dm-net2cloud-problem-statement-02.txt
 Date: 02/07/2018
 Authors: Linda Dunbar, Andrew Malis, Christian Jacquenet, Mehmet Toy
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the problems of enterprises face today in connecting their branch offices to dynamic workloads in commercial cloud data centers (DCs). It examines some of the approaches for interconnecting workloads & applications hosted in cloud DCs with enterprises' on-premises DCs & branch offices. This document also describes some of the (network) problems that many enterprises face when they have workloads & applications & data split among hybrid data centers, especially for those enterprises with multiple sites that are already interconnected by VPNs (e.g. MPLS L2VPN/L3VPN) and leased lines. Current operational problems in the field are examined to determine whether there is a need for enhancements to existing protocols or whether a new protocol is necessary to solve them.
    
draft-dnoveck-nfsv4-rpcrdma-rtissues-05.txt
 Issues Related to RPC-over-RDMA Internode Round Trips
 
 draft-dnoveck-nfsv4-rpcrdma-rtissues-05.txt
 Date: 22/02/2018
 Authors: David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
As currently designed and implemented, the RPC-over-RDMA protocol requires use of multiple internode round trips to process some common operations. For example, NFS WRITE operations require use of three internode round trips. This document looks at this issue and discusses what can and what should be done to address it, both within the context of an extensible version of RPC-over-RDMA and potentially outside that framework.
    
draft-do-babel-hmac-00.txt
 Babel Cryptographic Authentification
 
 draft-do-babel-hmac-00.txt
 Date: 02/07/2018
 Authors: Clara Do, Weronika Kolodziejak, Juliusz Chroboczek
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document updates RFC 6126bis and obsoletes RFC 7298.
    
draft-dold-payto-01.txt
 The 'payto' URI scheme for payments
 
 draft-dold-payto-01.txt
 Date: 07/04/2018
 Authors: Florian Dold, Christian Grothoff
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the 'payto' Uniform Resource Identifier (URI) scheme for specifying payments.
    
draft-dolson-transport-middlebox-03.txt
 An Inventory of Transport-centric Functions Provided by Middleboxes
 
 draft-dolson-transport-middlebox-03.txt
 Date: 20/06/2018
 Authors: David Dolson, Juho Snellman, Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document summarizes benefits that operators perceive to be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes". RFC3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application-layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets. A primary goal of this document is to provide information to working groups developing new transport protocols, to aid understanding of what might be gained or lost by design decisions that may affect (or be affected by) middlebox operation.
    
draft-dong-i2nsf-asf-config-00.txt
 Configuration of Advanced Security Functions with I2NSF Security Controller
 
 draft-dong-i2nsf-asf-config-00.txt
 Date: 30/06/2018
 Authors: Yue Dong, Liang Xia
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft defines a network security function (NSF-) facing interface of the security controller for the purpose of configuring some advanced security functions. These advanced security functions include antivirus, anti-ddos, and intrusion prevention system (IPS). The interface is presented in a YANG data model fashion and can be used to deploy a large amount of NSF blocks that all support above mentioned functions in the software defined network (SDN) based paradigm.
    
draft-dong-idr-node-target-ext-comm-00.txt
 BGP Extended Community for Identifying the Target Node
 
 draft-dong-idr-node-target-ext-comm-00.txt
 Date: 05/03/2018
 Authors: Jie Dong, Shunwan Zhuang, Gunter Van de Velde
 Working Group: Individual Submissions (none)
 Formats: txt
BGP has been used to distribute different types of routing and policy information in the network. In some cases, the information distributed may be only intended for one or several particular receiving BGP nodes in the network. BGP does not have a general mechanism for designating the receiving node of the routing information. This document defines a new type of BGP extended community called "Node Target". The mechanism and of using the Node Target extended community to steer BGP route distribution to particular BGP nodes is specified.
    
draft-dong-lsr-sr-enhanced-vpn-00.txt
 IGP Extensions for Segment Routing based Enhanced VPN
 
 draft-dong-lsr-sr-enhanced-vpn-00.txt
 Date: 20/06/2018
 Authors: Jie Dong, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: txt
Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. These applications require better isolation and have more stringent performance requirements than that can be provided with traditional overlay VPNs. An enhanced VPN may form the underpin of 5G transport network slicing, and will also be of use in its own right. This document describes how Multi- Topology Routing (MTR) as described in RFC 5120 and RFC 4915, can be extended to signal the resources allocated in the underlay network to construct the virtual networks for enhanced VPN services, together with the Segment Routing Identifiers (SIDs) used to identify and access the network resources allocated for the virtual networks in the data plane.
    
draft-dong-sacm-nid-infra-security-baseline-01.txt
 The Data Model of Network Infrastructure Device Infrastructure Layer Security Baseline
 
 draft-dong-sacm-nid-infra-security-baseline-01.txt
 Date: 24/05/2018
 Authors: Yue Dong, Liang Xia
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is one of the companion documents which describes the infrastructure layer security baseline YANG output for network infrastructure devices. The infrastructure layer security baseline covers the security functions to secure the device itself, and the fundamental security capabilities provided by the device to the upper layer applications. In this specific document, the integrity measurement, cryptography algorithms, key management, and certificate management are sorted out to generate the data model.
    
draft-dong-spring-sr-for-enhanced-vpn-01.txt
 Segment Routing for Enhanced VPN Service
 
 draft-dong-spring-sr-for-enhanced-vpn-01.txt
 Date: 02/07/2018
 Authors: Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka
 Working Group: Individual Submissions (none)
 Formats: txt
Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it to support the needs of new applications, particularly applications that are associated with 5G services. These applications require better isolation and have more stringent performance requirements than can be provided with overlay VPNs. The characteristics of an enhanced VPN as perceived by its tenant needs to be comparable to those of a dedicated private network. This requires tight integration between the overlay VPN and the underlay network resources in a scalable manner. An enhanced VPN may form the underpin of 5G network slicing, but will also be of use in its own right. This document describes the use of segment routing based mechanisms to provide the enhanced VPN service with dedicated network resources.
    
draft-dong-teas-enhanced-vpn-00.txt
 Enhanced Virtual Private Networks (VPN+)
 
 draft-dong-teas-enhanced-vpn-00.txt
 Date: 02/07/2018
 Authors: Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a number of enhancements that need to be made to virtual private networks (VPNs) to support the needs of new applications, particularly applications that are associated with 5G services. A network enhanced with these properties may form the underpin of network slicing, but will also be of use in its own right. Editor's Note: This is draft-bryant-rtgwg-enhanced-vpn moved to the TEAS WG.
    
draft-donnerhacke-linktax-01.txt
 Rights for restricted content
 
 draft-donnerhacke-linktax-01.txt
 Date: 28/06/2018
 Authors: Lutz Donnerhacke
 Working Group: Individual Submissions (none)
 Formats: xml txt
Links are omnipresent in the Internet to provide access to other resources. There is no mechanism to express differences in law systems, access limitations, or arbitrary rules defined by the owner of the linked resource. Therefore links do depend on and enforce a communist sharing ideology, which ignores the content owner rights. Links may point to resources far away from the originating page, hiding this fact from the customer. It takes the data transport services for free, internet transit providers on the way from the content source to the customers are not extra payed for this effort. In many cases, the remote company generates huge amount of money from the customers worldwide not shared with the transit providers. In order to get the rights of all involved parties balanced, a new type of connection initiation is proposed: The Right.
    
draft-dorfner-core-simplemetadata-00.txt
 SimpleMetadata: An interoperable format for sharing metadata
 
 draft-dorfner-core-simplemetadata-00.txt
 Date: 16/04/2018
 Authors: Ralf Dorfner
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a container format for storing serializable metadata. It shall provide the possibility to store and share any kind of metadata, including encryption support. The idea is to create an open, universal and interoperable standard for storing and distributing every kind of metadata independent from media type or file format.
    
draft-douglass-subscription-upgrade-03.txt
 Calendar subscription upgrades
 
 draft-douglass-subscription-upgrade-03.txt
 Date: 05/05/2018
 Authors: Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification introduces an approach to allow subscribers to calendar feeds to upgrade to a more performant protocol. This specification updates [RFC5545] to add the value DELETED to the STATUS property.
    
draft-dreibholz-ipv4-flowlabel-27.txt
 An IPv4 Flowlabel Option
 
 draft-dreibholz-ipv4-flowlabel-27.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6.
    
draft-dreibholz-rserpool-applic-distcomp-24.txt
 Applicability of Reliable Server Pooling for Real-Time Distributed Computing
 
 draft-dreibholz-rserpool-applic-distcomp-24.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools.
    
draft-dreibholz-rserpool-applic-mobility-23.txt
 Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility
 
 draft-dreibholz-rserpool-applic-mobility-23.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Jobin Pulinthanath
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool).
    
draft-dreibholz-rserpool-asap-hropt-22.txt
 Handle Resolution Option for ASAP
 
 draft-dreibholz-rserpool-asap-hropt-22.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Handle Resolution option for the ASAP protocol.
    
draft-dreibholz-rserpool-delay-21.txt
 Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling
 
 draft-dreibholz-rserpool-delay-21.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Xing Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling.
    
draft-dreibholz-rserpool-enrp-takeover-19.txt
 Takeover Suggestion Flag for the ENRP Handle Update Message
 
 draft-dreibholz-rserpool-enrp-takeover-19.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Xing Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol.
    
draft-dreibholz-rserpool-nextgen-ideas-09.txt
 Ideas for a Next Generation of the Reliable Server Pooling Framework
 
 draft-dreibholz-rserpool-nextgen-ideas-09.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document collects some idea for a next generation of the Reliable Server Pooling framework.
    
draft-dreibholz-rserpool-score-22.txt
 Reliable Server Pooling (RSerPool) Bakeoff Scoring
 
 draft-dreibholz-rserpool-score-22.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Michael Tuexen
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.
    
draft-dreibholz-taps-neat-socketapi-03.txt
 NEAT Sockets API
 
 draft-dreibholz-taps-neat-socketapi-03.txt
 Date: 07/06/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality.
    
draft-dreibholz-tsvwg-sctp-nextgen-ideas-07.txt
 Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)
 
 draft-dreibholz-tsvwg-sctp-nextgen-ideas-07.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment.
    
draft-dreibholz-tsvwg-sctpsocket-multipath-16.txt
 SCTP Socket API Extensions for Concurrent Multipath Transfer
 
 draft-dreibholz-tsvwg-sctpsocket-multipath-16.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Martin Becke, Hakim Adhari
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions.
    
draft-dreibholz-tsvwg-sctpsocket-sqinfo-16.txt
 Sender Queue Info Option for the SCTP Socket API
 
 draft-dreibholz-tsvwg-sctpsocket-sqinfo-16.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Robin Seggelmann, Martin Becke
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an extension to the SCTP sockets API for querying information about the sender queue.
    
draft-dreibholz-vnfpool-rserpool-applic-07.txt
 The Applicability of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL)
 
 draft-dreibholz-vnfpool-rserpool-applic-07.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Michael Tuexen, Melinda Shore, Ning Zong
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes the application of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL).
    
draft-dschinazi-ipsecme-sa-init-privacy-addition-00.txt
 Privacy Addition to the Internet Key Exchange Protocol Version 2 (IKEv2) IKE_SA_INIT Exchange
 
 draft-dschinazi-ipsecme-sa-init-privacy-addition-00.txt
 Date: 05/03/2018
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Internet Key Exchange Protocol version 2 (IKEv2) provides strong security and privacy properties to both endpoints once they have authenticated each other. However, before an endpoint has validated the peer's AUTH payload, it could be divulging information to an untrusted host. An example of such information is the Identification payload of the initiator. Another example is the fact that a host is running an IKEv2 responder. This document introduces a new "Initialization Authentication Code" notify payload that can be included in IKE_SA_INIT messages to increase their trustworthiness. This new protection is meant to be used in addition to current IKEv2 mechanisms and is not meant to replace the AUTH payload in any way.
    
draft-dt-iasa20-proposal-00.txt
 Proposed Structure of the IETF Administrative Organization
 
 draft-dt-iasa20-proposal-00.txt
 Date: 05/04/2018
 Authors: Joseph Hall, Brian Haberman, Jari Arkko, Leslie Daigle, Jason Livingood, Eric Rescorla
 Working Group: Individual Submissions (none)
 Formats: txt xml
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the intervening years, the needs of the IETF have evolved in ways that require changes to its administrative structure. The IETF Chair started an effort in November of 2016 to begin the process of changing the IETF administrative structure, starting with a set of virtual workshops to get input from the IETF community, and then encompassing a series of BOF sessions at IETF meetings to define the problem, develop requirements, explore potential options for changes, and a Design Team - the authors of this document - that would make recommendations. The purpose of this document is to collect all of the various materials that have lead up to the Design Team recommendation that IETF be a Disregarded Limited Liability Company (LLC) of the Internet Society.
    
draft-duchene-spring-srv6-socket-00.txt
 A socket API to control IPv6 Segment Routing
 
 draft-duchene-spring-srv6-socket-00.txt
 Date: 05/03/2018
 Authors: Fabien Duchene, Olivier Bonaventure
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a socket API to allow applications to control the utilisation of IPv6 Segment Routing (SRv6).
    
draft-dugeon-pce-stateful-interdomain-01.txt
 PCEP Extension for Stateful Inter-Domain Tunnels
 
 draft-dugeon-pce-stateful-interdomain-01.txt
 Date: 02/07/2018
 Authors: Olivier Dugeon, Julien Meuric, Young Lee, Dhruv Dhody, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes to combine a Backward Recursive or Hierarchical method in Stateful PCE with PCInitiate message to setup independent paths per domain, and combine these different paths together in order to operate them as end-to-end inter-domain paths without the need of signaling session between AS border routers. A new Stitching Label is defined and new LSP-TYPE code points are considered for that purpose.
    
draft-duke-quic-load-balancers-01.txt
 QUIC-LB: Using Load Balancers to Generate QUIC Connection IDs
 
 draft-duke-quic-load-balancers-01.txt
 Date: 22/05/2018
 Authors: Martin Duke
 Working Group: Individual Submissions (none)
 Formats: txt
QUIC connection IDs allow continuation of connections across address/ port 5-tuple changes, and can store routing information for stateless or low-state layer 4 load balancers. They are also meant to prevent linkability of connections across deliberate address migration through the use of protected communications between client and server. This creates issues for load-balancing intermediaries. This specification standardizes the communication between load balancers and servers to overcome these issues in a protocol called QUIC-LB.
    
draft-dukes-spring-mtu-overhead-analysis-00.txt
 Comparative Analysis of MTU overhead in the context of SPRING
 
 draft-dukes-spring-mtu-overhead-analysis-00.txt
 Date: 18/03/2018
 Authors: Darren Dukes, Clarence Filsfils, Pablo Camarillo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides an apples-to-apples comparative analysis of MTU overhead in the context of SPRING.
    
draft-dukes-spring-sr-for-sdwan-00.txt
 SR For SDWAN: VPN with Underlay SLA
 
 draft-dukes-spring-sr-for-sdwan-00.txt
 Date: 05/06/2018
 Authors: Darren Dukes, Clarence Filsfils, Gaurav Dawra, Xiaohu Xu, daniel.voyer@bell.ca, Pablo Camarillo, Francois Clad, Stefano Salsano
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes how SR enables underlay Service Level Agreements (SLA) to a VPN with scale and security while ensuring service opacity. This solution applies to Over-The-Top VPN (OTT VPN) and Software-Defined WAN (SDWAN).
    
draft-dulaunoy-dnsop-passive-dns-cof-04.txt
 Passive DNS - Common Output Format
 
 draft-dulaunoy-dnsop-passive-dns-cof-04.txt
 Date: 21/06/2018
 Authors: Alexandre Dulaunoy, Aaron Kaplan, Paul Vixie, Henry Stern
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a common output format of Passive DNS Servers which clients can query. The output format description includes also in addition a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily.
    
draft-dulaunoy-misp-core-format-04.txt
 MISP core format
 
 draft-dulaunoy-misp-core-format-04.txt
 Date: 10/04/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP core format used to exchange indicators and threat information between MISP (Malware Information and threat Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms.
    
draft-dulaunoy-misp-galaxy-format-02.txt
 MISP galaxy format
 
 draft-dulaunoy-misp-galaxy-format-02.txt
 Date: 09/05/2018
 Authors: Alexandre Dulaunoy, Andras Iklody, Deborah Servili
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository [MISP-G] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
    
draft-dulaunoy-misp-object-template-format-01.txt
 MISP object template format
 
 draft-dulaunoy-misp-object-template-format-01.txt
 Date: 10/04/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates [MISP-O] is available and relies on the MISP object reference format.
    
draft-dulaunoy-misp-taxonomy-format-05.txt
 MISP taxonomy format
 
 draft-dulaunoy-misp-taxonomy-format-05.txt
 Date: 01/06/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP taxonomy format which describes a simple JSON format to represent machine tags (also called triple tags) vocabularies. A public directory of common vocabularies MISP taxonomies is available and relies on the MISP taxonomy format. MISP taxonomies are used to classify cyber security events, threats or indicators.
    
draft-dunbar-sr-sdwan-over-hybrid-networks-02.txt
 Segment routing for SD-WAN paths over hybrid networks
 
 draft-dunbar-sr-sdwan-over-hybrid-networks-02.txt
 Date: 02/07/2018
 Authors: Linda Dunbar, Mehmet Toy
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a method for end-to-end (E2E) SD-WAN paths (most likely encrypted) to traverse specific list of network segments, some of which are SR enabled and others may be IP networks that do not support SR, to achieve the desired optimal E2E quality. The method described in this draft uses the principle of segment routing to enforce a SD-WAN path' head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segment to have the intelligence (or maintaining states) of selecting next hop or next domain. Those networks over which the SD-WAN path traverse have at least one SR enabled network, and some network segments (especially the last mile access portion) being existing IP networks (such as existing IPv4, IPv6 or others).
    
draft-duquennoy-6tisch-asf-01.txt
 6TiSCH Autonomous Scheduling Function (ASF)
 
 draft-duquennoy-6tisch-asf-01.txt
 Date: 02/03/2018
 Authors: Simon Duquennoy, Xavier Vilajosana, Thomas Watteyne
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a Scheduling Function called "ASF": the 6TiSCH Autonomous Scheduling Function. With ASF, nodes maintain their TSCH schedule based on local neighborhood knowledge, without any signaling after association. Hashes of the nodes' MAC address are used to deterministically derive the [slotOffset,channelOffset] location of cells in the TSCH schedule. Different traffic types (e.g. TSCH EB, RPL DIO, UDP etc.) are assigned to distinct slotframes, for isolation and flexible dimensioning. This approach provides over-provisioned schedules with low maintenance, in pursuit for simplicity rather than optimality.
    
draft-eastlake-bess-enhance-evpn-all-active-00.txt
 EVPN All Active Usage Enhancement
 
 draft-eastlake-bess-enhance-evpn-all-active-00.txt
 Date: 05/03/2018
 Authors: Donald Eastlake, Zhenbin Li, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: txt
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links.
    
draft-eastlake-bess-evpn-vxlan-bypass-vtep-01.txt
 EVPN VXLAN Bypass VTEP
 
 draft-eastlake-bess-evpn-vxlan-bypass-vtep-01.txt
 Date: 16/07/2018
 Authors: Donald Eastlake, Zhenbin Li, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) with all-active links. This draft specifies a mechanism to simplify PEs used with VXLAN tunnels and enhance VXLAN Active-Active reliability.
    
draft-eastlake-fnv-15.txt
 The FNV Non-Cryptographic Hash Algorithm
 
 draft-eastlake-fnv-15.txt
 Date: 12/06/2018
 Authors: Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen
 Working Group: Individual Submissions (none)
 Formats: txt
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community.
    
draft-eastlake-rfc6931bis-xmlsec-uris-07.txt
 Additional XML Security Uniform Resource Identifiers (URIs)
 
 draft-eastlake-rfc6931bis-xmlsec-uris-07.txt
 Date: 04/04/2018
 Authors: Donald Eastlake
 Working Group: Individual Submissions (none)
 Formats: txt
This document updates and corrects the IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document corrrects three errata against and obsoletes RFC 6931. The intent is to keep this draft alive while it accumulates updates until it seems reasonable to publish the next version.
    
draft-eastlake-sfc-nsh-ecn-support-01.txt
 Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH)
 
 draft-eastlake-sfc-nsh-ecn-support-01.txt
 Date: 02/07/2018
 Authors: Donald Eastlake, Bob Briscoe, Andrew Malis
 Working Group: Individual Submissions (none)
 Formats: txt
Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to expose congestion by feeding back information about it to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, draft-ietf-tsvwg-tunnel- congestion-feedback).
    
draft-eckert-anima-grasp-dnssd-01.txt
 DNS-SD compatible service discovery in GRASP
 
 draft-eckert-anima-grasp-dnssd-01.txt
 Date: 01/07/2018
 Authors: Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: xml txt
DNS Service Discovery (DNS-SD) defines the common framework for applications to announce and discover services. This includes service names, service instance names, common parameters for selecting a service instance (weight, priority) as well as service specific parameters. GRASP is intended to also be used for service discovery. Reinventing service discovery for GRASP with a similar set of fetures would result in duplication of work. Therefore, this document defines how to use GRASP to announce and discover services in a way that inherits DNS-SD features and also tries to be compatible in spirit as much as possibel while still maintaining the intended simplicity of GRASP. The goal of this document is to permit defining service and their parameters once and then use that in GRASP, mDNS and (unicast) DNS. Future work can also define DNS-SD <-> GRASP gateway functions. In support of service discovery, this document also defines name discovery and schemes for reuseable elements in GRASP objectives which are designed to be extensible so that future work that identifies elements required across multiple objectives do not need to define a scheme how to do this.
    
draft-eckert-anima-noc-autoconfig-00.txt
 Autoconfiguration of NOC services in ACP networks via GRASP
 
 draft-eckert-anima-noc-autoconfig-00.txt
 Date: 02/07/2018
 Authors: Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines standards for the autoconfiguration of crucial NOC services on ACP nodes via GRASP. It enables secure remote access to zero-touch bootstrapped ANI devices via SSH/Netconf with Radius/ Diameter authentication and authorization and provides lifecycle autoconfiguration for other crucial services such as syslog, NTP (clock synchronization) and DNS for operational purposes.
    
draft-eckert-bier-te-frr-03.txt
 Protection Methods for BIER-TE
 
 draft-eckert-bier-te-frr-03.txt
 Date: 05/03/2018
 Authors: Toerless Eckert, Gregory Cauchie, Wolfgang Braun, Michael Menth
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes protection methods for the BIER-TE architecture [I-D.ietf-bier-te-arch]. These include 1+1 (live-live) path/tree [RFC7431] redundancy, 1:1 path/tree protection, as well as fast reroute (FRR) methods. The latter may protect against link and/ or node failures and leverage infrastructure tunnels, BIER-in-BIER encapsulation, or header modification for implementation. In particular, this memo describes FRR for BIER-TE in detail. FRR for BIER-TE requires support from the BIER-TE controller and the BFRs that are attached to a link/adjacency for which FRR protection is desired. FRR relies on the BIER header described in [RFC8279] which is also used by BIER-TE. It does not require extensions or modifications to existing BIER-TE tables. However, the presented FRR procedures need some additional forwarding plane logic on the BFR. An additional table is needed that carries information about pre- computed backup paths. When a failure is detected, the information from this table is used to modify the bitstring in the BIER header before forwarding a packet over a backup path. To prevent undesired packet duplication, packets should be tunneled on the backup paths.
    
draft-eckert-teas-bier-te-framework-00.txt
 Framework for Traffic Engineering with BIER-TE forwarding (Bit Index Explicit Replication with Traffic Engineering)
 
 draft-eckert-teas-bier-te-framework-00.txt
 Date: 05/03/2018
 Authors: Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt xml
BIER-TE is an application-state free, (loose) source routed multicast forwarding method where every hop and destination is identified via bits in a bitstring of the data packets. It is described in [I-D.ietf-bier-te-arch]. BIER-TE is a variant of [RFC8279] in support of such explicit path engineering. This document described the traffic engineering control framework for use with the BIER-TE forwarding plane: How to enable the ability to calculate paths and integrate this forwarding plane into an overall TE solution.
    
draft-edwards-telnet-xon-xoff-state-control-00.txt
 Xon/Xoff State Control for Telnet Com Port Control Option
 
 draft-edwards-telnet-xon-xoff-state-control-00.txt
 Date: 23/03/2010
 Authors: Grant Edwards
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server.
    
draft-ekwk-capport-rfc7710bis-00.txt
 Captive-Portal Identification in DHCP / RA
 
 draft-ekwk-capport-rfc7710bis-00.txt
 Date: 15/07/2018
 Authors: Warren Kumari, Erik Kline
 Working Group: Individual Submissions (none)
 Formats: txt xml
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device, and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to, and interacting with the captive portal is out of scope of this document. [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-ekwk-capport-rfc7710bis. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. Text in square brackets will be removed before publication. ]
    
draft-elders-social-media-apology-00.txt
 Social Media (An Apology)
 
 draft-elders-social-media-apology-00.txt
 Date: 16/07/2018
 Authors: The Internet
 Working Group: Individual Submissions (none)
 Formats: txt
Oops, we did it again.
    
draft-erdtman-jose-cleartext-jwe-00.txt
 Cleartext JSON Web Encryption (JWE)
 
 draft-erdtman-jose-cleartext-jwe-00.txt
 Date: 05/03/2018
 Authors: Samuel Erdtman, Anders Rundgren, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: xml txt
Cleartext JSON Web Encryption (JWE) is a means of representing encrypted content as a JSON object without representing JSON values to be integrity protected in a non-JSON representation, such as base64url-encoded JSON. The integrity protection calculation for the authenticated encryption performed uses the predictable JSON serialization defined in ECMAScript version 6. Cleartext JWE builds on the JWE, JWA, and JWK specifications, reusing data structures and semantics from these specifications, where applicable.
    
draft-erdtman-jose-cleartext-jws-00.txt
 Cleartext JSON Web Signature (JWS)
 
 draft-erdtman-jose-cleartext-jws-00.txt
 Date: 05/03/2018
 Authors: Samuel Erdtman, Anders Rundgren, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: txt xml
Cleartext JSON Web Signature (JWS) is a means of signing JSON objects directly without representing the JSON to be signed in a non-JSON representation, such as base64url-encoded JSON. The signature and information about the signature is added to the JSON object when it is signed. The signature calculation for signing the JSON object uses the predictable JSON serialization defined in ECMAScript version 6. Cleartext JWS builds on the JWS, JWA, and JWK specifications, reusing data structures and semantics from these specifications, where applicable.
    
draft-ermagan-lisp-nat-traversal-14.txt
 NAT traversal for LISP
 
 draft-ermagan-lisp-nat-traversal-14.txt
 Date: 16/04/2018
 Authors: Vina Ermagan, Dino Farinacci, Darrel Lewis, Jesper Skriver, Fabio Maino, Chris White
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) network element, which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT.
    
draft-ermagan-lisp-nsh-05.txt
 LISP Control Plane integration with NSH
 
 draft-ermagan-lisp-nsh-05.txt
 Date: 29/03/2018
 Authors: Vina Ermagan, Paul Quinn, Darrel Lewis, Fabio Maino, Florin Coras
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines extensions to the LISP control plane protocol to enable support for Network Service Header(NSH) based Service Function Chaining (SFC).
    
draft-esale-mpls-ldp-rmr-extensions-02.txt
 LDP Extensions for RMR
 
 draft-esale-mpls-ldp-rmr-extensions-02.txt
 Date: 20/05/2018
 Authors: Santosh Esale, Kireeti Kompella
 Working Group: Multiprotocol Label Switching (mpls)
 Formats: txt
This document describes LDP extensions to signal Resilient MPLS Ring (RMR) Label Switched Paths (LSPs). An RMR LSP is a multipoint to point LSP signaled using LDP (Label Distribution Protocol). RMR Architecture document - draft-ietf-mpls-rmr-02 - describes why and how MPLS should be used in ring topologies.
    
draft-even-avtcore-priority-markings-02.txt
 Frame Priority Marking RTP Header Extension
 
 draft-even-avtcore-priority-markings-02.txt
 Date: 24/06/2018
 Authors: Roni Even, Ofer Idan
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document updates the Frame Marking RTP header extension in draft-ietf-avtext-framemarking-06 used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middle-boxes or network nodes. The flags for frame marking for non-scalable streams include the D bit to mark a frame that can be discarded, and still provide a decodable media stream. There is also the I bit for frames that can be decoded independent of prior frames, e.g. intra-frame. This memo adds priority values for the non-scalable streams discardable frames
    
draft-fairhurst-tsvwg-transport-encrypt-09.txt
 The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet
 
 draft-fairhurst-tsvwg-transport-encrypt-09.txt
 Date: 13/06/2018
 Authors: Gorry Fairhurst, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes implications of applying end-to-end encryption at the transport layer. It identifies in-network uses of transport layer header information. It then reviews the implications of developing end-to-end transport protocols that use authentication to protect the integrity of transport information or encryption to provide confidentiality of the transport protocol header and expected implications of transport protocol design and network operation. Since transport measurement and analysis of the impact of network characteristics have been important to the design of current transport protocols, it also considers the impact on transport and application evolution.
    
draft-faltstrom-unicode11-01.txt
 IDNA2008 and Unicode 11.0.0
 
 draft-faltstrom-unicode11-01.txt
 Date: 02/07/2018
 Authors: Patrik Faltstrom
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes changes between Unicode 6.3.0 and Unicode 11.0.0 in the context of IDNA2008. It further suggests for the IETF a path forward regarding ensuring IDNA2008 follows the evolution of the Unicode Standard.
    
draft-farinacci-lisp-decent-01.txt
 A Decent LISP Mapping System (LISP-Decent)
 
 draft-farinacci-lisp-decent-01.txt
 Date: 02/07/2018
 Authors: Dino Farinacci, Colin Cantrell
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust.
    
draft-farinacci-lisp-ecdsa-auth-02.txt
 LISP Control-Plane ECDSA Authentication and Authorization
 
 draft-farinacci-lisp-ecdsa-auth-02.txt
 Date: 19/04/2018
 Authors: Dino Farinacci, Erik Nordmark
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required.
    
draft-farinacci-lisp-geo-05.txt
 LISP Geo-Coordinate Use-Cases
 
 draft-farinacci-lisp-geo-05.txt
 Date: 16/04/2018
 Authors: Dino Farinacci
 Working Group: Locator/ID Separation Protocol (lisp)
 Formats: txt
This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols.
    
draft-farinacci-lisp-mobile-network-03.txt
 LISP for the Mobile Network
 
 draft-farinacci-lisp-mobile-network-03.txt
 Date: 18/03/2018
 Authors: Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: txt
This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network.
    
draft-farinacci-lisp-name-encoding-05.txt
 LISP Distinguished Name Encoding
 
 draft-farinacci-lisp-name-encoding-05.txt
 Date: 18/03/2018
 Authors: Dino Farinacci
 Working Group: Locator/ID Separation Protocol (lisp)
 Formats: txt
This draft defines how to use the AFI=17 Distinguished Names in LISP.
    
draft-farinacci-lisp-telemetry-00.txt
 LISP Data-Plane Telemetry
 
 draft-farinacci-lisp-telemetry-00.txt
 Date: 29/06/2018
 Authors: Dino Farinacci, Said Ouissal, Erik Nordmark
 Working Group: Individual Submissions (none)
 Formats: txt
This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages.
    
draft-farrel-spring-sr-domain-interconnect-04.txt
 Interconnection of Segment Routing Domains - Problem Statement and Solution Landscape
 
 draft-farrel-spring-sr-domain-interconnect-04.txt
 Date: 13/06/2018
 Authors: Adrian Farrel, John Drake
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) is a forwarding paradigm for use in MPLS and IPv6 networks. It is intended to be deployed in discrete domains that may be data centers, access networks, or other networks that are under the control of a single operator and that can easily be upgraded to support this new technology. Traffic originating in one SR domain often terminates in another SR domain, but must transit a backbone network that provides interconnection between those domains. This document describes a mechanism for providing connectivity between SR domains to enable end-to-end or domain-to-domain traffic engineering. The approach described allows connectivity between SR domains, utilizes traffic engineering mechanisms (RSVP-TE or Segment Routing) across the backbone network, makes heavy use of pre-existing technologies, and requires the specification of very few additional mechanisms. This document provides some background and a problem statement, explains the solution mechanism, gives references to other documents that define protocol mechanisms, and provides examples. It does not define any new protocol mechanisms.
    
draft-fear-ippm-mpdm-01.txt
 IPv6 Marking and Performance and Diagnostic Metrics (MPDM)
 
 draft-fear-ippm-mpdm-01.txt
 Date: 24/06/2018
 Authors: Nalini Elkins, Giuseppe Fioccola, mackermann@bcbsm.com, Rob Hamilton
 Working Group: Individual Submissions (none)
 Formats: txt
To assess performance problems, this document describes optional headers embedded in each packet that provide marking, sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real-time or after the fact. This document specifies the IPv6 Marking and Performance and Diagnostic Metrics (M-PDM) Hop-byHop and Destination Options extension headers.
    
draft-feeney-t2trg-inter-network-03.txt
 Inter-network Coexistence in the Internet of Things
 
 draft-feeney-t2trg-inter-network-03.txt
 Date: 28/05/2018
 Authors: Laura Feeney, Viktoria Fodor
 Working Group: Individual Submissions (none)
 Formats: xml txt
The breadth of IoT applications implies that there will be many diverse, administratively independent networks operating in the same physical location. In many cases, these networks will use unlicensed spectrum, due to its low cost and ease of deployment. However, this spectrum is becoming increasingly crowded. IoT networks will therefore be subject to wireless interference, both from similar networks and from networks that use the wireless channel in very different ways. High-density, heterogeneous wireless environments present formidable challenges for network coexistence. The PHY and MAC layers are primarily responsible for managing how radios use the channel. But higher layer protocols are also a key factor in inter-network interaction. To date, there have been few performance studies of coexistence in future IoT operating environments, particularly with respect to protocol behavior and network-scale interactions. This document describes key challenges for coexistence and highlights some recent research results that demonstrate the impact of protocol level interactions on network performance. It identifies both concrete and speculative opportunities for the IRTF T2TRG community. The former include developing and documenting best practices for performance evaluation and contributing IoT-related protocols being developed within IETF. The latter include speculative research into the design of high-layer protocols that allow networks to actively coordinate their access to the shared channel.
    
draft-feng-dmm-ra-prefixtype-02.txt
 Router Advertisement Extensions for On-Demand Mobility
 
 draft-feng-dmm-ra-prefixtype-02.txt
 Date: 17/03/2018
 Authors: Wu-chi Feng, Danny Moses
 Working Group: Individual Submissions (none)
 Formats: xml txt
Router Advertisement / Router Solicitation is one of the ways for hosts to establish network IPv6 connectivity configuration. This document describes two approches to allowing a router to specify service continuity type availability to mobile hosts. Mobile hosts can then configure their IP address to the preferred service continuity type. Two possibilities are considered: (i) creating an extension to the router advertisement prefix information option to allow the router to specify service connectivity types, and (ii) specifying a new RA options that allows the router to specify the service connectivity types.
    
draft-fenter-tls-decryption-00.txt
 Why Enterprises Need Out-of-Band TLS Decryption
 
 draft-fenter-tls-decryption-00.txt
 Date: 05/03/2018
 Authors: Steve Fenter
 Working Group: Individual Submissions (none)
 Formats: txt
Some enterprises are heavily TLS encrypted within their own enterprise network boundaries. Many of these enterprises are also utilizing out-of-band TLS decryption in order to inspect their own traffic for purposes of troubleshooting, network security monitoring, and for other kinds of monitoring. These monitoring functions are mission critical, and cannot just be done without when TLS 1.3 (draft-ietf-tls-tls13-26) is released or when the RSA key exchange is someday deprecated from TLS 1.2 (RFC5246). This draft will outline the use cases for out-of-band TLS decryption, as well as alternative suggestions for monitoring and troubleshooting and the limitations of those alternatives.
    
draft-fieau-cdni-interfaces-https-delegation-04.txt
 CDNI extensions for HTTPS delegation
 
 draft-fieau-cdni-interfaces-https-delegation-04.txt
 Date: 02/07/2018
 Authors: Frederic Fieau, Stephan Emile, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: xml txt
The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document proposes extensions in CDNI Control and Metadata interfaces to setup HTTPS delegation from an Upstream CDN (uCDN) to a Downstream CDN (dCDN).
    
draft-filsfils-spring-large-scale-interconnect-10.txt
 Interconnecting Millions Of Endpoints With Segment Routing
 
 draft-filsfils-spring-large-scale-interconnect-10.txt
 Date: 12/06/2018
 Authors: Clarence Filsfils, Stefano Previdi, Gaurav Dawra, Wim Henderickx, Dave Cooper
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use-case can be applied to the interconnection of massive-scale DC's and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries.
    
draft-filsfils-spring-sr-policy-considerations-01.txt
 SR Policy Implementation and Deployment Considerations
 
 draft-filsfils-spring-sr-policy-considerations-01.txt
 Date: 07/06/2018
 Authors: Clarence Filsfils, Ketan Talaulikar, Przemyslaw Krol, Martin Horneffer, Paul Mattes
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. SR Policy framework enables the instantiation and the management of necessary state on the headend node for flows along a source routed paths using an ordered list of segments associated with their specific SR Policies. This document describes some of the implementation and deployment aspects that are useful for operationalizing the SR Policy architecture.
    
draft-filsfils-spring-sr-traffic-counters-00.txt
 Segment Routing Traffic Accounting Counters
 
 draft-filsfils-spring-sr-traffic-counters-00.txt
 Date: 07/06/2018
 Authors: Clarence Filsfils, Zafar Ali, Martin Horneffer, daniel.voyer@bell.ca, Muhammad Durrani, Robert Raszuk
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. Traffic accounting plays a critical role in network operation. A traffic account solution is required for SR networks that provides the necessary functionality without creating any additional per SR path states in the fabric. This document describes counters for traffic accounting in SR networks.
    
draft-filsfils-spring-srv6-interop-00.txt
 SRv6 interoperability report
 
 draft-filsfils-spring-srv6-interop-00.txt
 Date: 17/03/2018
 Authors: Clarence Filsfils, Francois Clad, Pablo Camarillo, Ahmed Abdelsalam, Stefano Salsano, Olivier Bonaventure, Jakub Horn, Jose Liste
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) can be applied to the IPv6 data plane by leveraging a new type of routing extension header, called Segment Routing Header (SRH). An SRH contains an ordered list, or sequence, of segments representing topological or service-based instructions, or any combination of those. This draft provides an overview of IPv6 Segment Routing (SRv6) implementations and interoperability. It makes an inventory of the various pieces of hardware and software that have been demonstrated to support the processing of an SRH, and details some interoperability scenarios that have been showcased at a public event.
    
draft-filsfils-spring-srv6-network-programming-05.txt
 SRv6 Network Programming
 
 draft-filsfils-spring-srv6-network-programming-05.txt
 Date: 02/07/2018
 Authors: Clarence Filsfils, Pablo Camarillo, John Leddy, daniel.voyer@bell.ca, Satoru Matsushima, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the SRv6 network programming concept and its most basic functions.
    
draft-filyurin-lisp-elp-probing-01.txt
 LISP Explicit Locator Path (ELP) Probing
 
 draft-filyurin-lisp-elp-probing-01.txt
 Date: 14/05/2018
 Authors: Yan Filyurin, Robert Raszuk, Truman Boyes, Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a LISP-TE mechanism to probe an Explicit Locator Path (ELP) for reachability and telemetry data. The mechanism is called ELP-Probing.
    
draft-filyurin-rift-access-networks-00.txt
 RIFT -- Motivation,Additional Requirements and Use Cases in User Access Networks
 
 draft-filyurin-rift-access-networks-00.txt
 Date: 13/06/2018
 Authors: Yan Filyurin
 Working Group: Individual Submissions (none)
 Formats: txt
RIFT is a new specialized dynamic routing protocol originally designed for Clos and Fat Tree Data Center networks. It is designed to work on multilevel network topologies in which nodes in certain level will only connect to nodes in one upper or lower level with optional and non-contiguous intra-level connectivity. While the protocol was originally designed to meet the needs of Massively Scalable Data Centers, its ability to automatically prune the information distribution from higher levels to lower levels, as well as provide optimal routing for intra and inter-level traffic makes it a good match for user access networks, or any network that combines end user access and various compute enabling various network service for these end users. Current directions in distributed computing seek to blur even that distinction. Large distributed networks can be created, where virtual compute units can be in all tiers, combining and crossing many requirements for DC or User Access design. This draft seeks to analyze these requirements.
    
draft-finkelman-cdni-rr-sva-extensions-01.txt
 CDNI SVA Request Routing Extensions
 
 draft-finkelman-cdni-rr-sva-extensions-01.txt
 Date: 16/05/2018
 Authors: Ori Finkelman, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery requests from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).
    
draft-finkelman-cdni-triggers-sva-extensions-00.txt
 CDNI Triggers Interface SVA Extensions
 
 draft-finkelman-cdni-triggers-sva-extensions-00.txt
 Date: 14/06/2018
 Authors: Ori Finkelman, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery request from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).
    
draft-finn-detnet-bounded-latency-01.txt
 DetNet Bounded Latency
 
 draft-finn-detnet-bounded-latency-01.txt
 Date: 02/07/2018
 Authors: Norman Finn, Jean-Yves Le Boudec, Ehsan Mohammadpour, Balazs Varga, Janos Farkas
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents a parameterized timing model for Deterministic Networking so that existing and future standards can achieve bounded latency and zero congestion loss.
    
draft-finzi-priority-switching-scheduler-02.txt
 Priority Switching Scheduler
 
 draft-finzi-priority-switching-scheduler-02.txt
 Date: 30/05/2018
 Authors: Fred Baker, Anais Finzi, Fabrice Frances, Emmanuel Lochin, Ahlem Mifdaoui
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
We detail the implementation of a network scheduler that aims at isolating time constrained and elastic traffic flows from best-effort traffic. This scheduler inherits from the priority scheduler (PS) but dynamically changes the priority of one or several queues. Usual implementations of rate scheduler schemes (such as WRR, DRR, ...) do not allow to efficiently guarantee the capacity dedicated to both AF and BE classes as they mostly provide soft bounds. This means excessive margin is used to ensure the capacity requested and this impacts the number of additional users that could be accepted in the network. To cope with this issue, this memo presents a credit based scheduler mechanism called Priority Switching Scheduler (PSS) that allows a more predictable output rate per traffic class.
    
draft-fioccola-ippm-multipoint-alt-mark-04.txt
 Multipoint Alternate Marking method for passive and hybrid performance monitoring
 
 draft-fioccola-ippm-multipoint-alt-mark-04.txt
 Date: 29/06/2018
 Authors: Giuseppe Fioccola, Mauro Cociglio, Amedeo Sapio, Riccardo Sisto
 Working Group: Individual Submissions (none)
 Formats: txt
The Alternate Marking method, as presented in RFC 8321 [RFC8321], can be applied only to point-to-point flows because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document aims to generalize and expand this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here described is called Multipoint Alternate Marking. Some definitions here introduced extend the scope of RFC 5644 [RFC5644] in the context of alternate marking schema.
    
draft-fioccola-v6ops-ipv6-alt-mark-01.txt
 IPv6 Performance Measurement with Alternate Marking Method
 
 draft-fioccola-v6ops-ipv6-alt-mark-01.txt
 Date: 05/06/2018
 Authors: Giuseppe Fioccola, Gunter Van de Velde, Mauro Cociglio, Praveen Muley
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how the alternate marking method in [RFC8321] can be used as the passive performance measurement method in an IPv6 domain, and will discuss the strengths and the weaknesses of the implementation options available to network operations. It proposes how to extend [RFC7837] to apply alternate marking technique.
    
draft-flanagan-7322bis-03.txt
 RFC Style Guide
 
 draft-flanagan-7322bis-03.txt
 Date: 03/04/2018
 Authors: Heather Flanagan, RFC Editor
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 7322, "RFC Style Guide".
    
draft-fmm-nvo3-pm-alt-mark-02.txt
 Performance Measurement (PM) with Alternate Marking in Network Virtualization Overlays (NVO3)
 
 draft-fmm-nvo3-pm-alt-mark-02.txt
 Date: 25/06/2018
 Authors: Giuseppe Fioccola, Gregory Mirsky, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how the alternate marking method can be used for performance measurement method in a Network Virtualization Overlays (NVO3) Domain. The description aims to be general for NVO3 encapsulations, but is focused to Geneve, recommended by the NVO3 design team [I-D.ietf-nvo3-encap].
    
draft-foglar-ipv6-ull-routing-02.txt
 IPv6 Source Routing for ultralow Latency
 
 draft-foglar-ipv6-ull-routing-02.txt
 Date: 02/03/2018
 Authors: Andreas Foglar, Mike Parker, Theodoros Rokkas
 Working Group: Individual Submissions (none)
 Formats: txt
This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for very fast source routing experimentation using simple forwarding nodes. Research groups evaluate achievable latency reduction for special applications such as radio access networks, industrial networks or other networks requiring very low latency.
    
draft-fossati-tls-ext-header-01.txt
 Record Header Extensions for DTLS
 
 draft-fossati-tls-ext-header-01.txt
 Date: 03/03/2018
 Authors: Thomas Fossati, Nikos Mavrogiannopoulos
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a mechanism to extend the record header in DTLS. To that aim, the DTLS header is modified as follows: the length field is trimmed to 15 bits, and the length's top bit is given the "record header extension indicator" semantics, allowing a sender to signal that one or more record header extensions have been added to this record. We define the generic format of a record header extension and the general rules associated with its handling. Any details regarding syntax, semantics and negotiation of a specific record header extension, are left to future documents.
    
draft-foudil-securitytxt-04.txt
 A Method for Web Security Policies
 
 draft-foudil-securitytxt-04.txt
 Date: 16/07/2018
 Authors: Edwin Foudil, Yakov Shafranovich
 Working Group: Individual Submissions (none)
 Formats: txt
When security risks are discovered by independent security researchers, they often lack the channels to disclose them properly. As a result, security issues may be left unreported. This document defines a standard ("security.txt") to help organizations describe the process for security researchers to follow in order to disclose security vulnerabilities securely.
    
draft-foudil-spss-00.txt
 The Security Policy Specification Standard
 
 draft-foudil-spss-00.txt
 Date: 29/01/2018
 Authors: Edwin Foudil
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a way of standardising the structure, language, and grammar used in security policies. The goal is to reduce ambiguity and confusion that stems from poorly-worded security policies. Organisations and individuals can refer back to this document if their security policy uses definitions found in this document.
    
draft-fregly-regext-rdap-search-regex-04.txt
 Registration Data Access Protocol (RDAP) Search Using POSIX Regular Expressions
 
 draft-fregly-regext-rdap-search-regex-04.txt
 Date: 01/06/2018
 Authors: afregly@verisign.com, Swapneel Sheth, Scott Hollenbeck
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Registration Data Access Protocol (RDAP) provides limited search functionality based on pattern matching. This document describes an RDAP query extension that provides additional search functionality using POSIX extended regular expressions.
    
draft-freytag-troublesome-characters-02.txt
 Those Troublesome Characters: A Registry of Unicode Code Points Needing Special Consideration When Used in Network Identifiers
 
 draft-freytag-troublesome-characters-02.txt
 Date: 30/06/2018
 Authors: Asmus Freytag, John Klensin, Andrew Sullivan
 Working Group: Individual Submissions (none)
 Formats: xml txt
Unicode's design goal is to be the universal character set for all applications. The goal entails the inclusion of very large numbers of characters. It is also focused on written language in general; special provisions have always been needed for identifiers. The sheer size of the repertoire increases the possibility of accidental or intentional use of characters that can cause confusion among users, particularly where linguistic context is ambiguous, unavailable, or impossible to determine. A registry of code points that can be sometimes especially problematic may be useful to guide system administrators in setting parameters for allowable code points or combinations in an identifier system, and to aid applications in creating security aids for users.
    
draft-friel-brski-over-802dot11-01.txt
 BRSKI over IEEE 802.11
 
 draft-friel-brski-over-802dot11-01.txt
 Date: 02/07/2018
 Authors: Owen Friel, Eliot Lear, Max Pritikin, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document outlines the challenges associated with implementing Bootstrapping Remote Secure Key Infrastructures over IEEE 802.11 and IEEE 802.1x networks. Multiple options are presented for discovering and authenticating to the correct IEEE 802.11 SSID. This initial draft is a discussion document and no final recommendations are made on the recommended approaches to take.
    
draft-friel-tls-atls-00.txt
 Application-Layer TLS (ATLS)
 
 draft-friel-tls-atls-00.txt
 Date: 31/01/2018
 Authors: Owen Friel, Richard Barnes, Max Pritikin, Hannes Tschofenig, Mark Baugher
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies how TLS sessions can be established at the application layer over untrusted transport between clients and services for the purposes of establishing secure end-to-end encrypted communications channels. Transport layer encodings for application layer TLS records are specified for HTTP and CoAP transport. Explicit identification of application layer TLS packets enables middleboxes to provide transport services and enforce suitable transport policies for these payloads, without requiring access to the unencrypted payload content. Multiple scenarios are presented identifying the need for end-to-end application layer encryption between clients and services, and the benefits of reusing the well- defined TLS protocol, and a standard TLS stack, to accomplish this are described. Application software architectures for building, and network architectures for deploying application layer TLS are outlined.
    
draft-fujimoto-urn-onem2m-01.txt
 A Uniform Resource Name (URN) Namespace for the oneM2M Partnership Project (oneM2M)
 
 draft-fujimoto-urn-onem2m-01.txt
 Date: 13/03/2018
 Authors: Shingo Fujimoto, Peter Niblett, Miguel Ortega
 Working Group: Applications and Real-Time Area (art)
 Formats: txt xml
This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the oneM2M Partnership Project (oneM2M). oneM2M defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the oneM2M Secretariat.
    
draft-galimbe-ccamp-iv-yang-06.txt
 A YANG model to manage the optical parameters for in a WDM network
 
 draft-galimbe-ccamp-iv-yang-06.txt
 Date: 25/06/2018
 Authors: Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a Yang model that translate the information model to support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functionality. The information model is defined in draft-ietf- ccamp-wson-iv-info and draft-martinelli-ccamp-wson-iv-encode. This document defines proper encoding and extend to the models defined in draft-lee-ccamp-wson-yang tu support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functions The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the multivendor Endpoints and ROADMs
    
draft-galis-anima-autonomic-slice-networking-04.txt
 Autonomic Slice Networking
 
 draft-galis-anima-autonomic-slice-networking-04.txt
 Date: 05/03/2018
 Authors: A. Galis, kiran.makhijani@huawei.com, Delei Yu, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the technical requirements and the related reference model for the intercommunication and coordination among devices in Autonomic Slicing Networking. The goal is to define how the various elements in a network slicing context work and orchestrate together, to describe their interfaces and relations. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG.
    
draft-gandhi-spring-sr-mpls-pm-02.txt
 Performance Measurement in Segment Routing Networks with MPLS Data Plane
 
 draft-gandhi-spring-sr-mpls-pm-02.txt
 Date: 15/07/2018
 Authors: Rakesh Gandhi, Clarence Filsfils, Sagar Soni, daniel.voyer@bell.ca, Stefano Salsano, Pier Ventre, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt
RFC 6374 specifies protocol mechanisms to enable the efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay variation in MPLS networks using probe messages. This document reviews how these mechanisms can be used for Delay and Loss Performance Measurements (PM) in Segment Routing (SR) networks with MPLS data plane (SR-MPLS), for both SR links and end-to-end SR Policies. The performance measurements for SR links are used to compute extended Traffic Engineering (TE) metrics for delay and loss and are advertised in the network using routing protocols.
    
draft-gandhi-spring-udp-pm-01.txt
 UDP Path for In-band Performance Measurement for Segment Routing Networks
 
 draft-gandhi-spring-udp-pm-01.txt
 Date: 09/06/2018
 Authors: Rakesh Gandhi, Clarence Filsfils, Sagar Soni, daniel.voyer@bell.ca, Stefano Salsano, Pier Ventre
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document specifies a procedure for using UDP path for sending and processing in-band probe query and response messages for Performance Measurement (PM). The procedure uses the RFC 6374 defined mechanisms for Delay and Loss performance measurement. The procedure specified is applicable to IPv4, IPv6, SR-MPLS, and SRv6 data planes for both links and end-to-end measurement for SR Policies. This document also defines mechanisms for handling Equal Cost Multipaths (ECMPs) for SR Policies. In addition, this document defines new Return Path Segment List TLV for two-way performance measurement.
    
draft-gao-alto-fcs-06.txt
 ALTO Extension: Flow-based Cost Query
 
 draft-gao-alto-fcs-06.txt
 Date: 02/07/2018
 Authors: J. Zhang, Kai Gao, Junzhuo Wang, Qiao Xiang, Yang Yang
 Working Group: Individual Submissions (none)
 Formats: txt
ALTO cost maps and endpoint cost services map a source-destination pair into a cost value. However, current filter specifications, which define the set of source-destination pairs in an ALTO query, have two limitations: 1) Only very limited address types are supported (IPv4 and IPv6), which is not sufficient to uniquely identify a flow in networks with fine-grained routing, such as the emerging Software Defined Networks; 2) The base ALTO protocol only defines filters enumerating all sources and all destinations, leading to redundant information in the response; 3) Cannot distinguish transmission types of flows in the query, which makes the server hard to respond the accurate resource consumption. To address these three issues, this document extends the base ALTO protocol with a more fine-grained filter type which allows ALTO clients to select only the concerned source-destination pairs and announce the flow-specific information like data transmission type, and a more expressive address space which allows ALTO clients to make queries beyond the limited IP addresses.
    
draft-gao-alto-routing-state-abstraction-08.txt
 Compressing ALTO Path Vectors
 
 draft-gao-alto-routing-state-abstraction-08.txt
 Date: 01/03/2018
 Authors: Kai Gao, xinwang2014@hotmail.com, Qiao Xiang, Chen Gu, Yang Yang, G.Robert Chen
 Working Group: Individual Submissions (none)
 Formats: txt
The path vector extension [I-D.ietf-alto-path-vector] has extended the base ALTO protocol [RFC7285] with the ability to represent a more detailed view of the network which contains not only end-to-end costs but also information about shared bottlenecks. However, the view computed by straw man algorithms can contain redundant information and result in unnecessary communication overhead. The situation gets even worse when certain ALTO extensions are enabled, for example, the incremental update extension [I-D.ietf-alto-incr-update-sse] which continuously pushes data changes to ALTO clients. Redundant information can trigger unnecessary updates. In this document, several algorithms are described which can effectively reduce the redundancy in the network view while still providing the same information as in the original path vectors.
    
draft-gao-bess-evpn-blackhole-00.txt
 EVPN blackhole community extention for Blackholing
 
 draft-gao-bess-evpn-blackhole-00.txt
 Date: 02/07/2018
 Authors: Yuan Gao, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: txt
Ethernet Virtual Private Networks (EVPN) is becoming the de-facto standard-based control plane solution for Data Center and layer-2 Service Provider applications.The risk of hacking and DDos attacks within the EVPN network is general common concern.Blackhole mac is a method used to block hacking or DDos attacks, The network device discard the packets where the source or destionation match the blackhole mac.Normally blackhole mac is mannually configured on the networkdevic,Configure blackhole mac is complex and error-prone task for network operators.This document introduces a blackhole community extension for evpn mac route to distribute the blackhole mac in the EVPN networks.The evpn mac route with blackhole community allows the bgp speaker to notify the recipients the specific mac is a blackhole mac.
    
draft-gao-flexible-session-protocol-00.txt
 Flexible Session Protocol
 
 draft-gao-flexible-session-protocol-00.txt
 Date: 15/07/2018
 Authors: Jason Gao
 Working Group: Individual Submissions (none)
 Formats: txt
FSP is a connection-oriented transport layer protocol that provides support for mobility, multi-homing and multi-path by introducing the concept of 'upper layer thread ID'. It introduces the concept of transmit transaction to facilitate a quad-party sub-protocol of shared secret installation. It provides transport layer features of zero round-trip connection multiplication and on-the-wire compression, in addition to ubiquitous message authentication with optional encryption service.
    
draft-garciamorchon-t2trg-automated-iot-security-00.txt
 Automated IoT Security
 
 draft-garciamorchon-t2trg-automated-iot-security-00.txt
 Date: 02/07/2018
 Authors: Oscar Garcia-Morchon, Thorsten Dahm
 Working Group: Individual Submissions (none)
 Formats: txt
The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs are well-recognized and and many standardization steps for providing security have been taken, for example, the specification of Constrained Application Protocol (CoAP) over Datagram Transport Layer Security (DTLS). However, the design space of IoT applications and systems is complex and exposed to multiple types of threats. In particular, threats keep evolving at a fast pace while many IoT systems are rarely updated and still remain operational for decades. This document has three main parts: First, it summarizes exemplary security threats and suitable mitigation strategies to protect against multiple types of threats. Second, it describes a comprehensive agile security framework to integrate existing security processes such as risk asssement or vulnerability assessment in the lifecycle of a smart object in an IoT application. Thus, instead of having a security configuration that is fixed at manufacturing time, our approach allows us to apply a - security profile - on the device tailored for a specific environment at any point of time. Third, we discuss the concept of security profiles and give examples of them. The core of our agile security approach relies on two protocols: the Protocol for Automatic Security Configuration (PASC) and the Protocol for Automatic Vulnerability Assessment (PAVA). PACS is executed during the onboarding phase of a smart object in an IoT system and is in charge of automatically performing a risk assessment and assigning a security profile to defeat the identified risks. The assigned security profile fits the specific environment and threat model of the application in which the device has been deployed. PAVA is executed during the operation of the IoT object and ensures that vulnerabilities in the smart object and IoT system are discovered in a proactive way. These two protocols can benefit users, manufactures and operators by automating IoT security. We describe a few examplary security profiles that could be applicable in different application areas and automatically configured by means of PASC and PAVA.
    
draft-gavrichenkov-dnsop-dnssapi-00.txt
 Domain Name System Service Application Programming Interface
 
 draft-gavrichenkov-dnsop-dnssapi-00.txt
 Date: 05/03/2018
 Authors: Artyom Gavrichenkov
 Working Group: Individual Submissions (none)
 Formats: txt xml
Managed DNS services are widely used to maintain DNS zones. Virtually all of them have an API of some sort, in most cases an XML- RPC or JSON-RPC API, while most of them lack the support of zone transfers. The latter is unlikely to change any time soon due to the reasons outlined below. This document describes a protocol, a common denominator of existing API protocols, that both a service provider and its customer can use to exchange information about DNS zones and policies.
    
draft-geng-bier-sr-multicast-deployment-00.txt
 MVPN using Segment Routing and BIER for High Reachability Multicast Deployment
 
 draft-geng-bier-sr-multicast-deployment-00.txt
 Date: 02/07/2018
 Authors: Liang Geng, Lei Wang, Jingrong Xie, Mike McBride, Gang Yan
 Working Group: Individual Submissions (none)
 Formats: xml txt
Bit Index Explicit Replication (BIER) introduces a stateless multicast approach for a specific IGP area. Segment Routing introduces an approach for end-to-end stateless deployment for both inter-area and inter-as scenarios. This document proposes a MVPN using Segment Routing and BIER for a high reachability multicast deployment.
    
draft-geng-coms-architecture-02.txt
 COMS Architecture
 
 draft-geng-coms-architecture-02.txt
 Date: 05/03/2018
 Authors: Liang Geng, Li Qiang, Jose Lucena, Pablo Ameigeiras, Diego Lopez, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the overall architecture of a COMS based network slicing system. COMS works on the top level network slice orchestrator which directly communicates with the network slice provider and enables the technology-independent network slice management.
    
draft-geng-coms-problem-statement-04.txt
 Problem Statement of Common Operation and Management of Network Slicing
 
 draft-geng-coms-problem-statement-04.txt
 Date: 05/03/2018
 Authors: Liang Geng, Slawomir, Li Qiang, kiran.makhijani@huawei.com, A. Galis, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses the problem statement of Common Operation and Management of Network Slicing (COMS). The purpose of this document is to identify the problem space of COMS and discuss the approach COMS is using to match the top-down network slice management concern with the underlay technologies. Furthermore, the role of a common information model is introduced and corresponding design principles are also discussed.
    
draft-geng-detnet-conf-yang-03.txt
 DetNet Configuration YANG Model
 
 draft-geng-detnet-conf-yang-03.txt
 Date: 15/07/2018
 Authors: Xuesong Geng, Mach Chen, Zhenqiang Li, Reshad Rahman
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for Deterministic Networking (DetNet). It covers the model of DetNet device, service layer and transport layer. It also covers the DetNet topology YANG model.
    
draft-geng-detnet-info-distribution-02.txt
 IGP-TE Extensions for DetNet Information Distribution
 
 draft-geng-detnet-info-distribution-02.txt
 Date: 05/03/2018
 Authors: Xuesong Geng, Mach Chen, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
There are requirements in diverse industries to establish multi-hop paths for characterized flows with bounded end-to-end latency and extremely low packet loss rate. Deterministic Networking (DetNet) can provide service satisfying the requirements. This document describes extensions to IGP-TE, including OSPF-TE and ISIS-TE to distribute information of DetNet, which can be used for DetNet path computation/selection. This document only covers the mechanisms by which DetNet information is distributed. The mechanisms for measuring, calculating or configuring DetNet capabilities, resources and other relevant parameters are out of the scope.
    
draft-geng-detnet-requirements-bounded-latency-00.txt
 Technical Requirements of Bounded Latency in Large-scale DetNet Deployment
 
 draft-geng-detnet-requirements-bounded-latency-00.txt
 Date: 02/07/2018
 Authors: Liang Geng, Lei Wang, Li Qiang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document summarizes the technical requirements of bounded latency of DetNet system in large-scale deployment.
    
draft-geng-iiot-edge-computing-problem-statement-01.txt
 Problem Statement of Edge Computing on Premises for Industrial IoT
 
 draft-geng-iiot-edge-computing-problem-statement-01.txt
 Date: 05/03/2018
 Authors: Liang Geng, Mingui Zhang, Mike McBride, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the concept of Beyond Edge Computing (BEC) which brings edge computing capabilities down to the level of customers' premises for industrial IoT use cases. The purpose of the document is to discuss the general problem statement of BEC including capabilities, and use cases. Potential technical gaps in IETF problem scope that are related to BEC are also evaluated.
    
draft-geng-pim-bier-sr-multicast-deployment-00.txt
 MVPN using Segment Routing and BIER for High Reachability Multicast Deployment
 
 draft-geng-pim-bier-sr-multicast-deployment-00.txt
 Date: 02/07/2018
 Authors: Liang Geng, Lei Wang, Jingrong Xie, Mike McBride, Gang Yan
 Working Group: Individual Submissions (none)
 Formats: txt xml
Bit Index Explicit Replication (BIER) introduces a stateless multicast approach for a specific IGP area. Segment Routing introduces an approach for end-to-end stateless deployment for both inter-area and inter-as scenarios. This document proposes a MVPN using Segment Routing and BIER for a high reachability multicast deployment.
    
draft-ggalimbe-ccamp-flex-if-lmp-05.txt
 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application
 
 draft-ggalimbe-ccamp-flex-if-lmp-05.txt
 Date: 25/06/2018
 Authors: Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze
 Working Group: Individual Submissions (none)
 Formats: txt
This experimental memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) adding a set of parameters related to multicarrier DWDM interfaces to be used in Spectrum Switched Optical Networks (sson).
    
draft-ggalimbe-ccamp-flexigrid-carrier-label-04.txt
 Signaling extensions for Media Channel sub-carriers configuration in Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) Optical Line Systems.
 
 draft-ggalimbe-ccamp-flexigrid-carrier-label-04.txt
 Date: 28/06/2018
 Authors: Gabriele Galimberti, Domenico Fauci, Andrea Zanardi, Lorenzo Galvagni
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines the signaling extensions for managing Spectrum Switched Optical Network (SSON) parameters shared between the Client and the Network and inside the Network in accordance to the model described in RFC 7698. The extensions are in accordance and extending the parameters defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872].
    
draft-ginsberg-isis-rfc5306bis-01.txt
 Restart Signaling for IS-IS
 
 draft-ginsberg-isis-rfc5306bis-01.txt
 Date: 28/06/2018
 Authors: Les Ginsberg, Paul Wells
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechansim for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding plane state. This allows the neighbors to maintain their adjacencies until the router has restarted, but also allows the neighbors to bring the adjacencies down in the event of other topology changes. This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 5306.
    
draft-ginsberg-lsr-isis-rfc7810bis-00.txt
 IS-IS Traffic Engineering (TE) Metric Extensions
 
 draft-ginsberg-lsr-isis-rfc7810bis-00.txt
 Date: 09/04/2018
 Authors: Les Ginsberg, Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Qin Wu
 Working Group: Individual Submissions (none)
 Formats: txt xml
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810.
    
draft-gmsm-bess-evpn-bfd-01.txt
 Fault Management for EVPN networks
 
 draft-gmsm-bess-evpn-bfd-01.txt
 Date: 27/05/2018
 Authors: Vengada Govindan, Mallik Mudigonda, Ali Sajassi, Gregory Mirsky, Donald Eastlake
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a proactive, in-band network OAM mechanism to detect loss of continuity and miss-connection faults that affect unicast and multi-destination paths, used by Broadcast, unknown Unicast and Multicast traffic, in an EVPN network. The mechanisms proposed in the draft use the widely adopted Bidirectional Forwarding Detection (BFD) protocol.
    
draft-gondwana-jmap-imapdata-00.txt
 JMAP Extension for imap data
 
 draft-gondwana-jmap-imapdata-00.txt
 Date: 21/03/2018
 Authors: Bron Gondwana
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document adds additional properties to the JMAP Email and Mailbox objects so that servers which also support IMAP can expose metadata about the IMAP Mailstore via JMAP.
    
draft-gont-6man-non-stable-iids-04.txt
 Recommendation on Temporary IPv6 Interface Identifiers
 
 draft-gont-6man-non-stable-iids-04.txt
 Date: 24/03/2018
 Authors: Fernando Gont, Christian Huitema, Suresh Krishnan, Guillermo Gont, Madelen Corbo
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a set of requirements for generating temporary addresses, and clarifies the stability requirements for IPv6 addresses, allowing for the use of only temporary addresses.
    
draft-gont-numeric-ids-generation-02.txt
 On the Generation of Transient Numeric Identifiers
 
 draft-gont-numeric-ids-generation-02.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers and analyzes their security and privacy properties.
    
draft-gont-numeric-ids-history-03.txt
 Unfortunate History of Transient Numeric Identifiers
 
 draft-gont-numeric-ids-history-03.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. It describes a number of algorithms that have been employed in real implementations to meet such requirements and analyzes their security and privacy properties. Additionally, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it provides recommendations for future protocol specifications regarding the specification of the aforementioned numeric identifiers.
    
draft-gont-numeric-ids-sec-considerations-02.txt
 Security Considerations for Transient Numeric Identifiers Employed in Network Protocols
 
 draft-gont-numeric-ids-sec-considerations-02.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
For more than 30 years, a large number of implementations of the TCP/ IP protocol suite have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection, to information leakage that could be exploited for pervasive monitoring. The root of these issues has been, in many cases, the poor selection of transient identifiers in such protocols, usually as a result of an insufficient or misleading specifications. This document formally updates RFC3552, such that RFCs are required to perform a security and privacy analysis of the transient numeric identifiers they specify.
    
draft-gont-predictable-numeric-ids-02.txt
 Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols
 
 draft-gont-predictable-numeric-ids-02.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. It describes a number of algorithms that have been employed in real implementations to meet such requirements and analyzes their security and privacy properties. Additionally, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it provides recommendations for future protocol specifications regarding the specification of the aforementioned numeric identifiers.
    
draft-gont-taps-address-analysis-00.txt
 Problem Statement Regarding IPv6 Address Usage
 
 draft-gont-taps-address-analysis-00.txt
 Date: 21/03/2018
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the security, privacy, and interoperability implications of IPv6 addresses based on a number of properties (such as address scope, stability, and usage type).
    
draft-gont-taps-address-usage-problem-statement-00.txt
 Problem Statement Regarding IPv6 Address Usage
 
 draft-gont-taps-address-usage-problem-statement-00.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the security and privacy implications of IPv6 addresses based on a number of properties (such as address scope, stability, and usage type), and identifies gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses.
    
draft-gont-taps-sockets-api-limitations-00.txt
 Problem Statement Regarding Limitations of the Sockets API for IPv6 Address Usage
 
 draft-gont-taps-sockets-api-limitations-00.txt
 Date: 21/03/2018
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This identifies gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses.
    
draft-gont-tcpm-tcp-seq-validation-03.txt
 On the Validation of TCP Sequence Numbers
 
 draft-gont-tcpm-tcp-seq-validation-03.txt
 Date: 05/03/2018
 Authors: Fernando Gont, David Borman
 Working Group: Individual Submissions (none)
 Formats: txt
When TCP receives packets that lie outside of the receive window, the corresponding packets are dropped and either an ACK, RST or no response is generated due to the out-of-window packet, with no further processing of the packet. Most of the time, this works just fine and TCP remains stable, especially when a TCP connection has unidirectional data flow. However, there are three scenarios in which packets that are outside of the receive window should still have their ACK field processed, or else a packet war will take place. The aforementioned issues have affected a number of popular TCP implementations, typically leading to connection failures, system crashes, or other undesirable behaviors. This document describes the three scenarios in which the aforementioned issues might arise, and formally updates RFC 793 such that these potential problems are mitigated.
    
draft-google-self-published-geofeeds-02.txt
 Self-published IP Geolocation Data
 
 draft-google-self-published-geofeeds-02.txt
 Date: 28/07/2013
 Authors: Erik Kline, Krzysztof Duleba, Zoltan Szamonek
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document records a format whereby a network operator can publish a mapping of IP address ranges to simplified geolocation information, colloquially termed a geolocation "feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. At least one consumer (Google) has incorporated these ad hoc feeds into a geolocation data pipeline.
    
draft-gould-carney-regext-registry-02.txt
 Registry Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-carney-regext-registry-02.txt
 Date: 27/06/2018
 Authors: James Gould, Lin Jia, rcarney@godaddy.com, Jody Kolker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning registry zones (e.g. top-level domains) in a Domain Name Registry. The attributes of a registry zone include the features and policies of the registry zone.
    
draft-gould-idn-table-06.txt
 Extensible Provisioning Protocol (EPP) Internationalized Domain Name (IDN) Table Mapping
 
 draft-gould-idn-table-06.txt
 Date: 16/04/2018
 Authors: James Gould, Francisco Obispo
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an Extensible Provisioning Protocol (EPP) mapping for getting Internationalized Domain Name (IDN) Table information for the registration of IDNs, using the EPP domain name mapping, and optionally with the IDN mapping extension. An IDN Table defines the valid set of characters (code points) that can be used in a domain name. Code points may overlap across IDN Tables and the IDN Tables supported by the servers are up to server policy. The IDN Table information can be used to validate an IDN prior to registration, can be cached by the client for pre-validation, can be used to select the best IDN Table for the IDN, and can be used to know if and what IDN Table Identifier to pass in a domain create.
    
draft-gould-regext-launch-policy-00.txt
 Launch Phase Policy Extensions Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-launch-policy-00.txt
 Date: 31/05/2018
 Authors: James Gould
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an Extensible Provisioning Protocol (EPP) extension of the Registry Mapping to define the server policy of the Launch Phase EPP extension. The server policy of the Launch Phase EPP extension includes the MAYs, SHOULDs, and options implemented by the server.
    
draft-gould-regext-login-security-01.txt
 Login Security Extension for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-login-security-01.txt
 Date: 14/06/2018
 Authors: James Gould, Matthew Pozun
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response.
    
draft-gpujol-oauth-atrl-00.txt
 OAuth 2.0 Token Revocation List
 
 draft-gpujol-oauth-atrl-00.txt
 Date: 14/07/2018
 Authors: Guillaume Pujol
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a format and a standardised uri for a Token Revocation List. An OAuth 2.0 authorization server can use those to expose a current list of revoked access tokens identifiers that it previously issued, intended for use by OAuth 2.0 resource servers.
    
draft-gu-grow-bmp-vpn-label-00.txt
 VPN Label Monitoring Using BMP
 
 draft-gu-grow-bmp-vpn-label-00.txt
 Date: 02/07/2018
 Authors: Yunan Gu, iqjie@mail.ustc.edu.cn, Penghui Mi, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
The BGP Monitoring Protocol (BMP) is designed to monitor BGP running status, such as BGP peer relationship establishment and termination and route updates. This document provides a method of collecting the VPN label using BMP, as well as an implementation example.
    
draft-gu-network-monitoring-protocol-00.txt
 Network Monitoring Protocol (NMP)
 
 draft-gu-network-monitoring-protocol-00.txt
 Date: 16/07/2018
 Authors: Yunan Gu, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
To evolve towards automated network OAM (Operations, administration and management), the monitoring of control plane protocols is a fundamental necessity. In this document, a network monitoring protocol (NMP) is proposed to provision the running status information of control plane protocols, e.g., IGP (Interior Gateway Protocol) and other protocols. By collecting the protocol monitoring data and reporting it to the NMP monitoring server in real-time, NMP can facilitate network troubleshooting. In this document, NMP for IGP troubleshooting are illustrated to showcase the necessity of NMP. IS-IS is used as the demonstration protocol, and the case of OSPF (Open Shortest Path First) and other control protocols will be elaborated in the future versions. The operations of NMP are described, and the NMP message types and message formats are defined in the document.
    
draft-gu-network-mornitoring-protol-00.txt
 Network Monitoring Protocol (NMP)
 
 draft-gu-network-mornitoring-protol-00.txt
 Date: 02/07/2018
 Authors: Yunan Gu, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
To enable automated network OAM (Operations, administration and management), the availability of network protocol running status information is a fundamental step. In this document, a network monitoring protocol (NMP) is proposed to provision the information related to running status of IGP (Interior Gateway Protocol) and other control protocols. It can facilitate the network troubleshooting of control protocols in a network domain. Typical network issues are illustrated as the usecases of NMP for ISIS to showcase the necessity of NMP. Then the operations and the message formats of NMP for ISIS are defined. In this document ISIS is used as the illustration protocol, and the case of OSPF and other control protocols will be included in the future version.
    
draft-guichard-sfc-nsh-sr-02.txt
 NSH and Segment Routing Integration for Service Function Chaining (SFC)
 
 draft-guichard-sfc-nsh-sr-02.txt
 Date: 18/06/2018
 Authors: Jim Guichard, Haoyu Song, Jeff Tantsura, Joel Halpern, Wim Henderickx, Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes two application scenarios where Network Service Header (NSH) and Segment Routing (SR) techniques can be deployed together to support Service Function Chaining (SFC) in an efficient manner while maintaining separation of the service and transport planes as originally intended by the SFC architecture. In the first scenario, an NSH-based SFC is created using SR as the transport between SFFs. SR in this case is just one of many encapsulations that could be used to maintain the transport- independent nature of NSH-based service chains. In the second scenario, SR is used to represent each service hop of the NSH-based SFC as a segment within the segment-list. SR and NSH in this case are integrated. In both scenarios SR is responsible for steering packets between SFFs along a given SFP while NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata. These application scenarios demonstrate that NSH and SR can work jointly and complement each other leaving the network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure, and still maintain an end-to-end service plane using NSH.
    
draft-gundavelli-dmm-mfa-00.txt
 Mobility-aware Floating Anchor (MFA)
 
 draft-gundavelli-dmm-mfa-00.txt
 Date: 24/02/2018
 Authors: Sri Gundavelli, Marco Liebsch, Satoru Matsushima
 Working Group: Individual Submissions (none)
 Formats: txt
IP mobility protocols are designed to allow a mobile node to remain reachable while moving around in the network. The currently deployed mobility management protocols are anchor-based approaches, where a mobile node's IP sessions are anchored on a central node. The mobile node's IP traffic enters and exits from this anchor node and it remains as the control point for all subscriber services. This architecture based on fixed IP anchors comes with some complexity and there is some interest from the mobile operators to eliminate the use of fixed anchors, and other residual elements such as the overlay tunneling that come with it. This document describes a new approach for realizing a mobile user- plane that does not require fixed IP anchors. The architectural- basis for this approach is the separation of control and user plane, and the use of programmability constructs of the user-plane for traffic steering. This approach is referred to as, Mobility-aware Floating Anchor (MFA).
    
draft-gundogan-icnrg-ccnlowpan-02.txt
 ICN Adaptation to LowPAN Networks (ICN LoWPAN)
 
 draft-gundogan-icnrg-ccnlowpan-02.txt
 Date: 16/07/2018
 Authors: Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch, Christopher Scherb, Claudio Marxer, Christian Tschudin
 Working Group: Individual Submissions (none)
 Formats: xml txt
In this document, a convergence layer for CCNx and NDN over IEEE 802.15.4 LoWPAN networks is defined. A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by 6LoWPAN is extended to include new dispatch types for CCNx and NDN. Additionally, the link fragmentation component of the 6LoWPAN dispatching framework is applied to ICN chunks. Basic improvements in efficiency are advised by stateless and stateful compression schemes.
    
draft-gundogan-icnrg-pub-iot-02.txt
 Publish-Subscribe Deployment Option for NDN in the Constrained Internet of Things
 
 draft-gundogan-icnrg-pub-iot-02.txt
 Date: 05/03/2018
 Authors: Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch
 Working Group: Individual Submissions (none)
 Formats: txt xml
Constrained IoT devices often operate more efficiently in a loosely coupled environment without maintaining end-to-end connectivity between nodes. Information Centric Networking naturally supports this demand by replicated data distribution and hop wise forwarding. This document outlines a deployment option for NDN in low-power and lossy networks (LLNs) that follows a publish-subscribe pattern. The proposed protocol scheme simplifies name-based routing significantly and facilitates even large off-duty cycles for constrained nodes.
    
draft-gutmann-scep-10.txt
 Simple Certificate Enrolment Protocol
 
 draft-gutmann-scep-10.txt
 Date: 01/03/2018
 Authors: Peter Gutmann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using CMS (formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.
    
draft-gutmann-tls-lts-10.txt
 TLS 1.2 Update for Long-term Support
 
 draft-gutmann-tls-lts-10.txt
 Date: 22/03/2018
 Authors: Peter Gutmann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an update of TLS 1.2 for long-term support on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis.
    
draft-haas-bfd-large-packets-00.txt
 BFD Encapsulated in Large Packets
 
 draft-haas-bfd-large-packets-00.txt
 Date: 19/03/2018
 Authors: Jeffrey Haas, Albert Fu
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode.
    
draft-haberman-iasa20dt-recs-02.txt
 IASA 2.0 Design Team Recommendations
 
 draft-haberman-iasa20dt-recs-02.txt
 Date: 18/04/2018
 Authors: Brian Haberman, Jari Arkko, Leslie Daigle, Jason Livingood, Joseph Hall, Eric Rescorla
 Working Group: Individual Submissions (none)
 Formats: txt
The arrangements relating to administrative support for the IETF were created more than ten years ago. Since then, there has been considerable change in the tasks and in our own expectations. The IETF community has discussed these changes and the problems they cause. The community has some sense of the properties they expect from future arrangements, including those related to structure, organization, personnel, and transparency. This document is a product of a design team, focused on providing additional information to the community about solution options, as well as supporting analysis of the implications of those options. To be clear, the community is responsible for adopting any recommendations or making any final decisions.
    
draft-haindl-lisp-gb-atn-01.txt
 Ground-Based LISP for the Aeronautical Telecommunications Network
 
 draft-haindl-lisp-gb-atn-01.txt
 Date: 05/06/2018
 Authors: Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras, Victor Moreno, Fabio Maino
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization. The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures.
    
draft-hakala-urn-nbn-rfc3188bis-02.txt
 Using National Bibliography Numbers as Uniform Resource Names
 
 draft-hakala-urn-nbn-rfc3188bis-02.txt
 Date: 14/06/2018
 Authors: Juna Hakala
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
National Bibliography Numbers (NBNs) are used by the national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such as ISBN. A URN (Uniform Resource Names) namespace for NBNs was established in 2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems. This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) compliant to RFC 8141 is included.
    
draft-hall-censorship-tech-05.txt
 A Survey of Worldwide Censorship Techniques
 
 draft-hall-censorship-tech-05.txt
 Date: 25/05/2018
 Authors: Joseph Hall, Michael Aaron, Ben Jones, Nick Feamster
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the technical mechanisms used by censorship regimes around the world to block or impair Internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties being exploited and mechanisms used to censor end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended to be a reference.
    
draft-hallambaker-dare-container-01.txt
 Data At Rest Encryption: DARE Container
 
 draft-hallambaker-dare-container-01.txt
 Date: 15/07/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes DARE Container, a message and file syntax that allows a sequence of data frames to be represented with cryptographic integrity, signature and encryption enhancements to be constructed in an append only format. The format supports data integrity checks using digest chains and Merkle trees. The simplest supports efficient append only write operations and efficient read operations in either the forward or reverse direction. Support for efficient random-access reads may be provided through the use of binary trees or index records appended to the end of the file. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-dare-container.html [1] .
    
draft-hallambaker-dare-message-01.txt
 Data At Rest Encryption Part 1: DARE Message
 
 draft-hallambaker-dare-message-01.txt
 Date: 15/07/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Data At Rest Encryption (DARE) message syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-dare-message.html [1] .
    
draft-hallambaker-jbcd-container-02.txt
 JBCD Container
 
 draft-hallambaker-jbcd-container-02.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jbcd-container.html [1] .
    
draft-hallambaker-json-key-exchange-03.txt
 JSON Key Exchange
 
 draft-hallambaker-json-key-exchange-03.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The JSON Key Exchange This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-json-key- exchange.html [1] .
    
draft-hallambaker-json-web-service-10.txt
 JSON Web Service Binding Version 1.0
 
 draft-hallambaker-json-web-service-10.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The JSON Web Binding (JWB) describes a standardized approach to implementing Web Services. Services are advertised using the DNS SRV and HTTP Well Known Service conventions. Messages may be authenticated or authenticated and encrypted at the message layer in addition to any transport and/or network layer security. Service messages are encoded in JSON using Internet time format for Date-Time fields and Base64urlencoding for binary objects. This document specifies Version 1.0 of JWB which uses HTTP/1.1 for transport. Use of the multiple stream capabilities of HTTP/2 or QUIC is outside the scope of this document. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-json-web-service.html [1] .
    
draft-hallambaker-jsonbcd-13.txt
 Binary Encodings for JavaScript Object Notation: JSON-B,JSON-C,JSON-D
 
 draft-hallambaker-jsonbcd-13.txt
 Date: 15/07/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
Three binary encodings for JavaScript Object Notation (JSON) are presented. JSON-B (Binary) is a strict superset of the JSON encoding that permits efficient binary encoding of intrinsic JavaScript data types. JSON-C (Compact) is a strict superset of JSON-B that supports compact representation of repeated data strings with short numeric codes. JSON-D (Data) supports additional binary data types for integer and floating-point representations for use in scientific applications where conversion between binary and decimal representations would cause a loss of precision. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html [1] .
    
draft-hallambaker-mesh-app-02.txt
 Mathematical Mesh: Application Profiles
 
 draft-hallambaker-mesh-app-02.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The use of the Mathematical Mesh to manage cryptographic keys for use with Mail and SSH is described. The format of the application profiles is described with examples. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-app.html [1] .
    
draft-hallambaker-mesh-developer-07.txt
 Mathematical Mesh: Reference Implementation
 
 draft-hallambaker-mesh-developer-07.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes the Mesh reference code and how to install, run and make use of it in applications. It does not form a part of the Mesh specifications and is not normative. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-developer.html [1] .
    
draft-hallambaker-mesh-platform-03.txt
 Mathematical Mesh: Platform Configuration
 
 draft-hallambaker-mesh-platform-03.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes how Mesh profiles are stored for application access on Windows, Linux and OSX platforms. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-platform.html [1] .
    
draft-hallambaker-mesh-reference-09.txt
 Mathematical Mesh: Reference
 
 draft-hallambaker-mesh-reference-09.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-reference.html [1] .
    
draft-hallambaker-sin-03.txt
 Strong Internet Names (SIN)
 
 draft-hallambaker-sin-03.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
A Strong Internet Name is a DNS name that contains a cryptographic binding to a security policy governing interpretation of the name. This document describes the use of Strong Internet Names formed using a Uniform Data Fingerprint of a PKIX trust root and outlines the additional capabilities that might be supported in a purpose written policy language. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-sin.html [1] .
    
draft-hallambaker-udf-10.txt
 Uniform Data Fingerprint (UDF)
 
 draft-hallambaker-udf-10.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Uses of UDF fingerprints include but are not limited to creating Strong Internet Names (SINs). Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-udf.html [1] .
    
draft-hallambaker-web-service-discovery-00.txt
 DNS Web Service Discovery
 
 draft-hallambaker-web-service-discovery-00.txt
 Date: 14/06/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a standardized approach to discovering Web Service Endpoints from a DNS name. Services are advertised using the DNS SRV and TXT records and the HTTP Well Known Service conventions. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker- web-service- discovery.html [1] .
    
draft-haluska-sipping-directory-assistance-11.txt
 Considerations for Information Services and Operator Services Using SIP
 
 draft-haluska-sipping-directory-assistance-11.txt
 Date: 15/08/2011
 Authors: John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell
 Working Group: Real-time Applications and Infrastructure Area (rai)
 Formats: txt
Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers.
    
draft-hamarsheh-behave-biav2-05.txt
 Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA)
 
 draft-hamarsheh-behave-biav2-05.txt
 Date: 19/01/2011
 Authors: Ala Hamarsheh
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a mechanism for hosts with any network connectivity (IPv4 only, IPv6 only, or dual IPv4/IPv6 connectivity) to run applications of any capability (IPv4 only, IPv6 only, or dual IPv4/IPv6) without any modification to those applications. It is a generalisation of a previous experimental protocol called "Bump-in-the-API" (BIA) [RFC3338]. New mechanism of BIA allows a changeover between the application layer and the IP communication layers from IPv4 to IPv6 and vice versa or IPv6 to IPv4 and vice versa, without requiring those applications to be converted in addressing capabilities, effectively shielding the application layer from IPv4 or IPv6 connectivity. This is considered by the authors to be one of the essential conditions for the transition to IPv6 in the Internet to be successful.
    
draft-han-tsvwg-cc-00.txt
 A New Congestion Control in Bandwidth Guaranteed Network
 
 draft-han-tsvwg-cc-00.txt
 Date: 03/03/2018
 Authors: Lin Han, Yingzhen Qu, Thomas Nadeau
 Working Group: Individual Submissions (none)
 Formats: xml txt
In bandwidth guaranteed networks, network resources are reserved before a TCP session starts transmitting data. This draft proposes a new TCP congestion control algorithm used in bandwidth guaranteed networks. It is an extension to the current TCP standards.
    
draft-han-tsvwg-ip-transport-qos-00.txt
 Resource Reservation Protocol for IP Transport QoS
 
 draft-han-tsvwg-ip-transport-qos-00.txt
 Date: 02/07/2018
 Authors: Lin Han, Yingzhen Qu, Lijun Dong, Thomas Nadeau, Kevin Smith
 Working Group: Individual Submissions (none)
 Formats: txt
IP has been known as best-effort data transmission. However there are new applications requiring IP to provide deterministic services in terms of bandwidth and latency, such as network based AR/VR (Augmented Reality and Virtual Reality), industrial internet. This document proposes a solution in IPv6 that can be used by transport layer protocols to guarantee certain level of service quality. This new service is fined-grained and could apply to individual or aggregated TCP/UDP flow(s).
    
draft-handrews-json-schema-01.txt
 JSON Schema: A Media Type for Describing JSON Documents
 
 draft-handrews-json-schema-01.txt
 Date: 19/03/2018
 Authors: Austin Wright, Henry Andrews
 Working Group: Individual Submissions (none)
 Formats: txt xml
JSON Schema defines the media type "application/schema+json", a JSON- based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/ schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents.
    
draft-handrews-json-schema-hyperschema-01.txt
 JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON
 
 draft-handrews-json-schema-hyperschema-01.txt
 Date: 19/01/2018
 Authors: Henry Andrews, Austin Wright
 Working Group: Individual Submissions (none)
 Formats: txt xml
JSON Schema is a JSON-based format for describing JSON data using various vocabularies. This document specifies a vocabulary for annotating JSON documents with hyperlinks. These hyperlinks include attributes describing how to manipulate and interact with remote resources through hypermedia environments such as HTTP, as well as determining whether the link is usable based on the instance value. The hyperlink serialization format described in this document is also usable independent of JSON Schema.
    
draft-handrews-json-schema-validation-01.txt
 JSON Schema Validation: A Vocabulary for Structural Validation of JSON
 
 draft-handrews-json-schema-validation-01.txt
 Date: 19/03/2018
 Authors: Austin Wright, Henry Andrews, Geraint Luff
 Working Group: Individual Submissions (none)
 Formats: txt xml
JSON Schema (application/schema+json) has several purposes, one of which is JSON instance validation. This document specifies a vocabulary for JSON Schema to describe the meaning of JSON documents, provide hints for user interfaces working with JSON data, and to make assertions about what a valid document must look like.
    
draft-handrews-relative-json-pointer-01.txt
 Relative JSON Pointers
 
 draft-handrews-relative-json-pointer-01.txt
 Date: 19/01/2018
 Authors: Geraint Luff, Henry Andrews
 Working Group: Individual Submissions (none)
 Formats: txt xml
JSON Pointer is a syntax for specifying locations in a JSON document, starting from the document root. This document defines an extension to the JSON Pointer syntax, allowing relative locations from within the document.
    
draft-hao-bess-evpn-centralized-df-01.txt
 Centralized EVPN DF Election
 
 draft-hao-bess-evpn-centralized-df-01.txt
 Date: 20/03/2018
 Authors: Donald Eastlake, Hao Weiguo, Lili Wang, Li Yizhou, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a centralized DF Designated Forwarder election mechanism to be used between an SDN (Software Defined Network) controller and each PE (Provider Edge) device in an EVPN network. Such a mechanism overcomes the issues of current standalone DF election defined in RFC 7432. A new BGP capability and an additional DF Election Result Route Type are specified to support this centralized DF mechanism.
    
draft-hardie-path-signals-03.txt
 Path Signals
 
 draft-hardie-path-signals-03.txt
 Date: 02/04/2018
 Authors: Ted Hardie
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the nature of signals seen by on-path elements, contrasting implicit and explicit signals. For example, TCP's state mechanics uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on- path network elements lack those signals. This document recommends that explict signals be used by transports which encrypt their state mechanics. It also recommends that a signal be exposed to the path only when the signal's originator intends that it be used by the network elements on the path.
    
draft-hardjono-oauth-decentralized-02.txt
 Decentralized Service Architecture for OAuth2.0
 
 draft-hardjono-oauth-decentralized-02.txt
 Date: 25/03/2018
 Authors: Thomas Hardjono
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an alternative service architecture for user- centric control of the sharing of resources following the UMA model, such as personal data, using the decentralized peer-to-peer computing paradigm. The term 'control' is used here to denote the full capacity of the user to freely select (i) the entities with whom to share resources (e.g. data), and (ii) the entities which provide services implementing user-controlled resource sharing. The peer-to- peer service architecture uses a set of computing nodes called OAuth2.0 Nodes (ON) that are part of a peer-to-peer network as the basis for the decentralized service architecture.
    
draft-hardt-oauth-distributed-01.txt
 Distributed OAuth
 
 draft-hardt-oauth-distributed-01.txt
 Date: 12/06/2018
 Authors: Dick Hardt, Brian Campbell, Nat Sakimura
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Distributed OAuth profile enables an OAuth client to discover what authorization server or servers may be used to obtain access tokens for a given resource, and what parameter values to provide in the access token request.
    
draft-hardt-oauth-mutual-02.txt
 Reciprocal OAuth
 
 draft-hardt-oauth-mutual-02.txt
 Date: 16/01/2018
 Authors: Dick Hardt
 Working Group: Individual Submissions (none)
 Formats: xml txt
There are times when a user has a pair of protected resources that would like to request access to each other. While OAuth flows typically enable the user to grant a client access to a protected resource, granting the inverse access requires an additional flow. Reciprocal OAuth enables a more seemless experience for the user to grant access to a pair of protected resources.
    
draft-hares-i2nsf-capability-data-model-07.txt
 I2NSF Capability YANG Data Model
 
 draft-hares-i2nsf-capability-data-model-07.txt
 Date: 23/03/2018
 Authors: Susan Hares, Jaehoon Jeong, Jinyong Kim, Robert Moskowitz, linqiushi@huawei.com
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG data model for capabilities that enables an I2NSF user to control various network security functions in network security devices.
    
draft-haresh-sushrut-mib-classification-01.txt
 SNMPD to use cache and shared database based on MIB Classification
 
 draft-haresh-sushrut-mib-classification-01.txt
 Date: 29/03/2012
 Authors: Haresh Khandelwal
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device.
    
draft-harkins-pkex-05.txt
 Public Key Exchange
 
 draft-harkins-pkex-05.txt
 Date: 24/01/2018
 Authors: Dan Harkins
 Working Group: Crypto Forum (cfrg)
 Formats: txt
This memo describes a password-authenticated protocol to allow two devices to exchange "raw" (uncertified) public keys and establish trust that the keys belong to their respective identities.
    
draft-harkins-tls-dragonfly-03.txt
 Secure Password Ciphersuites for Transport Layer Security (TLS)
 
 draft-harkins-tls-dragonfly-03.txt
 Date: 02/07/2018
 Authors: Dan Harkins
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The exchange is called TLS-PWD. The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to off-line dictionary attack.
    
draft-hartke-core-pending-02.txt
 "Pending" Responses for the Constrained Application Protocol (CoAP)
 
 draft-hartke-core-pending-02.txt
 Date: 26/02/2018
 Authors: Peter van der Stok, Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a new type of response for the Constrained Application Protocol (CoAP) called a "Pending" response. A CoAP server can use a Pending response to indicate that it has accepted a request but has not yet started processing it or that processing the request will take longer than a client is typically willing to wait for a response.
    
draft-hartke-t2trg-coral-05.txt
 The Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-05.txt
 Date: 25/04/2018
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as two specialized serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata.
    
draft-hartke-t2trg-data-hub-01.txt
 Thing-to-Thing Data Hub
 
 draft-hartke-t2trg-data-hub-01.txt
 Date: 02/03/2018
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The Thing-to-Thing Data Hub is a RESTful, hypermedia-driven Web application that can be used in Thing-to-Thing communication to share data items such as thing descriptions, configurations, resource descriptions, or firmware updates at a central location.
    
draft-haynes-nfsv4-delstid-00.txt
 Extending the Opening of Files in NFSv4.2
 
 draft-haynes-nfsv4-delstid-00.txt
 Date: 01/04/2018
 Authors: Thomas Haynes
 Working Group: Individual Submissions (none)
 Formats: txt
The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file. This grants the client the right to cache metadata on the file locally. This document presents serveral refinements to both the opeing and delegating of the file to the client.
    
draft-he-ccamp-gmpls-signaling-smp-00.txt
 GMPLS Signaling Extensions for Shared Mesh Protection
 
 draft-he-ccamp-gmpls-signaling-smp-00.txt
 Date: 02/07/2018
 Authors: He Jia
 Working Group: Individual Submissions (none)
 Formats: txt
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of a shared mesh protection (SMP) mechanism, where the difference between SMP and shared mesh restoration (SMR) is also identified. ITU-T Recommendation G.873.3 [G873.3] defines the protection switching operation and associated protocol for shared mesh protection (SMP) at the optical data unit (ODU) layer. This document updates RFC 4872 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the shared mesh protection.
    
draft-hegde-spring-node-protection-for-sr-te-paths-03.txt
 Node Protection for SR-TE Paths
 
 draft-hegde-spring-node-protection-for-sr-te-paths-03.txt
 Date: 02/07/2018
 Authors: Shraddha Hegde, Chris Bowers, Stephane Litkowski, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment routing supports the creation of explicit paths using adjacency-sids, node-sids, and binding-sids. 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 label stack describing an SR-TE path to provide protection against node failures.
    
draft-heide-nwcrg-rlnc-00.txt
 Random Linear Network Coding (RLNC)-Based Symbol Representation
 
 draft-heide-nwcrg-rlnc-00.txt
 Date: 07/02/2018
 Authors: Janus Heide, Shirley Shi, Muriel Medard, Vince Chook
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the use of Random Linear Network Coding (RLNC) schemes for erasure correction in data transfer, with an emphasis on RLNC encoded symbol representations in data packets. Both block and sliding window RLNC code implementations are described. By providing erasure correction using randomly generated repair symbols, such RLNC-based schemes offer advantages in accommodating varying frame sizes and dynamically changing connections, reducing the need for feedback, and lowering the amount of state information needed at the sender and receiver.
    
draft-heitz-idr-extra-extended-community-01.txt
 BGP Extra Extended Community
 
 draft-heitz-idr-extra-extended-community-01.txt
 Date: 17/07/2018
 Authors: Jakob Heitz, Ali Sajassi, Ignas Bagdonas
 Working Group: Individual Submissions (none)
 Formats: txt xml
Auto-derived identifiers are used by applications to enable zero configuration features. Such identifiers are often a combination of primitive identifiers and are thus longer. In addition, existing identifiers have grown longer. IP addresses have grown from 4 octets to 16. AS numbers have grown from 2 octets to 4. In order to accommodate such longer identifiers in BGP extended communities, this document defines a new BGP path attribute, the Extra Extended Communities attribute. It is similar to the Extended Community, but is 24 octets long. Communities are mostly used within ASes under a single administration or between neighboring ASes. Limiting the spread of communities beyond their intended reach and polluting the internet at large is complex and error prone. To simplify this, enhanced transitivity options are provided.
    
draft-herbert-6man-icmp-limits-03.txt
 ICMPv6 errors for discarding packets due to processing limits
 
 draft-herbert-6man-icmp-limits-03.txt
 Date: 15/01/2018
 Authors: Tom Herbert
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication so it cannot take action to address the cause of discarded packets. This document defines ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may be able to modify what it sends in future packets to avoid subsequent packet discards.
    
draft-herbert-fast-01.txt
 Firewall and Service Tickets
 
 draft-herbert-fast-01.txt
 Date: 26/06/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Firewalls and Service Tickets protocol. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network service to be applied. Applications request tickets from a local agent in the network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to a packets. A single ticket may provide both firewall and service ticket information. Tickets are sent in either IPv6 Destination options or Hop-by-Hop options.
    
draft-herbert-idgroups-00.txt
 Identifier groups
 
 draft-herbert-idgroups-00.txt
 Date: 03/02/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a means to create logical identifier groups to manage identifiers in a mapping system for identifier-locator protocols. An identifier group consists of identifiers that have similar properties in the context of the mapping system. Identifier groups facilitate bulk operations on the mapping system that would affect multiple identifiers. A primary use case for this is to facilitate mobility of devices that are associated with possibly thousands or even millions of identifiers.
    
draft-herbert-idloc-fast-00.txt
 Lightweight Identifier-Locator Mapping Using FAST
 
 draft-herbert-idloc-fast-00.txt
 Date: 26/06/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This proposal provides a method to implement identifier to locator mapping in the datapath without the need to access an in-network mapping database or cache. Mappings are encoded in Firewall and Service Tickets (FAST) tickets as locator information. When a packet is sent by a mobile node, a ticket is attached that providers the locator to use in the return path. Peer nodes receive packets with these tickets, cache the tickets in a flow context, and then attach them to packets they send as reflected tickets. When a packet with a reflected ticket enters an identifier-locator domain, the ticket is parsed to extract the locator. That locator is then used to send the packet to the appropriate destination over a network overlay.
    
draft-herbert-ila-mobile-01.txt
 Identifier Locator Addressing for Mobile User-Plane
 
 draft-herbert-ila-mobile-01.txt
 Date: 05/03/2018
 Authors: Tom Herbert, Kalyani Bogineni
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the applicability of Identifier Locator Addressing (ILA) to the user-plane of mobile networks. ILA allows a means to implement network overlays without the overhead, complexities, or anchor points associated with encapsulation. This solution facilitates highly efficient packet forwarding and provides low latency and scalability in mobile networks. ILA can be used in conjunction with techniques such as network slices and Network Function Virtualization to achieve optimal service based forwarding.
    
draft-herbert-ila-motivation-00.txt
 Identifier Locator Addressing: Problem areas,Motivation,and Use Cases
 
 draft-herbert-ila-motivation-00.txt
 Date: 22/01/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the problems, motivation, and use cases for Identifier-Locator Addressing.
    
draft-herbert-intarea-ila-01.txt
 Identifier-locator addressing for IPv6
 
 draft-herbert-intarea-ila-01.txt
 Date: 05/03/2018
 Authors: Tom Herbert, Petr Lapukhov
 Working Group: Individual Submissions (none)
 Formats: txt
This specification describes identifier-locator addressing (ILA) for IPv6. Identifier-locator addressing differentiates between location and identity of a network node. Part of an address expresses the immutable identity of the node, and another part indicates the location of the node which can be dynamic. Identifier-locator addressing can be used to efficiently implement overlay networks for network virtualization as well as solutions for use cases in mobility.
    
draft-herbert-ipv6-prefix-address-privacy-00.txt
 Privacy in IPv6 Network Prefix Assignment
 
 draft-herbert-ipv6-prefix-address-privacy-00.txt
 Date: 19/02/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses privacy concerns around network prefix assignment in IPv6. It evaluates the privacy threat, proposes a set of ideal criteria for strong privacy, and suggests solutions to achieve a high degree of privacy in addressing.
    
draft-hesmans-mptcp-socket-03.txt
 A socket API to control Multipath TCP
 
 draft-hesmans-mptcp-socket-03.txt
 Date: 05/03/2018
 Authors: benjamin.hesmans@uclouvain.be, Olivier Bonaventure, Fabien Duchene
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an enhanced socket API to allow applications to control the operation of a Multipath TCP stack.
    
draft-hevroni-oauth-seamless-flow-00.txt
 Seamless OAuth 2.0 Client Assertion Grant
 
 draft-hevroni-oauth-seamless-flow-00.txt
 Date: 24/03/2018
 Authors: Omer Hevroni
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines the use of a One Time Password, encoded as JSON Web Token (JWS) Bearer Token, as a means for requesting an OAuth 2.0 access token as well as for client authentication.
    
draft-hfa-bier-pim-signaling-01.txt
 PIM Signaling Through BIER Core
 
 draft-hfa-bier-pim-signaling-01.txt
 Date: 07/02/2018
 Authors: Hooman Bidgoli, Andrew Dolganow, Jayant Kotalwar, Fengman Xu, IJsbrand Wijnands, mankamana mishra
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the procedure needed for PIM Joins and Prunes to be signaled through a BIER core. Allowing PIM routers to run traditional PIM multicast services through a BIER core.
    
draft-historic-simple-ip-00.txt
 Simple Internet Protocol (SIP) Specification
 
 draft-historic-simple-ip-00.txt
 Date: 17/07/2018
 Authors: Steve Deering, Robert Hinden
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is published for the historical record. It was one of the candidates for the IETF's Next Generation (IPng) work, and became the basis for IPv6. The publication date of the original Internet Draft was November 10, 1992. This document specifies a new version of IP called SIP, the Simple Internet Protocol. It also describes the changes needed to ICMP, IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast.
    
draft-hj-bier-mldp-signaling-00.txt
 M-LDP Signaling Through BIER Core
 
 draft-hj-bier-mldp-signaling-00.txt
 Date: 02/07/2018
 Authors: Hooman Bidgoli, Andrew Dolganow, Jayant Kotalwar
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the procedure needed for mLDP tunnels to be signaled and stitched through a BIER core. Allowing LDP routers to run traditional Multipoint LDP services through a BIER core.
    
draft-hl-dnsop-cache-filling-00.txt
 Additional Method for Filling DNS Caches
 
 draft-hl-dnsop-cache-filling-00.txt
 Date: 02/03/2018
 Authors: Paul Hoffman, Matt Larson
 Working Group: Individual Submissions (none)
 Formats: txt
DNS recursive resolvers do not always have access to the authoritative resolvers from which they need to get information. For example, when the DNS root servers are under DDoS attack, a recursive resolver may not be able to get an answer from any of the root servers. This document describes how resolvers can populate their caches with zone information, and keep their cache populated, using out-of-band mechanisms that do not rely on the DNS protocol. The protocol is primarily designed for the root zone, but can apply to any zone that wants to participate by publishing values to be cached.
    
draft-hmm-dmm-5g-uplane-analysis-00.txt
 User Plane Protocol and Architectural Analysis on 3GPP 5G System
 
 draft-hmm-dmm-5g-uplane-analysis-00.txt
 Date: 29/06/2018
 Authors: Shunsuke Homma, Takuya Miyasaka, Satoru Matsushima, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side.
    
draft-hodges-webauthn-registries-01.txt
 Registries for Web Authentication (WebAuthn)
 
 draft-hodges-webauthn-registries-01.txt
 Date: 28/02/2018
 Authors: Jeff Hodges, Giridhar Mandyam, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines IANA registries for W3C Web Authentication attestation statement formats and extension identifiers.
    
draft-hoehlhubmer-https-addon-07.txt
 Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol
 
 draft-hoehlhubmer-https-addon-07.txt
 Date: 25/11/2013
 Authors: Walter Hoehlhubmer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations.
    
draft-hoehrmann-cp-collation-01.txt
 The i;codepoint collation
 
 draft-hoehrmann-cp-collation-01.txt
 Date: 14/09/2010
 Authors: Bjoern Hoehrmann
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations.
    
draft-hoffman-andrews-caa-simplification-03.txt
 DNS Certification Authority Authorization (CAA) Resource Record
 
 draft-hoffman-andrews-caa-simplification-03.txt
 Date: 23/02/2018
 Authors: Phillip Hallam-Baker, Rob Stradling, Jacob Hoffman-Andrews
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
 Formats: txt xml
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers.
    
draft-hoffman-c2pq-03.txt
 The Transition from Classical to Post-Quantum Cryptography
 
 draft-hoffman-c2pq-03.txt
 Date: 12/02/2018
 Authors: Paul Hoffman
 Working Group: Crypto Forum (cfrg)
 Formats: txt
Quantum computing is the study of computers that use quantum features in calculations. For over 20 years, it has been known that if very large, specialized quantum computers could be built, they could have a devastating effect on asymmetric classical cryptographic algorithms such as RSA and elliptic curve signatures and key exchange, as well as (but in smaller scale) on symmetric cryptographic algorithms such as block ciphers, MACs, and hash functions. There has already been a great deal of study on how to create algorithms that will resist large, specialized quantum computers, but so far, the properties of those algorithms make them onerous to adopt before they are needed. Small quantum computers are being built today, but it is still far from clear when large, specialized quantum computers will be built that can recover private or secret keys in classical algorithms at the key sizes commonly used today. It is important to be able to predict when large, specialized quantum computers usable for cryptanalysis will be possible so that organization can change to post-quantum cryptographic algorithms well before they are needed. This document describes quantum computing, how it might be used to attack classical cryptographic algorithms, and possibly how to predict when large, specialized quantum computers will become feasible.
    
draft-hoffman-dns-in-json-16.txt
 Representing DNS Messages in JSON
 
 draft-hoffman-dns-in-json-16.txt
 Date: 12/05/2018
 Authors: Paul Hoffman
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search those without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of this document can be described in other documents for specific applications and usage scenarios.
    
draft-hohendorf-secure-sctp-25.txt
 Secure SCTP
 
 draft-hohendorf-secure-sctp-25.txt
 Date: 04/03/2018
 Authors: Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP.
    
draft-hollenbeck-regext-rdap-openid-09.txt
 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect
 
 draft-hollenbeck-regext-rdap-openid-09.txt
 Date: 29/06/2018
 Authors: Scott Hollenbeck
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect.
    
draft-homma-dmm-5gs-id-loc-coexistence-01.txt
 Co-existence of 3GPP 5GS and Identifier Locator Separation Architecture
 
 draft-homma-dmm-5gs-id-loc-coexistence-01.txt
 Date: 15/05/2018
 Authors: Shunsuke Homma, Kenta Kawakami, Arashmid Akhavain
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an approach to introduce Identifier Locator Separation architecture into 3GPP 5GS with low-impact on its specification, and shows the features and considerations of this approach.
    
draft-homma-nfvrg-slice-gateway-00.txt
 Gateway Function for Network Slicing
 
 draft-homma-nfvrg-slice-gateway-00.txt
 Date: 02/07/2018
 Authors: Shunsuke Homma, Xavier de Foy, A. Galis
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the roles and requirements for a slice gateway that is a data plane function or function group for connecting/disconnecting and compose/decompose network slice subnets and providing network slices from end to end. The interworkings between management and control elements at the management and control planes with the gateway function for controlling and orchestrating end-to-end network slices are also presented in this document.
    
draft-hong-i2nsf-nsf-monitoring-data-model-04.txt
 YANG Data Model for Monitoring I2NSF Network Security Functions
 
 draft-hong-i2nsf-nsf-monitoring-data-model-04.txt
 Date: 02/07/2018
 Authors: Dongjin Hong, Jaehoon Jeong, Jinyong Kim, Susan Hares, Liang Xia, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document proposes a YANG data model for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) system. If the monitoring of NSFs is performed in a comrehensive way, it is possible to detect the indication of malicious activity, anomalous behavior or the potential sign of denial of service attacks in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only a data tree to specify an information model for monitoring NSFs, but also the corresponding YANG data model for monitoring NSFs.
    
draft-hong-icnrg-ccnx-nrs-02.txt
 CCNx Extension for Name Resolution Service
 
 draft-hong-icnrg-ccnx-nrs-02.txt
 Date: 02/07/2018
 Authors: jhong@etri.re.kr, Taewan You, Yong-Geun Hong
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents the CCNx extension for Name Resolution Service (NRS). It describes TLV-based CCNx messages for NRS and modification of CCNx forwarder where the messages for NRS are working.
    
draft-hong-icnrg-icnnrs-01.txt
 Architectural Considerations of ICN using Name Resolution Service
 
 draft-hong-icnrg-icnnrs-01.txt
 Date: 02/07/2018
 Authors: jhong@etri.re.kr, Taewan You, Yong-Geun Hong
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses architectural considerations and implications of Information-Centric Networking (ICN) related to the usage of the Name Resolution Service (NRS). It describes how ICN architecture changes and what implications are in the routing system when NRS is utilized in ICN.
    
draft-hong-iot-edge-computing-00.txt
 Problem Statement of IoT integrated with Edge Computing
 
 draft-hong-iot-edge-computing-00.txt
 Date: 02/07/2018
 Authors: jhong@etri.re.kr, Yong-Geun Hong, Joo-Sang Youn
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes new challenges for IoT services issued by the changes of the IoT environment. In order to address those new challenges, the integration of Edge computing and IoT has been emerged as a promising solution. This document provides the concept of IoT integrated with Edge computing as well as its use cases to discuss the benefits and challenges of Edge computing mainly focused on IoT data. The direction of Edge computing for IoT should be discussed in IETF/IRTF.
    
draft-hongcs-6lo-sbcn-00.txt
 Scheduling to Increase Lifetime for Low Energy Body-Centric Wearable Networks
 
 draft-hongcs-6lo-sbcn-00.txt
 Date: 09/02/2018
 Authors: Choong Hong, ameen@khu.ac.kr, Seung Moon
 Working Group: Individual Submissions (none)
 Formats: txt
Recent advances in Internet of Things(IoT) have increased the usage of sensing technologies. Breakthroughs is microelectronics have increased the use of wearable devices to monitor human body functions and its surroundings. A typical wearable device has low resources in terms of power and processing capabilities. Reducing the energy consumption is one of the key design factors in a wearable network so that the devices may work for longer duration. Idle listening and overhearing are major causes of energy consumption. These issues can be resolved by maximizing the sleeping time of a device (switched off) and avoid unnecessary wakeup time (idle listening) to save energy. An external wakeup scheduling to handle the sleep/wakeup cycle of a device can be adapted. This document describes how a 2wakeup scheduling using an out-of-bound external wake up mechanism can work to successfully increase the lifetime of a typical body-centric wearable network (S-BCN).
    
draft-hou-6lo-plc-04.txt
 Transmission of IPv6 Packets over PLC Networks
 
 draft-hou-6lo-plc-04.txt
 Date: 02/07/2018
 Authors: Jianqiang Hou, Bing Liu, Yong-Geun Hong, Xiaojun Tang, Charles Perkins
 Working Group: Individual Submissions (none)
 Formats: txt
Power Line Communication (PLC), namely using the electric-power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The inherent advantage of existing electricity infrastructure facilitates the expansion of PLC deployments, and moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as ITU-T G.9903, IEEE 1901.1, IEEE 1901.2 and IEEE 1901.2a.
    
draft-housley-cms-mix-with-psk-04.txt
 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)
 
 draft-housley-cms-mix-with-psk-04.txt
 Date: 03/04/2018
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support them, if current syntax the does not accommodated them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key.
    
draft-housley-cms-mts-hash-sig-10.txt
 Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS)
 
 draft-housley-cms-mts-hash-sig-10.txt
 Date: 01/07/2018
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the conventions for using the Merkle Tree Signatures (MTS) digital signature algorithm with the Cryptographic Message Syntax (CMS). The MTS algorithm is one form of hash-based digital signature.
    
draft-housley-hash-of-root-key-cert-extn-00.txt
 Hash Of Root Key Certificate Extension
 
 draft-housley-hash-of-root-key-cert-extn-00.txt
 Date: 02/03/2018
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a certificate extension that is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor.
    
draft-housley-suit-cose-hash-sig-04.txt
 Use of the Hash-based Signature Algorithm with CBOR Object Signing and Encryption (COSE)
 
 draft-housley-suit-cose-hash-sig-04.txt
 Date: 02/07/2018
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the conventions for using the Leighton-Micali Signature (LMS) algorithm for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax.
    
draft-housley-suite-b-to-historic-05.txt
 Reclassification of Suite B Documents to Historic Status
 
 draft-housley-suite-b-to-historic-05.txt
 Date: 30/04/2018
 Authors: Russ Housley, Lydia Zieglar
 Working Group: Individual Submissions (none)
 Formats: txt
This document reclassifies the RFCs related to the U.S. National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so. This document moves seven informational RFCs to Historic Status: RFC 5759, RFC 6239, RFC 6318, RFC 6379, RFC 6380, RFC 6403, and RFC 6460. In addition, this document moves three obsolete informational RFCs to Historic Status: RFC 4869, RFC 5008, and RFC 5430.
    
draft-housley-tls-tls13-cert-with-extern-psk-00.txt
 TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key
 
 draft-housley-tls-tls13-cert-with-extern-psk-00.txt
 Date: 01/03/2018
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK).
    
draft-hoyland-tls-layered-exported-authenticator-00.txt
 Layered Exported Authenticators in TLS
 
 draft-hoyland-tls-layered-exported-authenticator-00.txt
 Date: 25/06/2018
 Authors: Jonathan Hoyland
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an extension that allows for Exported Authenticators (EAs) to authenticate each other. The extension includes a reference to a previous EA. An EA containing this extension constitues an attestation of the authenticity of the referenced EA.
    
draft-hsmit-bmp-extensible-routemon-msgs-00.txt
 BMP Extensible Route-Monitoring Messages
 
 draft-hsmit-bmp-extensible-routemon-msgs-00.txt
 Date: 18/07/2018
 Authors: Henk Smit
 Working Group: Individual Submissions (none)
 Formats: xml txt
The BGP Monitoring Protocol (BMP) is defined in RFC7854. Most of the types of messages in BMP are extensible via the mechanism of TLVs. However, the most important type of message, the route-monitoring message, has a fixed format. This document proposes a relatively small change to the format of BMP route-monitoring messages. The new format of route-monitoring messages is no longer fixed-format, but tlv-encoded. This document also proposes to split the route-monitoring message-type into 3 new message-types. For Adj-RIB-In, Adj-RIB-Out and Loc-RIB. This document proposes two types of TLVs to be used in this new format. A TLV to report the BGP update message itself. And a flags- field TLV, to report state of the reported routes.
    
draft-hspab-5gangip-atticps-00.txt
 IP Issues and Associated Gaps in Fifth Generation Wireless Networks
 
 draft-hspab-5gangip-atticps-00.txt
 Date: 29/01/2018
 Authors: Dirk Hugo, Behcet Sarikaya
 Working Group: Individual Submissions (none)
 Formats: txt
This document attempts to make the case for new work that need to be developed to be used among various virtualized functions and the end user which may be moving. First a set of use cases on tunneling, charging, mobility anchors are developed and then the steps of proposed new work is described next.
    
draft-httpi-12.txt
 Need for an httpi intelligent service
 
 draft-httpi-12.txt
 Date: 15/07/2018
 Authors: pradeep xplorer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the need for an httpi protocol similar to https/http used for intelligent surfing of information.
    
draft-hu-bess-srv6-vpn-bypass-sid-00.txt
 Enhance IPv6-Segment-Routing-based EVPN VPWS All Active Usage
 
 draft-hu-bess-srv6-vpn-bypass-sid-00.txt
 Date: 02/07/2018
 Authors: Chongyang Hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the extensions to enhance SRv6 EVPN VPWS all- active Reliability.
    
draft-hu-lsr-isis-path-mtu-00.txt
 IS-IS Extensions for Path MTU
 
 draft-hu-lsr-isis-path-mtu-00.txt
 Date: 30/06/2018
 Authors: Zhibo Hu, Yongqing Zhu, Zhenbin Li, Longfei Dai
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
Segment routing (SR) leverages the source routing mechanism. It allows for a flexible definition of end-to-end paths with IGP topologies by encoding paths as sequences of topological sub-paths which is called segments. These segments are advertised by the link- state routing protocols (IS-IS and OSPF). Unlike the MPLS, SR does not have the specific path construction signaling so that it cannot support the Path MTU. This draft provides the necessary IS-IS extensions about the Path MTU that need to be used on SR.
    
draft-hu-lsr-network-automatic-optimization-00.txt
 Network Automatic Optimization Based on Dynamic Adjustment of IGP Metrics
 
 draft-hu-lsr-network-automatic-optimization-00.txt
 Date: 02/07/2018
 Authors: Zhibo Hu, Gang Yan, Junda Yao
 Working Group: Individual Submissions (none)
 Formats: txt
The centralized traffic engineering technology adopts centralized calculation, PCE/SDN performs centralized calculation based on the collected link-status and TE information collected by BGP-LS/IGP, so that the traffic in the network is optimized to the optimization goal. The distributed traffic engineering technology uses IGP to calculate the shortest path. Each node in the network calculates the next hop to a destination address based on the same algorithm and network topology. Each algorithm can calculate a shortest path tree in the entire network, which can reduce the amount of calculation, so that the hard convergence time of TE can be close to the convergence time of IGP. The distributed computing and management methods can not co-ordinate management of network bandwidth resources. As a result, network bandwidth resources can not be planned in an integrated manner, bandwidth resources are wasted, and even tunnels cannot be established. This document attempts to discuss a automatic network optimization function of the distributed traffic engineering technology by the method of dynamically adjusting the link Metric.
    
draft-hu-nvo3-vxlan-gpe-extension-for-vbng-00.txt
 VXLAN GPE Extension for Packets Exchange Between Control and User Plane of vBNG
 
 draft-hu-nvo3-vxlan-gpe-extension-for-vbng-00.txt
 Date: 13/06/2018
 Authors: Shujun Hu, Fengwei Qin, Zhenqiang Li, Zitao Wang, Ting Ao
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document briefly describes the architecture of control plane and user plane separated vBNG and define the extension of VXLAN-GPE for PPPoE/IPoE dialup packets exchange between control plane and user plane.
    
draft-hu-rtgwg-cu-separation-yang-model-03.txt
 YANG Data Model for Configuration Interface of Control-Plane and User- Plane separation BNG
 
 draft-hu-rtgwg-cu-separation-yang-model-03.txt
 Date: 19/03/2018
 Authors: fangwei hu, RongRong Hua, Sujun Hu, Rong Gu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the YANG data model for operation management of Control-Plane and User-Plane separation BNG (Broadband Network Gateway).
    
draft-hu-spring-segment-routing-rsvp-te-interop-00.txt
 Segment Routing interworking with RSVP-TE
 
 draft-hu-spring-segment-routing-rsvp-te-interop-00.txt
 Date: 30/06/2018
 Authors: Zhibo Hu, Gang Yan, Xia Chen, Junda Yao
 Working Group: Individual Submissions (none)
 Formats: txt
A Segment Routing (SR) node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. Segment Routing (SR) is a protocol designed to forward packets on the network based on the concept of source routing. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. It simplifies the MPLS control protocol, simplifies the configuration of the network, and can achieve SDN better. Resource Reservation Protocol - Traffic Engineering (RSVP-TE) has the ability of path planning and resource reservation. In the process of traditional network evolution to Segment Routing, there will inevitably be coexistence of RSVP-TE and Segment Routing. The Document describes how to interact with nodes that support Segment Routing capabilities and nodes that support RSVP-TE capabilities.
    
draft-hu-spring-sr-tp-use-case-01.txt
 Segment Routing Transport Profile Use Case
 
 draft-hu-spring-sr-tp-use-case-01.txt
 Date: 04/03/2018
 Authors: fangwei hu, Quan Xiong, Gregory Mirsky, Weiqiang Cheng
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the use case and requirement of segment routing is used in MPLS-TP network.
    
draft-huang-bier-te-encapsulation-00.txt
 Encapsulation for BIER-TE
 
 draft-huang-bier-te-encapsulation-00.txt
 Date: 04/03/2018
 Authors: Rachel Huang, Toerless Eckert, Naiwen Wei, Pascal Thubert
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes an enhanced encapsulation for BIER to support BIER, BIER-TE and a control word.
    
draft-huang-detnet-single-path-pref-01.txt
 Single-path PREF
 
 draft-huang-detnet-single-path-pref-01.txt
 Date: 13/06/2018
 Authors: Daniel Huang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies PREF on the single path for low-rate traffic, and illustrates in details the implementation solutions as well as the impacts on the data plane specified in [I-D.ietf-detnet-dp-alt].
    
draft-huang-rsca-sdm-eon-00.txt
 RSCA method with Dividing Frequency Slots Area in Space Division Multiplexing Elastic Optical Networks
 
 draft-huang-rsca-sdm-eon-00.txt
 Date: 21/05/2018
 Authors: Shanguo Huang, Shan Yin, Shuang Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This documentary provides a routing, spectrum and core assignment method with the dividing frequency slots area for space division multiplexing elastic optical networks. This effective RSCA method to solve this problem better. The proposed method utilizes the Frequency Slots Area (FSA) concept and first-last fit policy of frequency slots assignment to have less spectrum fragments, lower crosstalk, smaller traffic blocking probability and higher spectrum resource utilization.
    
draft-huitema-dnssd-prireq-00.txt
 DNS-SD Privacy and Security Requirements
 
 draft-huitema-dnssd-prireq-00.txt
 Date: 30/06/2018
 Authors: Christian Huitema
 Working Group: Extensions for Scalable DNS Service Discovery (dnssd)
 Formats: xml txt
DNS-SD (DNS Service Discovery) normally discloses information about devices offering and requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, serious privacy problems arise. We analyze the requirements of a privacy respecting discovery service.
    
draft-huitema-dnssd-privacyscaling-01.txt
 DNS-SD Privacy Scaling Tradeoffs
 
 draft-huitema-dnssd-privacyscaling-01.txt
 Date: 30/06/2018
 Authors: Christian Huitema
 Working Group: Extensions for Scalable DNS Service Discovery (dnssd)
 Formats: xml txt
DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. The draft currently progressing in the DNS-SD Working Group assumes peer-to-peer pairing between the service to be discovered and each of its clients. This has good security properties, but creates scaling issues, because each server needs to publish as many announcements as it has paired clients. This leads to large number of operations when servers are paired with many clients. Different designs are possible. For example, if there was only one server "discovery key" known by each authorized client, each server would only have to announce a single record, and clients would only have to process one response for each server that is present on the network. Yet, these designs will present different privacy profiles, and pose different management challenges. This draft analyses the tradeoffs between privacy and scaling in a set of different designs, using either shared secrets or public keys.
    
draft-huitema-quic-dnsoquic-05.txt
 Specification of DNS over Dedicated QUIC Connections
 
 draft-huitema-quic-dnsoquic-05.txt
 Date: 29/06/2018
 Authors: Christian Huitema, Melinda Shore, Allison Mankin, Sara Dickinson, Jana Iyengar
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the use of QUIC to provide transport privacy for DNS. The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of- line blocking issues inherent with TCP and provides more efficient error corrections than UDP. DNS over QUIC (DNS/QUIC) has privacy properties similar to DNS over TLS specified in RFC7858, and performance similar to classic DNS over UDP.
    
draft-hunt-secevent-sstp-00.txt
 Symmetric SET Transfer Protocol
 
 draft-hunt-secevent-sstp-00.txt
 Date: 22/03/2018
 Authors: Phil Hunt, Anthony Nadalin
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines how security event tokens (SETs) may be exchanged between a client and service provider using HTTP POST over TLS using a symmetric format. The specification supports three modes of operation: "push", "pull", and "push-pull" bi-directional SET exchange. The specification also defines a simple acknowledge mechanism allowing parties to confirm delivery.
    
draft-huque-dnsop-multi-provider-dnssec-03.txt
 Multi Provider DNSSEC models
 
 draft-huque-dnsop-multi-provider-dnssec-03.txt
 Date: 01/07/2018
 Authors: Shumon Huque, Pallavi Aras, John Dickinson, Jan Vcelak
 Working Group: Domain Name System Operations (dnsop)
 Formats: txt
Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment can have some challenges depending on the configuration and feature set in use. This document will present several deployment models that may be suitable.
    
draft-huque-dnssec-alg-nego-02.txt
 Algorithm Negotiation in DNSSEC
 
 draft-huque-dnssec-alg-nego-02.txt
 Date: 20/01/2018
 Authors: Shumon Huque, Haya Shulman, Shane Kerr
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a DNS extension that allows a DNS client to specify a list of DNSSEC algorithms, in preference order, that the client desires to use. A DNS server upon receipt of this extension can choose to selectively respond with DNSSEC signatures using the most preferred algorithm they support. This mechanism may make it easier for DNS zone operators to support signing zone data simultaneously with multiple DNSSEC algorithms, without significantly increasing the size of DNS responses. It will also allow an easier way to transition to new algorithms while still retaining support for older DNS validators that do not yet support the new algorithms.
    
draft-hyun-i2nsf-nsf-triggered-steering-06.txt
 Service Function Chaining-Enabled I2NSF Architecture
 
 draft-hyun-i2nsf-nsf-triggered-steering-06.txt
 Date: 02/07/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, Park Jung-Soo, Susan Hares
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document describes an architecture of the I2NSF framework using security function chaining for security policy enforcement. Security function chaining enables composite inspection of network traffic by steering the traffic through multiple types of network security functions according to the information model for NSFs capabilities in the I2NSF framework. This document explains the additional components integrated into the I2NSF framework and their functionalities to achieve security function chaining. It also describes representative use cases to address major benefits from the proposed architecture.
    
draft-hyun-i2nsf-registration-interface-dm-05.txt
 I2NSF Registration Interface YANG Data Model
 
 draft-hyun-i2nsf-registration-interface-dm-05.txt
 Date: 17/07/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, Park Jung-Soo
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a YANG data model for I2NSF Registration Interface between Security Controller and Developer's Management System. The data model is required for NSF instance registration and dynamic life cycle management of NSF instances.
    
draft-hyun-i2nsf-registration-interface-im-06.txt
 Registration Interface Information Model
 
 draft-hyun-i2nsf-registration-interface-im-06.txt
 Date: 17/07/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, Park Jung-Soo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an information model for Interface to Network Security Functions (I2NSF) Registration Interface between Security Controller and Developer's Management System (DMS). The information model is required to support NSF instance via the registration interface. This document explains the procedures over I2NSF registration interface for these functionalities. It also describes the detailed information which should be exchanged via I2NSF registration interface.
    
draft-iab-iotsi-workshop-02.txt
 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
 
 draft-iab-iotsi-workshop-02.txt
 Date: 02/07/2018
 Authors: Jaime Jimenez, Hannes Tschofenig, Dave Thaler
 Working Group: Internet Architecture Board (iab)
 Formats: xml txt
This document provides a summary of the 'Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)', which took place in Santa Clara, California, on March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions, and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors and the Internet Architecture Board (IAB), which organized the workshop.
    
draft-iab-marnew-report-02.txt
 IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) Report
 
 draft-iab-marnew-report-02.txt
 Date: 25/05/2018
 Authors: Natasha Rooney, Spencer Dawkins
 Working Group: Internet Architecture Board (iab)
 Formats: txt xml
The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on "Managing Radio Networks in an Encrypted World" (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimisation on mobile networks for encrypted content, as current solutions rely on unencrypted content which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members and participants from various organisations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators. The group discussed the current Internet encryption trends and deployment issues identified within the IETF, and the privacy needs of users which should be adhered. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed as well as analysing whether issues experienced when using current transport layer protocols are also playing a role here. Content providers and CDNs gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation was discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for- privacy technologies back to regulators. A group of suggested solutions were devised which will be discussed in various IETF groups moving forward.
    
draft-iab-path-signals-00.txt
 Path Signals
 
 draft-iab-path-signals-00.txt
 Date: 16/05/2018
 Authors: Ted Hardie
 Working Group: Internet Architecture Board (iab)
 Formats: txt
This document discusses the nature of signals seen by on-path elements, contrasting implicit and explicit signals. For example, TCP's state mechanics uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on- path network elements lack those signals. This document recommends that explict signals be used by transports which encrypt their state mechanics. It also recommends that a signal be exposed to the path only when the signal's originator intends that it be used by the network elements on the path.
    
draft-iab-protocol-maintenance-00.txt
 The Harmful Consequences of the Robustness Principle
 
 draft-iab-protocol-maintenance-00.txt
 Date: 03/05/2018
 Authors: Martin Thomson
 Working Group: Internet Architecture Board (iab)
 Formats: txt xml
Jon Postel's famous statement of "Be liberal in what you accept, and conservative in what you send" is a principle that has long guided the design and implementation of Internet protocols. The posture this statement advocates promotes interoperability, but can produce negative effects in the protocol ecosystem in the long term. Those effects can be avoided by maintaining protocols.
    
draft-icann-registrar-interfaces-00.txt
 ICANN Registrar Interfaces
 
 draft-icann-registrar-interfaces-00.txt
 Date: 22/03/2018
 Authors: Gustavo Lozano, Eduardo Alvarez
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents in order to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications.
    
draft-ichen-rtgwg-forwarding-policy-yang-00.txt
 Forwarding Policy YANG Model
 
 draft-ichen-rtgwg-forwarding-policy-yang-00.txt
 Date: 05/03/2018
 Authors: Ing-Wher Chen, Aseem Choudhary
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model to manage forwarding policies. The forwarding policy YANG model is based on the generic Quality-of-Service (Qos) policy YANG model ietf-qos-policy.yang, and includes augmented data nodes specific to forwarding policies.
    
draft-ideskog-assisted-token-00.txt
 OAuth 2.0 Assisted Token
 
 draft-ideskog-assisted-token-00.txt
 Date: 18/03/2018
 Authors: Jacob Ideskog, Travis Spencer
 Working Group: Individual Submissions (none)
 Formats: xml txt
The OAuth 2.0 authorization flow for Single Page Applications (SPAs), often referred to as the assisted token flow, enables OAuth clients to request user authorization written in scripting languages, like JavaScript, with a simplified integration compared to the implicit grant type flow. Communication does not rely on redirection of the user agent, but instead leverages HTML's iframe element, child windows, and the postMessage interface. This communication is done using an additional endpoint, the assisted token endpoint, which this document defines.
    
draft-idr-bgp-route-refresh-options-04.txt
 Extension to BGP's Route Refresh Message
 
 draft-idr-bgp-route-refresh-options-04.txt
 Date: 01/03/2018
 Authors: Keyur Patel, Aamod Vyavaharkar, Niloofar Fazlollahi, Tony Przygienda
 Working Group: Individual Submissions (none)
 Formats: txt xml
[RFC2918] defines a route refresh capability to be exchanged between BGP speakers. BGP speakers that support this capability are advertising that they can resend the entire BGP Adj-RIB-Out on receipt of a refresh request. By supporting this capability, BGP speakers are more flexible in applying any inbound routing policy changes as they no longer have to store received routes in their unchanged form or reset the session when an inbound routing policy change occurs. The route refresh capability is advertised per AFI, SAFI combination. There are newer AFI, SAFI types that have been introduced to BGP that support a variety of route types (e.g. IPv4/MVPN, L2VPN/EVPN). Currently, there is no way to request a subset of routes in a Route Refresh message for a given AFI, SAFI. This draft defines route refresh capability extensions that help BGP speakers to request a subset of routes for a given address family. This is expected to reduce the amount of update traffic being generated by route refresh requests as well as lessen the burden on the router servicing such requests.
    
draft-idr-rfc8203bis-00.txt
 Extended BGP Administrative Shutdown Communication
 
 draft-idr-rfc8203bis-00.txt
 Date: 30/04/2018
 Authors: Job Snijders, Jakob Heitz, John Scudder, Alexander Azimov
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets.
    
draft-ietf-6lo-ap-nd-06.txt
 Address Protected Neighbor Discovery for Low-power and Lossy Networks
 
 draft-ietf-6lo-ap-nd-06.txt
 Date: 23/02/2018
 Authors: Pascal Thubert, Behcet Sarikaya, Mohit Sethi
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This document defines an extension to 6LoWPAN Neighbor Discovery (ND) [RFC6775][I-D.ietf-6lo-rfc6775-update] called Address Protected ND (AP-ND); AP-ND protects the owner of an address against address theft and impersonation inside a low-power and lossy network (LLN). Nodes supporting this extension compute a cryptographic Owner Unique Interface ID and associate it with one or more of their Registered Addresses. The Cryptographic ID uniquely identifies the owner of the Registered Address and can be used for proof-of-ownership. It is used in 6LoWPAN ND in place of the EUI-64-based unique ID that is associated with the registration. Once an address is registered with a Cryptographic ID, only the owner of that ID can modify the anchor state information of the Registered Address, and Source Address Validation can be enforced.
    
draft-ietf-6lo-backbone-router-06.txt
 IPv6 Backbone Router
 
 draft-ietf-6lo-backbone-router-06.txt
 Date: 23/02/2018
 Authors: Pascal Thubert
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This specification proposes proxy operations for IPv6 Neighbor Discovery on behalf of devices located on broadcast-inefficient wireless networks. A broadcast-efficient backbone running classical IPv6 Neighbor Discovery federates multiple wireless links to form a large MultiLink Subnet, but the broadcast domain does not need to extend to the wireless links for the purpose of ND operation. Backbone Routers placed at the wireless edge of the backbone proxy the ND operation and route packets from/to registered nodes, and wireless nodes register or are proxy-registered to the Backbone Router to setup proxy services in a fashion that is essentially similar to a classical Layer-2 association.
    
draft-ietf-6lo-blemesh-03.txt
 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
 
 draft-ietf-6lo-blemesh-03.txt
 Date: 02/07/2018
 Authors: Carles Gomez, Seyed Darroudi, Teemu Savolainen, Michael Spoerk
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable IPv6 over Bluetooth low energy networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies the mechanisms needed to enable IPv6 over mesh networks composed of Bluetooth low energy links established by using the Bluetooth Internet Protocol Support Profile.
    
draft-ietf-6lo-deadline-time-01.txt
 Packet Delivery Deadline time in 6LoWPAN Routing Header
 
 draft-ietf-6lo-deadline-time-01.txt
 Date: 04/03/2018
 Authors: Lijo Thomas, P.M. Akshay, Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This document specifies a new type for the 6LoWPAN routing header containing the delivery deadline time for data packets. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks.
    
draft-ietf-6lo-nfc-10.txt
 Transmission of IPv6 Packets over Near Field Communication
 
 draft-ietf-6lo-nfc-10.txt
 Date: 17/07/2018
 Authors: Younghwan Choi, Yong-Geun Hong, Joo-Sang Youn, Dongkyun Kim, JinHyeock Choi
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LowPAN techniques.
    
draft-ietf-6lo-rfc6775-update-21.txt
 Registration Extensions for 6LoWPAN Neighbor Discovery
 
 draft-ietf-6lo-rfc6775-update-21.txt
 Date: 19/06/2018
 Authors: Pascal Thubert, Erik Nordmark, Samita Chakrabarti, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low power network.
    
draft-ietf-6lo-use-cases-05.txt
 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases
 
 draft-ietf-6lo-use-cases-05.txt
 Date: 01/07/2018
 Authors: Yong-Geun Hong, Carles Gomez, Abdur Sangi, Take Aanstoot, Samita Chakrabarti
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt
This document describes the applicability of IPv6 over constrained node networks (6lo) and provides practical deployment examples. In addition to IEEE 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, PLC (IEEE 1901.2), and IEEE 802.15.4e (6tisch) are used as examples. The document targets an audience who like to understand and evaluate running end- to-end IPv6 over the constrained node networks connecting devices to each other or to other devices on the Internet (e.g. cloud infrastructure).
    
draft-ietf-6man-icmp-limits-00.txt
 ICMPv6 errors for discarding packets due to processing limits
 
 draft-ietf-6man-icmp-limits-00.txt
 Date: 29/05/2018
 Authors: Tom Herbert
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication so it cannot take action to address the cause of discarded packets. This document defines ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may be able to modify what it sends in future packets to avoid subsequent packet discards.
    
draft-ietf-6man-ipv6only-flag-01.txt
 IPv6 Router Advertisement IPv6-Only Flag
 
 draft-ietf-6man-ipv6only-flag-01.txt
 Date: 30/06/2018
 Authors: Robert Hinden, Brian Carpenter
 Working Group: IPv6 Maintenance (6man)
 Formats: xml txt
This document specifies a Router Advertisement Flag to indicate to hosts that the administrator has configured the router to advertise that the link is IPv6-Only. This document updates RFC5175.
    
draft-ietf-6man-ndpioiana-04.txt
 IANA Considerations for IPv6 Neighbor Discovery Prefix Information Option Flags
 
 draft-ietf-6man-ndpioiana-04.txt
 Date: 01/05/2018
 Authors: Ole Troan
 Working Group: IPv6 Maintenance (6man)
 Formats: xml txt
The Prefix Information Option in the IPv6 Neighbor Discovery Router Advertisement message defines an 8-bit flag field with two flags defined and the remaining 6 bits reserved (Reserved1). RFC 6275 has defined a new flag from this field without creating a IANA registry or updating RFC 4861. The purpose of this document is to request a new IANA registry for the PIO flags. This document updates RFC 4861.
    
draft-ietf-6man-rfc4941bis-00.txt
 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
 
 draft-ietf-6man-rfc4941bis-00.txt
 Date: 02/07/2018
 Authors: Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. This document describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.
    
draft-ietf-6man-rfc6434-bis-09.txt
 IPv6 Node Requirements
 
 draft-ietf-6man-rfc6434-bis-09.txt
 Date: 16/07/2018
 Authors: Tim Chown, John Loughney, Timothy Winters
 Working Group: IPv6 Maintenance (6man)
 Formats: xml txt
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294.
    
draft-ietf-6man-segment-routing-header-14.txt
 IPv6 Segment Routing Header (SRH)
 
 draft-ietf-6man-segment-routing-header-14.txt
 Date: 29/06/2018
 Authors: Clarence Filsfils, Stefano Previdi, John Leddy, Satoru Matsushima, daniel.voyer@bell.ca
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header. This document describes the Segment Routing Extension Header and how it is used by Segment Routing capable nodes.
    
draft-ietf-6tisch-6top-protocol-12.txt
 6TiSCH Operation Sublayer Protocol (6P)
 
 draft-ietf-6tisch-6top-protocol-12.txt
 Date: 20/06/2018
 Authors: Qin Wang, Xavier Vilajosana, Thomas Watteyne
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This document defines the IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer to the IEEE Std 802.15.4 TSCH medium access control layer. The 6top layer terminates the 6top Protocol defined in this document, and runs one or more 6top Scheduling Function(s). A 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. This document lists the requirements for an SF, but leaves the definition of SFs out of scope.
    
draft-ietf-6tisch-6top-sfx-01.txt
 6TiSCH Experimental Scheduling Function (SFX)
 
 draft-ietf-6tisch-6top-sfx-01.txt
 Date: 05/03/2018
 Authors: Diego Dujovne, Luigi Grieco, Maria Palattella, Nicola Accettura
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt
This document defines a Scheduling Function called "Experimental Scheduling Function" (SFX). SFX dynamically adapts the number of scheduled cells between neighbor nodes, based on the amount of currently allocated cells and the neighbor nodes' cell requirements. Neighbor nodes negotiate in a distributed neighbor-to-neighbor basis the number of cell(s) to be added/deleted. SFX uses the 6P signaling messages to add/delete cells in the schedule. This function selects the candidate cells from the schedule, defines which cells will be added/deleted and triggers the allocation/deallocation process.
    
draft-ietf-6tisch-architecture-14.txt
 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4
 
 draft-ietf-6tisch-architecture-14.txt
 Date: 25/04/2018
 Authors: Pascal Thubert
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
This document describes a network architecture that provides low- latency, low-jitter and high-reliability packet delivery. It combines a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of LowPower wireless deterministic applications.
    
draft-ietf-6tisch-dtsecurity-zerotouch-join-02.txt
 6tisch Zero-Touch Secure Join protocol
 
 draft-ietf-6tisch-dtsecurity-zerotouch-join-02.txt
 Date: 30/04/2018
 Authors: Michael Richardson, Benjamin Damm
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This document describes a Zero-touch Secure Join (ZSJ) mechanism to enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch signaling mechanisms. The resulting device will obtain a domain specific credential that can be used with either 802.15.9 per-host pair keying protocols, or to obtain the network- wide key from a coordinator. The mechanism describe here is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security], and a constrained version of [I-D.ietf-anima-bootstrapping-keyinfra].
    
draft-ietf-6tisch-minimal-security-06.txt
 Minimal Security Framework for 6TiSCH
 
 draft-ietf-6tisch-minimal-security-06.txt
 Date: 25/05/2018
 Authors: Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt
This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, a new Stateless-Proxy CoAP option, and configures the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework.
    
draft-ietf-6tisch-terminology-10.txt
 Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e
 
 draft-ietf-6tisch-terminology-10.txt
 Date: 02/03/2018
 Authors: Maria Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt
This document provides a glossary of terminology used in IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH). This document extends existing terminology documents for Low-power and Lossy Networks.
    
draft-ietf-ace-coap-est-05.txt
 EST over secure CoAP (EST-coaps)
 
 draft-ietf-ace-coap-est-05.txt
 Date: 18/07/2018
 Authors: Peter van der Stok, Panos Kampanakis, Sandeep Kumar, Michael Richardson, Martin Furuhed, Shahid Raza
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt pdf xml
Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows low-resource constrained devices to use existing EST functionality for provisioning certificates.
    
draft-ietf-ace-cwt-proof-of-possession-03.txt
 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
 
 draft-ietf-ace-cwt-proof-of-possession-03.txt
 Date: 29/06/2018
 Authors: Michael Jones, Ludwig Seitz, Goeran Selander, Samuel Erdtman, Hannes Tschofenig
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: xml txt
This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs.
    
draft-ietf-ace-dtls-authorize-03.txt
 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
 
 draft-ietf-ace-dtls-authorize-03.txt
 Date: 05/03/2018
 Authors: Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt xml
This specification defines a profile for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. The protocol relies on DTLS for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained node can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory.
    
draft-ietf-ace-oauth-authz-13.txt
 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
 
 draft-ietf-ace-oauth-authz-13.txt
 Date: 02/07/2018
 Authors: Ludwig Seitz, Goeran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined.
    
draft-ietf-ace-oscore-profile-02.txt
 OSCORE profile of the Authentication and Authorization for Constrained Environments Framework
 
 draft-ietf-ace-oscore-profile-02.txt
 Date: 29/06/2018
 Authors: Ludwig Seitz, Francesca Palombini, Martin Gunnarsson, Goeran Selander
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt xml
This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.
    
draft-ietf-acme-acme-13.txt
 Automatic Certificate Management Environment (ACME)
 
 draft-ietf-acme-acme-13.txt
 Date: 17/07/2018
 Authors: Richard Barnes, Jacob Hoffman-Andrews, Daniel McCarney, James Kasten
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org).
    
draft-ietf-acme-authority-token-00.txt
 ACME Challenges Using an Authority Token
 
 draft-ietf-acme-authority-token-00.txt
 Date: 03/07/2018
 Authors: Jon Peterson, Mary Barnes, David Hancock, Chris Wendt
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt
A number of proposed challenges for the Automated Certificate Management Environment (ACME) effectively rely on an external authority issuing a token according to a particular policy. This document specifies a generic Authority Token challenge for ACME which supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications of this Authority Token challenge.
    
draft-ietf-acme-authority-token-tnauthlist-00.txt
 TNAuthList profile of ACME Authority Token
 
 draft-ietf-acme-authority-token-tnauthlist-00.txt
 Date: 02/07/2018
 Authors: Chris Wendt, David Hancock, Mary Barnes, Jon Peterson
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for VoIP Telephone Providers to support Secure Telephony Identity (STI) using the TNAuthList defined by STI certificates.
    
draft-ietf-acme-caa-05.txt
 CAA Record Extensions for Account URI and ACME Method Binding
 
 draft-ietf-acme-caa-05.txt
 Date: 21/06/2018
 Authors: Hugo Landau
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
The CAA DNS record allows a domain to communicate issuance policy to CAs, but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be required.
    
draft-ietf-acme-email-smime-02.txt
 Extensions to Automatic Certificate Management Environment for end user S/MIME certificates
 
 draft-ietf-acme-email-smime-02.txt
 Date: 04/03/2018
 Authors: Alexey Melnikov
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.
    
draft-ietf-acme-email-tls-04.txt
 Extensions to Automatic Certificate Management Environment for email TLS
 
 draft-ietf-acme-email-tls-04.txt
 Date: 20/03/2018
 Authors: Alexey Melnikov
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by TLS email services.
    
draft-ietf-acme-ip-02.txt
 ACME IP Identifier Validation Extension
 
 draft-ietf-acme-ip-02.txt
 Date: 18/05/2018
 Authors: Roland Shoemaker
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.
    
draft-ietf-acme-star-03.txt
 Support for Short-Term,Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)
 
 draft-ietf-acme-star-03.txt
 Date: 03/03/2018
 Authors: Yaron Sheffer, Diego Lopez, Oscar de Dios, Antonio Pastor, Thomas Fossati
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an attacker. However the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating this sequence upon compromise. This memo proposes an ACME extension to enable the issuance of short- term and automatically renewed (STAR) certificates. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR.
    
draft-ietf-acme-tls-alpn-01.txt
 ACME TLS ALPN Challenge Extension
 
 draft-ietf-acme-tls-alpn-01.txt
 Date: 30/05/2018
 Authors: Roland Shoemaker
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol which allows for domain control validation using TLS.
    
draft-ietf-alto-cdni-request-routing-alto-03.txt
 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO
 
 draft-ietf-alto-cdni-request-routing-alto-03.txt
 Date: 17/06/2018
 Authors: Jan Seedorf, Yang Yang, Kevin Ma, Jon Peterson, Xiao Lin
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Content Delivery Networks Interconnection (CDNI) WG is defining a set of protocols to inter-connect CDNs, to achieve multiple goals such as extending the reach of a given CDN to areas that are not covered by that particular CDN. One component that is needed to achieve the goal of CDNI is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI) [RFC7336]. [RFC8008] has defined precisely the semantics of FCI and provided guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. In this document, we define an FCI protocol using the Application-Layer Traffic Optimization (ALTO) protocol.
    
draft-ietf-alto-cost-calendar-07.txt
 ALTO Cost Calendar
 
 draft-ietf-alto-cost-calendar-07.txt
 Date: 02/07/2018
 Authors: Sabine Randriamasy, Yang Yang, Qin Wu, Deng Lingli, Nico Schwan
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information in order to allow applications to make network informed decisions. The present draft extends the ALTO cost information so as to broaden the decision possibilities of applications to not only decide 'where' to connect to, but also 'when'. This is useful to applications that need to schedule their data transfers and connections and have a degree of freedom to do so. ALTO guidance to schedule application traffic can also efficiently help for load balancing and resources efficiency. Besides, the ALTO Cost Calendar allows to schedule the ALTO requests themselves and thus to save a number of ALTO transactions. This draft proposes new capabilities and attributes on filtered cost maps and endpoint cost maps enabling an ALTO Server to provide "Cost Calendars". These capabilities are applicable to ALTO metrics with time-varying values. With ALTO Cost Calendars, an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes are specified in the IRD and ALTO Server responses.
    
draft-ietf-alto-incr-update-sse-12.txt
 ALTO Incremental Updates Using Server-Sent Events (SSE)
 
 draft-ietf-alto-incr-update-sse-12.txt
 Date: 02/07/2018
 Authors: Wendy Roome, Y. Yang, Shiwei Chen
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. For example, an ALTO server can provide network and cost maps so that an ALTO client can use the maps to determine the costs between endpoints when choosing communicating endpoints. However, the ALTO protocol does not define a mechanism to allow an ALTO client to obtain updates to the information resources, other than by periodically re-fetching them. Because some information resources (e.g., the aforementioned maps) may be large (potentially tens of megabytes), and because only parts of the information resources may change frequently (e.g., only some entries in a cost map), complete re-fetching can be extremely inefficient. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients, to achieve two benefits: (1) Updates can be immediate, in that the server can send updates as soon as they are available; and (2) updates can be incremental, in that if only a small section of an information resource changes, the server can send just the changes.
    
draft-ietf-alto-path-vector-04.txt
 ALTO Extension: Path Vector Cost Type
 
 draft-ietf-alto-path-vector-04.txt
 Date: 02/07/2018
 Authors: Greg Bernstein, Shiwei Chen, Kai Gao, Young Lee, Wendy Roome, Michael Scharf, Yang Yang, J. Zhang
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] has defined cost maps and endpoint cost maps to provide basic network information. However, they provide only scalar (numerical or ordinal) cost mode values, which are insufficient to satisfy the demands of solving more complex network optimization problems. This document introduces an extension to the base ALTO protocol, namely the path-vector extension, which allows ALTO clients to query information such as capacity regions for a given set of flows. A non-normative example called multi-flow scheduling is presented to illustrate the limitations of existing ALTO endpoint cost maps. After that, details of the extension are defined.
    
draft-ietf-alto-performance-metrics-04.txt
 ALTO Performance Cost Metrics
 
 draft-ietf-alto-performance-metrics-04.txt
 Date: 16/06/2018
 Authors: Qin Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt xml
Cost Metric is a basic concept in Application-Layer Traffic Optimization (ALTO). It is used in both the Cost Map Service and the Endpoint Cost Service. Different applications may benefit from different Cost Metrics. For example, a Resource Consumer may prefer Resource Providers that offer a low delay delivery to the Resource Consumer. However the base ALTO protocol [ALTO] has documented only one single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]). This document, proposes a set of Cost Metrics, derived and aggregated from routing protocols with different granularity and scope, such as BGP-LS,OSPF-TE and ISIS-TE, or from end-to-end traffic management tools. It currently documents Network Performance Cost Metrics reporting on network delay, jitter, packet loss, hop count, and bandwidth. These metrics may be exposed by an ALTO Server to allow applications to determine "where" to connect based on network performance criteria. Additional Cost Metrics involving ISP specific considerations or other network technologies may be documented in further versions of this draft.
    
draft-ietf-alto-unified-props-new-04.txt
 Unified Properties for the ALTO Protocol
 
 draft-ietf-alto-unified-props-new-04.txt
 Date: 29/06/2018
 Authors: Wendy Roome, Shiwei Chen, Sabine Randriamasy, Yang Yang, J. Zhang
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to domains of other entities, and by presenting those properties as maps, similar to the network and cost maps in ALTO.
    
draft-ietf-alto-xdom-disc-02.txt
 Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
 
 draft-ietf-alto-xdom-disc-02.txt
 Date: 05/03/2018
 Authors: Sebastian Kiesel, Martin Stiemerling
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be needed to discover an ALTO server outside of the own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (i.e., "ALTO: http" or "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URI(s) of information resources related to that IP address or prefix.
    
draft-ietf-anima-autonomic-control-plane-16.txt
 An Autonomic Control Plane (ACP)
 
 draft-ietf-anima-autonomic-control-plane-16.txt
 Date: 08/06/2018
 Authors: Toerless Eckert, Michael Behringer, Steinthor Bjarnason
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that is secure and reliable even when the network is not configured, or misconfigured.
    
draft-ietf-anima-bootstrapping-keyinfra-16.txt
 Bootstrapping Remote Secure Key Infrastructures (BRSKI)
 
 draft-ietf-anima-bootstrapping-keyinfra-16.txt
 Date: 22/06/2018
 Authors: Max Pritikin, Michael Richardson, Michael Behringer, Steinthor Bjarnason, Kent Watsen
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well.
    
draft-ietf-anima-constrained-voucher-00.txt
 Constrained Voucher Artifacts for Bootstrapping Protocols
 
 draft-ietf-anima-constrained-voucher-00.txt
 Date: 23/05/2018
 Authors: Michael Richardson, Peter van der Stok, Panos Kampanakis
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document builds upon the work in [RFC8366], encoding the resulting artifact in CBOR. Use with two signature technologies are described. Additionally, this document explains how constrained vouchers may be transported in the [I-D.ietf-ace-coap-est] protocol.
    
draft-ietf-anima-grasp-15.txt
 A Generic Autonomic Signaling Protocol (GRASP)
 
 draft-ietf-anima-grasp-15.txt
 Date: