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-aanchal-time-implementation-guidance-01.txt
 On Implementing Time
 
 draft-aanchal-time-implementation-guidance-01.txt
 Date: 22/10/2018
 Authors: Aanchal Malhotra, Kristof Teichel, Martin Hoffmann, Willem Toorop
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the properties of different types of clocks available on digital systems. It provides implementors of applications with guidance on choices they have to make when working with time to provide basic functionality and security guarantees.
    
draft-abd-mpls-ldp-identifier-name-00.txt
 MPLS LDP Identifier Name
 
 draft-abd-mpls-ldp-identifier-name-00.txt
 Date: 21/09/2018
 Authors: N Anil, Deepak Gowda, sajibasil@gmail.com
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces a new optional LDP Identifier Name TLV that allows LDP routers to inform their LDP-Identifier-to-Name mapping in LDP Hello messages as part of the LDP Discovery Mechanism. This document describes a mechanism to provide a simple and dynamic mechanism for ldp routers to learn about symbolic LDP Identifier Names.
    
draft-aboba-avtcore-quic-multiplexing-02.txt
 QUIC Multiplexing
 
 draft-aboba-avtcore-quic-multiplexing-02.txt
 Date: 22/10/2018
 Authors: Bernard Aboba, Peter Thatcher, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: txt
If QUIC is to be used in a peer-to-peer manner, with NAT traversal, then it is necessary to be able to demultiplex QUIC and other protocols used in WebRTC on a single UDP port. This memo discusses options for demultiplexing.
    
draft-abr-twitter-reply-00.txt
 A reply to a specific tweet
 
 draft-abr-twitter-reply-00.txt
 Date: 07/09/2018
 Authors: Adam Roach
 Working Group: Individual Submissions (none)
 Formats: txt
This document is a response to a tweet. It is of very limited interest.
    
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-ospf-admin-tags-00.txt
 Extensions to OSPF for Advertising Prefix/Link Administrative Tags
 
 draft-acee-lsr-ospf-admin-tags-00.txt
 Date: 23/07/2018
 Authors: Acee Lindem, Peter Psenak
 Working Group: Individual Submissions (none)
 Formats: txt
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to associate tags with prefixes and links. Previously, OSPFv2 and OSPFv3 were relegated to a single tag for AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may advertised for all types of prefixes and links. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. The ISIS protocol supports a similar mechanism that is described in RFC 5130.
    
draft-acee-lsr-ospfv3-extended-lsa-yang-02.txt
 Yang Model for OSPFv3 Extended LSAs
 
 draft-acee-lsr-ospfv3-extended-lsa-yang-02.txt
 Date: 22/10/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-acee-rtgwg-yang-rib-extend-08.txt
 RIB YANG Data Model
 
 draft-acee-rtgwg-yang-rib-extend-08.txt
 Date: 16/08/2018
 Authors: Acee Lindem, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
The Routing Information Base (RIB) is a list of routes and their corresponding administrative data and operational state. RFC 8349 defines the basic building blocks for RIB, and this model augments it to support multiple next-hops (aka, paths) for each route as well as additional attributes.
    
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-agrawal-spring-srv6-mpls-interworking-00.txt
 SRv6 and MPLS interworking
 
 draft-agrawal-spring-srv6-mpls-interworking-00.txt
 Date: 22/10/2018
 Authors: Swadesh Agrawal, Zafar Ali, Clarence Filsfils, daniel.voyer@bell.ca, Gaurav Dawra, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures.
    
draft-alavarez-hamelin-tictoc-sic-02.txt
 Synchronizing Internet Clock frequency protocol (sic)
 
 draft-alavarez-hamelin-tictoc-sic-02.txt
 Date: 23/10/2018
 Authors: Jose Alvarez-Hamelin, David Samaniego, Alfredo Ortega, Ruediger Geib
 Working Group: Individual Submissions (none)
 Formats: xml txt
Synchronizing Internet Clock Frequency specifies a new secure method to synchronize difference clocks on the Internet, assuring smoothness (i.e., frequency stability) and robustness to man-in-the-middle attacks. In 90% of all cases, Synchronized Internet Clock Frequency is highly accurate, with a Maximum Time Interval Error less than 25 microseconds by a minute. Synchronized Internet Clock Frequency is based on a regular packet exchange and works with commodity terminal hardware.
    
draft-ali-spring-bfd-sr-policy-02.txt
 Bidirectional Forwarding Detection (BFD) for Segment Routing Policies for Traffic Engineering
 
 draft-ali-spring-bfd-sr-policy-02.txt
 Date: 22/10/2018
 Authors: Zafar Ali, Ketan Talaulikar, Clarence Filsfils, Nagendra Kumar, Carlos Pignataro
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path using a segment list which is referred to as a SR Policy. Intermediate per-flow states are eliminated thanks to source routing. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. Bidirectional Forwarding Detection (BFD) is used to monitor different kinds of paths between node. BFD mechanisms can be also used to monitor the availability of the path indicated by a SR Policy and to detect any failures. Seamless BFD (S-BFD) extensions provide a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale. This document describes the use of Seamless BFD (S-BFD) mechanism to monitor the SR Policies that are used for Traffic Engineering (TE) in SR deployments.
    
draft-ali-spring-ioam-srv6-00.txt
 Segment Routing Header encapsulation for In-situ OAM Data
 
 draft-ali-spring-ioam-srv6-00.txt
 Date: 22/10/2018
 Authors: Zafar Ali, Rakesh Gandhi, Clarence Filsfils, Frank Brockners, Nagendra Kumar, Carlos Pignataro, Cheng Li, Mach Chen, Gaurav Dawra
 Working Group: Individual Submissions (none)
 Formats: txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the data packet while the packet traverses a path between two points in the network. This document defines how IOAM data fields are transported as part of the Segment Routing with IPv6 data plane (SRv6) header.
    
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-service-programming-oam-00.txt
 OAM for Service Programming with Segment Routing
 
 draft-ali-spring-sr-service-programming-oam-00.txt
 Date: 22/10/2018
 Authors: Zafar Ali, Clarence Filsfils, Nagendra Kumar, Carlos Pignataro, Francois Clad, faiqbal@cisco.com, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks.
    
draft-ali-spring-srv6-oam-02.txt
 Operations,Administration,and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
 
 draft-ali-spring-srv6-oam-02.txt
 Date: 22/10/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-allan-lsr-flooding-algorithm-00.txt
 A Distributed Algorithm for Constrained Flooding of IGP Advertisements
 
 draft-allan-lsr-flooding-algorithm-00.txt
 Date: 18/10/2018
 Authors: Dave Allan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a distributed algorithm that can be applied to the problem of constraining IGP flooding in dense mesh topologies. The flooding topology utilizes two node-diverse spanning trees in order to provide complete coverage in the presence of any single failure while constraining the number of LSAs received by any IGP speaker connected to the flooding topology.
    
draft-amringer-jose-chacha-00.txt
 Chacha derived AEAD algorithms in JSON Object Signing and Encryption (JOSE)
 
 draft-amringer-jose-chacha-00.txt
 Date: 07/11/2018
 Authors: Guillaume Amringer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines how to use the AEAD algorithms "AEAD_XCHACHA20_POLY1305" and "AEAD_CHACHA20_POLY1305" from [RFC8439] and [I-D.arciszewski-xchacha] in JSON Object Signing and Encryption (JOSE).
    
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-04.txt
 A Yang Data Model for SAVI Management
 
 draft-an-savi-yang-04.txt
 Date: 10/08/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-01.txt
 Integrated Packet-Optical In-Situ OAM
 
 draft-anand-ippm-po-ioam-01.txt
 Date: 21/08/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-06.txt
 Packet-Optical Integration in Segment Routing
 
 draft-anand-spring-poi-sr-06.txt
 Date: 30/07/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-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-pim-reliable-registers-00.txt
 Reliable Transport For PIM Register States
 
 draft-anish-pim-reliable-registers-00.txt
 Date: 20/11/2018
 Authors: Anish Peter, Robert Kebler, Vikram Nagarajan, Toerless Eckert, Stig Venaas
 Working Group: Individual Submissions (none)
 Formats: 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-annu-t2trg-ike-for-wsn-security-00.txt
 ike for wsn security
 
 draft-annu-t2trg-ike-for-wsn-security-00.txt
 Date: 03/08/2018
 Authors: annusin@cisco.com, Karan Verma
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an internet key exchange(ike) protocol for wireless sensor network.IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations.This document preassumed that readers are familier with basic concept of sensor network.
    
draft-ao-nvo3-overlay-subnet-architecture-00.txt
 Architecture for Overlay Virtual Sub-Network Interconnection
 
 draft-ao-nvo3-overlay-subnet-architecture-00.txt
 Date: 20/10/2018
 Authors: Ting Ao, Gregory Mirsky, Fan Yongbing
 Working Group: Individual Submissions (none)
 Formats: txt
An virtualized overlay network may be divided into several subnets for the reasons of geographical location, management, or using different technologies being used. For example, different customer have their own preference. But all these subnets need to work together to provide an end-to-end connectionif in a virtual network, An extended architecture of the NVO3 and propose a new component to provide the connection fucntion are introduced in this document.
    
draft-ao-sfc-oam-path-consistency-03.txt
 SFC OAM for path consistency
 
 draft-ao-sfc-oam-path-consistency-03.txt
 Date: 19/10/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-ao-sfc-oam-return-path-specified-02.txt
 Controlled Return Path for Service Function Chain (SFC) OAM
 
 draft-ao-sfc-oam-return-path-specified-02.txt
 Date: 19/10/2018
 Authors: Ting Ao, Gregory Mirsky, Zhonghua Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines extensions to the Service Function Chain (SFC) Operation, Administration and Maintenance (OAM) that enable control of the Echo Reply return path by specifying it as Reverse Service Function Path. Enforcing the specific return path can be used to verify bidirectional connectivity of SFC and increase the robustness of SFC OAM.
    
draft-ao-sfc-scalability-analysis-04.txt
 Analysis of the SFC scalability
 
 draft-ao-sfc-scalability-analysis-04.txt
 Date: 19/10/2018
 Authors: Ting Ao, Gregory Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt
SFC is an ordered set of service function, should be scalable to meet broad range of requirements. The scalability of SFC can be interpreted as ability of the SFC to accommodate one or more SFs joining the SFC , or leaving the SFC without significant impact to SFC performance. This document presents four aspects on SFC scalability, and provide analysis of the data plane and the control plane to implement the scalable SFC.
    
draft-ao-sfc-transport-00.txt
 SFC transport considertation
 
 draft-ao-sfc-transport-00.txt
 Date: 22/10/2018
 Authors: Ting Ao, Wei Wei, Yan Zheng
 Working Group: Individual Submissions (none)
 Formats: txt
A Network Service Header(NSH) is imposed encapsulates a packet or a frame for Service Function Chaining. The resulting packet, in turn, is encapsulate according to transport layer. The NSH contains a Service Path Identifier (SPI) and a Service Index (SI). The SPI is, as per its name, an identifier. The SPI alone cannot be used to forward packets along a service path. Rather, the SPI provides a level of indirection between the service path / topology and the network transport encapsulation. For different transport encapsulations, this document provides the format information with transport and NSH, and gives operational constraints that transport technologies, used by NSH need to meet.
    
draft-aranda-dispatch-q4s-07.txt
 The Quality for Service Protocol
 
 draft-aranda-dispatch-q4s-07.txt
 Date: 05/12/2018
 Authors: Jose Aranda, 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-06.txt
 High-level VNF Descriptors using NEMO
 
 draft-aranda-nfvrg-recursive-vnf-06.txt
 Date: 21/08/2018
 Authors: Pedro Gutierrez, Diego Lopez, Stefano Salsano, Elena Batanero
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-arciszewski-xchacha-03.txt
 XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305
 
 draft-arciszewski-xchacha-03.txt
 Date: 18/12/2018
 Authors: Scott Arciszewski
 Working Group: Crypto Forum (cfrg)
 Formats: xml txt
The eXtended-nonce ChaCha cipher construction (XChaCha) allows for ChaCha-based ciphersuites to accept a 192-bit nonce with similar guarantees to the original construction, except with a much lower probability of nonce misuse occurring. This enables XChaCha constructions to be stateless, while retaining the same security assumptions as ChaCha. This document defines XChaCha20, which uses HChaCha20 to convert the key and part of the nonce into a subkey, which is in turn used with the remainder of the nonce with ChaCha20 to generate a pseudorandom keystream (e.g. for message encryption). This document also defines AEAD_XChaCha20_Poly1305, a variant of [RFC7539] that utilizes the XChaCha20 construction in place of ChaCha20.
    
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-eap-aka-pfs-03.txt
 Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)
 
 draft-arkko-eap-aka-pfs-03.txt
 Date: 22/10/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 (to be superseded by draft-ietf-emu-rfc5448bis). The extension, when negotiated, 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 being able to decrypt all past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead.
    
draft-arkko-iab-internet-consolidation-00.txt
 Considerations on Internet Consolidation and the Internet Architecture
 
 draft-arkko-iab-internet-consolidation-00.txt
 Date: 22/10/2018
 Authors: Jari Arkko, Brian Trammell, Mark Nottingham, Christian Huitema, Martin Thomson, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
Many of us have held a vision of the Internet as the ultimate distributed platform that allows communication, the provision of services, and competition from any corner of the world. But as the Internet has matured, it seems to also feed the creation of large, centralised entities in many areas. This phenomenon could be looked at from many different angles, but this memo considers the topic from the perspective of how available technology and Internet architecture drives different market directions.
    
draft-arkko-trip-registry-update-01.txt
 Update to the TRIP IANA Registry Rules Regarding Postal Addresses
 
 draft-arkko-trip-registry-update-01.txt
 Date: 04/12/2018
 Authors: Jari Arkko, Ted Hardie
 Working Group: Applications and Real-Time Area (art)
 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-arora-mpls-spring-ttl-procedures-srte-paths-00.txt
 TTL Procedures for SR-TE Paths in Label Switched Path Traceroute Mechanisms
 
 draft-arora-mpls-spring-ttl-procedures-srte-paths-00.txt
 Date: 16/10/2018
 Authors: Kapil Arora, Shraddha Hegde
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
Segment routing supports the creation of explicit paths using adjacency-sids, node-sids, and anycast-sids. The SR-TE paths are built by stacking the labels that represent the nodes and links in the explicit path. A very useful Operations And Maintenance requirement is to be able to trace these paths as defined in [RFC8029]. This document specifies a uniform mechanism to support MPLS traceroute for the SR-TE paths when the nodes in the network are following uniform mode or short-pipe mode [RFC3443].
    
draft-asaeda-pim-multiif-igmpmldproxy-02.txt
 Multiple Upstream Interface Support for IGMP/MLD Proxy
 
 draft-asaeda-pim-multiif-igmpmldproxy-02.txt
 Date: 04/11/2018
 Authors: Hitoshi Asaeda, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the way of supporting multiple upstream interfaces for an IGMP/MLD proxy device. The proposed extension enables an IGMP/MLD proxy device to receive multicast sessions/ channels through the different upstream interfaces. The upstream interface is selected based on the subscriber address prefixes, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables to switch from an inactive upstream interface to an active upstream interface is also described.
    
draft-asciirfc-minimal-03.txt
 A Minimal Internet-Draft In AsciiRFC
 
 draft-asciirfc-minimal-03.txt
 Date: 11/12/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. NOTE This template requires usage of the Metanorma toolchain and the "metanorma-ietf" 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-atlas-rift-pgp-00.txt
 Policy Guided Prefixes with Routing In Fat Trees
 
 draft-atlas-rift-pgp-00.txt
 Date: 22/10/2018
 Authors: Alia Atlas, Zhaohui Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
In a fat tree, it can be sometimes desirable to guide traffic to particular destinations or keep specific flows to certain paths. In RIFT, this traffic steering/engineering is done by using policy- guided prefixes with their associated communities. Routes based on policy-guided prefixes are preferred over regular routes. Any node can originate a policy-guided prefix and advertise it in both north and south directions, and the calculation in both directions are distance vector based.
    
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-04.txt
 Nimble out-of-band authentication for EAP (EAP-NOOB)
 
 draft-aura-eap-noob-04.txt
 Date: 22/10/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, Russell 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-01.txt
 Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization
 
 draft-azimov-sidrops-aspa-verification-01.txt
 Date: 22/10/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-01.txt
 Study Report on a Framework for Cloud Inter-connection toward the Realization of IoT
 
 draft-baba-iot-interconnection-01.txt
 Date: 15/11/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-06.txt
 Problems in and among industries for the prompt realization of IoT and safety considerations
 
 draft-baba-iot-problems-06.txt
 Date: 15/11/2018
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Koichi KUNITAKE, Kaoru Maeda
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document contains opinions gathered from enterprises engaging in the IoT business as stated in the preceding version hereof, and also examines the possibilities of new social problems in the IoT era. Recognition of the importance of information security has grown in step with the rising use of the Internet. Closer examination reveals that the IoT era may see a new direct physical threat to users. For instance, the situation at a smart house may lead it to judge that the owner has only temporarily stepped out, causing it to unlock the front door, which in turn makes it easier for thieves to enter. These kinds of scenarios may occur without identity fraud, hacking, and other means of compromising information security. Therefore, for the purpose of this document, this issue shall be referred to as "IoT Safety" to distinguish it from Information Security. We believe that it is necessary to deepen our understanding of these new IoT-related threats through discussion and ensure there are measures to address these threats in the future. At the same time, we must also coordinate these measures with the solutions to the problems described in the previous version of this document.
    
draft-baba-iot-webapi-04.txt
 Report on Problem Solving Experiment for Realization of Web-API-based IoT
 
 draft-baba-iot-webapi-04.txt
 Date: 15/11/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-05.txt
 Benchmarking Methodology for Network Security Device Performance
 
 draft-balarajah-bmwg-ngfw-performance-05.txt
 Date: 14/10/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-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-stir-passport-div-hi-callflows-02.txt
 Session Initiation Protocol (SIP) Call Flow Examples with PASSporT Diversion and History-Info
 
 draft-barnes-stir-passport-div-hi-callflows-02.txt
 Date: 23/10/2018
 Authors: Mary Barnes
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-04.txt
 TFO support for Multipath TCP
 
 draft-barre-mptcp-tfo-04.txt
 Date: 22/11/2018
 Authors: Sebastien Barre, Gregory Detal, Olivier Bonaventure, Christoph Paasch
 Working Group: Individual Submissions (none)
 Formats: txt
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-01.txt
 PCEP extension to support Segment Routing Policy Candidate Paths
 
 draft-barth-pce-segment-routing-policy-cp-01.txt
 Date: 17/12/2018
 Authors: Colby Barth, Mike Koldychev, Siva Sivabalan, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a mechanism to specify an Segment Routing (SR) policy, as a collection of SR candidate paths. An SR policy is identified by tuple. An SR policy can contain one or more candidate paths where each candidate path is identified in PCEP via an PLSP-ID. 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 planes.
    
draft-bashandy-isis-srv6-extensions-04.txt
 IS-IS Extensions to Support Routing over IPv6 Dataplane
 
 draft-bashandy-isis-srv6-extensions-04.txt
 Date: 18/10/2018
 Authors: Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane.
    
draft-bashandy-rtgwg-segment-routing-uloop-04.txt
 Loop avoidance using Segment Routing
 
 draft-bashandy-rtgwg-segment-routing-uloop-04.txt
 Date: 24/09/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: Individual Submissions (none)
 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-http-record-00.txt
 A DNS Resource Record for HTTP
 
 draft-bellis-dnsop-http-record-00.txt
 Date: 03/11/2018
 Authors: Ray Bellis
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an "HTTP" resource record type for the DNS to facilitate the lookup of the server hostname of HTTP(s) URIs. It is intended to replace the use of CNAME records for this purpose, and in the process provides a solution for the inability of the DNS to allow a CNAME to be placed at the apex of a domain name.
    
draft-belyavskiy-certificate-limitation-policy-07.txt
 Certificate Limitation Policy
 
 draft-belyavskiy-certificate-limitation-policy-07.txt
 Date: 25/11/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-berger-manet-dlep-ether-credit-extension-01.txt
 DLEP IEEE 802.1Q Aware Credit Window Extension
 
 draft-berger-manet-dlep-ether-credit-extension-01.txt
 Date: 02/08/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-intarea-vim-discovery-00.txt
 IPv6-based discovery and association of Virtualization Infrastructure Manager (VIM) and Network Function Virtualization Orchestrator (NFVO)
 
 draft-bernardos-intarea-vim-discovery-00.txt
 Date: 22/08/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-nfvrg-multidomain-05.txt
 Multi-domain Network Virtualization
 
 draft-bernardos-nfvrg-multidomain-05.txt
 Date: 03/09/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-sfc-discovery-01.txt
 Service Function discovery in fog environments
 
 draft-bernardos-sfc-discovery-01.txt
 Date: 03/09/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-04.txt
 Service Function Chaining Use Cases in Fog RAN
 
 draft-bernardos-sfc-fog-ran-04.txt
 Date: 03/09/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-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-bhati-intarea-ip-reassembly-using-labels-00.txt
 IP Reassembly Using Labels
 
 draft-bhati-intarea-ip-reassembly-using-labels-00.txt
 Date: 04/10/2018
 Authors: BHATI Abhishek
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a faster mechanism to re-assemble IPv4 and IPv6 fragments when fragment labels are used instead of fragment offset to reassemble the packets.
    
draft-bhattacharyya-core-a-realist-00.txt
 Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)
 
 draft-bhattacharyya-core-a-realist-00.txt
 Date: 06/10/2018
 Authors: Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Rath, Arpan Pal
 Working Group: Individual Submissions (none)
 Formats: txt
This draft presents extensions to Constrained Application Protocol (CoAP) to enable RESTful Real-time Live Streaming for improving the Quality of Experience (QoE) for delay-sensitive Internet of Things (IoT) applications. The overall architecture is termed ''Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)''. It is particularly designed for applications which rely on real-time augmented vision through live First Person View (FPV) feed from constrained remote agents like Unmanned Aerial Vehicle (UAV), etc. These extensions provide the necessary hooks to help solution designers ensure low-latency transfer of streams and, for contents like video, a quick recovery from freeze and corruption without incurring undue lag. A-REaLiST is an attempt to provide an integrated approach to maintain the balance amongst QoE, resource- efficiency and loss resilience. It provides the necessary hooks to optimize system performance by leveraging contextual intelligence inferred from instantaneous information segments in flight. These extensions equip CoAP with a standard for efficient RESTful streaming for Internet of Things (IoT) contrary to HTTP-streaming in conventional Internet.
    
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-16.txt
 A SAVI Solution for WLAN
 
 draft-bi-savi-wlan-16.txt
 Date: 14/11/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-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-04.txt
 Time-Based Uni-Directional Attestation
 
 draft-birkholz-i2nsf-tuda-04.txt
 Date: 23/10/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-rats-architecture-00.txt
 Architecture and Reference Terminology for Remote Attestation Procedures
 
 draft-birkholz-rats-architecture-00.txt
 Date: 23/10/2018
 Authors: Henk Birkholz, Monty Wiseman, Hannes Tschofenig, Ned Smith
 Working Group: Individual Submissions (none)
 Formats: txt xml
Remote ATtestation ProcedureS (RATS), such as Remote Integrity VERification (RIVER), the creation of Entity Attestation Tokens (EAT), software integrity Measurement And ATtestation (MAAT), or the attestation of device characteristics, in general, are based on specific operations and qualities provided by hardware and software. The RATS architecture maps corresponding functions and operation capabilities to specific RATS roles. The goal is to enable an appropriate conveyance of believable evidence about device health or trusted claims about device capabilities via network protocols. The flows of data between these roles depend on the composition of RATS roles and their location with respect to devices or services. The RATS architecture provides these roles as building blocks to enable suitable composition, while remaining hardware-agnostic. This flexibility is intended to address a significant majority of use cases or usage scenarios in the domain of RATS. Examples include, but are not limited to: financial transactions, voting machines, critical safety systems, network equipment health, or trustworthy end-user device management.
    
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-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-01.txt
 YANG Module for Basic Challenge-Response-based Remote Attestation Procedures
 
 draft-birkholz-yang-basic-remote-attestation-01.txt
 Date: 23/10/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 a YANG RPC and a minimal datastore tree required to retrieve attestation evidence about integrity measurements from a composite device with one or more roots of trust for reporting. Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement. The module defined requires a TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server 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-02.txt
 Software Inventory YANG module based on Software Identifiers
 
 draft-birkholz-yang-swid-02.txt
 Date: 23/10/2018
 Authors: Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-03.txt
 BPSec Interoperability Cipher Suites
 
 draft-birrane-dtn-bpsec-interop-cs-03.txt
 Date: 22/10/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-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-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-03.txt
 The IPv6 Probe Option
 
 draft-bonica-6man-unrecognized-opt-03.txt
 Date: 09/08/2018
 Authors: Ron Bonica, John Leddy
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a new IPv6 option, called the Probe option. The Probe option elicits an ICMPv6 Parameter Problem message from all nodes that process it. When a node sends a packet that contains the Probe option and receives an ICMPv6 Parameter Problem message in response, it has verified the network's ability to convey packets that contain the Probe option.
    
draft-bonica-6man-vpn-dest-opt-01.txt
 The IPv6 Virtual Private Network (VPN) Context Information Option
 
 draft-bonica-6man-vpn-dest-opt-01.txt
 Date: 10/12/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-borchert-sidrops-bgpsec-state-unverified-00.txt
 BGPsec Validation State Unverified
 
 draft-borchert-sidrops-bgpsec-state-unverified-00.txt
 Date: 23/10/2018
 Authors: Oliver Borchert, Doug Montgomery
 Working Group: Individual Submissions (none)
 Formats: txt
In case operators decide to delay BGPsec path validation, none of the available states do properly represent this decision. This document introduces "Unverified" as a well-defined validation state which allows to properly identify a non-evaluated BGPsec routes as not verified.
    
draft-borchert-sidrops-rpki-state-unverified-00.txt
 RPKI Validation State Unverified
 
 draft-borchert-sidrops-rpki-state-unverified-00.txt
 Date: 23/10/2018
 Authors: Oliver Borchert, Doug Montgomery
 Working Group: Individual Submissions (none)
 Formats: txt
In case operators decide not to evaluate BGP route prefixes according to RPKI origin validation, none of the available states as specified in RFC 6811 do properly represent this decision. This document introduces "Unverified" as well-defined validation state which allows to properly identify route prefixes as not evaluated according to RPKI route origin validation.
    
draft-bormann-cbor-cddl-freezer-01.txt
 A feature freezer for the Concise Data Definition Language (CDDL)
 
 draft-bormann-cbor-cddl-freezer-01.txt
 Date: 09/08/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-cbor-time-tag-02.txt
 Concise Binary Object Representation (CBOR) Tags for Time,Duration,and Period
 
 draft-bormann-cbor-time-tag-02.txt
 Date: 22/10/2018
 Authors: Carsten Bormann, Ben Gamari, Henk Birkholz
 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. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC3339 time) and tag 1 (Posix time [TIME_T], int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, and anticipates the definition of related CBOR tags for duration and time period. It is intended as the reference document for the IANA registration of the CBOR tags defined.
    
draft-bormann-core-corr-clar-00.txt
 Constrained Application Protocol (CoAP): Corrections and Clarifications
 
 draft-bormann-core-corr-clar-00.txt
 Date: 23/10/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided.
    
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-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-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-bormann-t2trg-sworn-02.txt
 SWORN: Secure Wake on Radio Nudging
 
 draft-bormann-t2trg-sworn-02.txt
 Date: 22/10/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
Normally off devices (RFC7228) would need to expend considerable energy resources to be reachable at all times. Instead, MAC layer mechanisms are often employed that allow the last hop router of the device to "wake" the device via radio when needed. Activating these devices even for a short time still does expend energy and thus should be available to authorized correspondents only. Traditionally, this has been achieved by heavy firewalling, allowing only authorized hosts to reach the device at all. This may be too inflexible for an Internet of Things. The present report describes how to use a combination of currently standardized (or in progress) technologies to securely effect this authorization.
    
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: Individual Submissions (none)
 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-boucadair-dots-multihoming-04.txt
 Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)
 
 draft-boucadair-dots-multihoming-04.txt
 Date: 07/10/2018
 Authors: Mohamed Boucadair, Reddy K
 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-05.txt
 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server Discovery
 
 draft-boucadair-dots-server-discovery-05.txt
 Date: 07/10/2018
 Authors: Mohamed Boucadair, Reddy K, 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-netmod-softwire-iftunnel-00.txt
 A Tunnel Extension to the Interface Management YANG Module
 
 draft-boucadair-netmod-softwire-iftunnel-00.txt
 Date: 19/10/2018
 Authors: Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies an extension the Interface Management YANG module. Editorial Note (To be removed by RFC Editor) Please update these statements in the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: A Tunnel Extension to the Interface Management YANG Module"; o "reference: RFC XXXX" Please update the "revision" date of the YANG module.
    
draft-boucadair-radext-tcpm-converter-01.txt
 RADIUS Extensions for 0-RTT TCP Converters
 
 draft-boucadair-radext-tcpm-converter-01.txt
 Date: 18/10/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-01.txt
 DHCP Options for 0-RTT TCP Converters
 
 draft-boucadair-tcpm-dhc-converter-01.txt
 Date: 18/10/2018
 Authors: Mohamed Boucadair, Christian Jacquenet, Reddy K
 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-04.txt
 IPv6 is Classless
 
 draft-bourbaki-6man-classless-ipv6-04.txt
 Date: 15/09/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-03.txt
 EVPN control plane for Geneve
 
 draft-boutros-bess-evpn-geneve-03.txt
 Date: 14/09/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-02.txt
 Geneve applicability for service function chaining
 
 draft-boutros-nvo3-geneve-applicability-for-sfc-02.txt
 Date: 14/09/2018
 Authors: Sami Boutros, Dharma Rajan, Philip Kippen, Pierluigi Rolando
 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-boydseda-ipfix-psamp-bulk-data-yang-model-00.txt
 Data Models for the IP Flow Information Export (IPFIX) Protocol,Packet Sampling (PSAMP) Protocol,and Bulk Data Export
 
 draft-boydseda-ipfix-psamp-bulk-data-yang-model-00.txt
 Date: 22/10/2018
 Authors: Joey Boyd, Marta Seda
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a flexible modular alternative YANG model for bulk data collection and export via the IPFIX protocol to the model defined in [RFC6728] "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols". The model defined in this RFC configures the IPFIX exporter and collector (if applicable) and refers to the bulk data monitoring configuration. Optionally, the model can be configured to support PSAMP export of data via IPFIX. This document obsoletes [RFC6728] (if approved).
    
draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
 IPv6-Ready DNS/DNSSSEC Infrastructure
 
 draft-bp-v6ops-ipv6-ready-dns-dnssec-00.txt
 Date: 10/10/2018
 Authors: Cameron Byrne, Jordi Palet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines the timing for implementing a worldwide IPv6-Ready DNS and DNSSEC infrastructure, in order to facilitate the global IPv6-only deployment. A key issue for this, is the need for a global support of DNSSEC and DNS64, which in some scenarios do not work well together. This document states that any DNSSEC signed resources records should include a native IPv6 resource record as the most complete and expedient path to solve any deployment conflict with DNS64 and DNSSEC
    
draft-bradley-dnssd-private-discovery-00.txt
 Private Discovery
 
 draft-bradley-dnssd-private-discovery-00.txt
 Date: 23/10/2018
 Authors: Bob Bradley
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a mechanism for advertising and discovering in a private manner.
    
draft-bradley-oauth-jwt-encoded-state-09.txt
 Encoding claims in the OAuth 2 state parameter using a JWT
 
 draft-bradley-oauth-jwt-encoded-state-09.txt
 Date: 04/11/2018
 Authors: John Bradley, Torsten Lodderstedt, Hans Zandbelt
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft provides a method for a client to encode one or more elements encoding information about the session into the OAuth 2 "state" parameter.
    
draft-bradley-oauth-stateless-client-id-06.txt
 Stateless Client Identifier for OAuth 2
 
 draft-bradley-oauth-stateless-client-id-06.txt
 Date: 02/08/2018
 Authors: John Bradley, Justin Richer
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation.
    
draft-bretelle-dprive-dot-for-insecure-delegations-00.txt
 DNS-over-TLS for insecure delegations
 
 draft-bretelle-dprive-dot-for-insecure-delegations-00.txt
 Date: 27/09/2018
 Authors: Emmanuel Bretelle
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an alternate mechanism to DANE ([RFC6698]) in order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative server by not making DNSSEC a hard requirement, making DoT server authentication available for insecure delegations.
    
draft-briscoe-tsvwg-l4s-diffserv-02.txt
 Interactions between Low Latency,Low Loss,Scalable Throughput (L4S) and Differentiated Services
 
 draft-briscoe-tsvwg-l4s-diffserv-02.txt
 Date: 04/11/2018
 Authors: Bob Briscoe
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-03.txt
 EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols
 
 draft-brissette-bess-evpn-l2gw-proto-03.txt
 Date: 22/10/2018
 Authors: Patrice Brissette, Ali Sajassi, Luc Burdet, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
The existing EVPN multi-homing load-balancing modes defined are Single-Active and All-Active. Neither of these multi-homing mechanisms are appropriate to support access networks with Layer-2 Gateway protocols such as G.8032, MPLS-TP, STP, etc. These Layer-2 Gateway protocols require a new multi-homing mechanism defined in this draft.
    
draft-brissette-bess-evpn-mh-pa-02.txt
 EVPN multi-homing port-active load-balancing
 
 draft-brissette-bess-evpn-mh-pa-02.txt
 Date: 22/10/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-02.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-02.txt
 Date: 04/10/2018
 Authors: Dan Brown
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a special elliptic curve with a compact description (see title) and an efficient endormorphism (complex multiplication by i). This curve is only recommended for cryptographic use in a strongest-link combination with dissimilar elliptic curves (e.g. NIST P-256, Curve25519, extension-field curves, etc.). Used in this manner, the curve special features serve as a defense in depth against an unlikely event: a new or secret attack against the other types of elliptic curves.
    
draft-browne-sfc-nsh-kpi-stamp-06.txt
 A Key Performance Indicators (KPI) Stamping for the Network Service Header (NSH)
 
 draft-browne-sfc-nsh-kpi-stamp-06.txt
 Date: 26/11/2018
 Authors: Rory Browne, Andrey Chilikin, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an experimenal method of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH). This method may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.
    
draft-bruckert-brainpool-for-tls13-01.txt
 ECC Brainpool Curves for Transport Layer Security (TLS) Version 1.3
 
 draft-bruckert-brainpool-for-tls13-01.txt
 Date: 26/09/2018
 Authors: Leonie Bruckert, Johannes Merkle, Manfred Lochter
 Working Group: Individual Submissions (none)
 Formats: txt pdf
This document specifies the use of several ECC Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.3.
    
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-bryskin-teas-service-tunnel-steering-model-01.txt
 Basic YANG Model for Steering Client Services To Server Tunnels
 
 draft-bryskin-teas-service-tunnel-steering-model-01.txt
 Date: 05/11/2018
 Authors: Igor Bryskin, Vishnu Beeram, Tarek Saad, Xufeng Liu, Young Lee
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG data model for managing pools of transport tunnels and steering client services on them.
    
draft-burleigh-dtn-stcp-00.txt
 Simple TCP Convergence-Layer Protocol
 
 draft-burleigh-dtn-stcp-00.txt
 Date: 14/09/2018
 Authors: Scott Burleigh
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a Simple TCP (STCP) "convergence-layer" protocol for the Delay-Tolerant Networking (DTN) Bundle Protocol (BP). STCP uses Transmission Control Protocol (TCP) to transmit BP "bundles" from one BP node to another node to which it is topologically adjacent in the BP network. The services provided by the STCP convergence-layer protocol adapter utilize a standard TCP connection for the purposes of bundle transmission.
    
draft-burleigh-dtnwg-dtka-02.txt
 Architecture for Delay-Tolerant Key Administration
 
 draft-burleigh-dtnwg-dtka-02.txt
 Date: 28/08/2018
 Authors: Scott Burleigh, David Horres, Kapali Viswanathan, michael.w.benson@boeing.com, Fred Templin
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-01.txt
 Pseudowire (PW) Control Word (CW) Stitching
 
 draft-busi-pals-pw-cw-stitching-01.txt
 Date: 22/10/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-02.txt
 Link-Layer Addresses Assignment Mechanism for DHCPv6
 
 draft-bvtm-dhc-mac-assign-02.txt
 Date: 20/10/2018
 Authors: Bernie Volz, Tomek Mrugalski, Carlos Bernardos
 Working Group: Individual Submissions (none)
 Formats: txt
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-camarillo-dmm-srv6-mobile-pocs-01.txt
 Segment Routing IPv6 for mobile user-plane PoCs
 
 draft-camarillo-dmm-srv6-mobile-pocs-01.txt
 Date: 22/10/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-campbell-sip-messaging-smime-04.txt
 Securing Session Initiation Protocol (SIP) based Messaging with S/MIME
 
 draft-campbell-sip-messaging-smime-04.txt
 Date: 18/10/2018
 Authors: Ben Campbell, Russell Housley
 Working Group: Applications and Real-Time Area (art)
 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-01.txt
 TLS 1.3 Authentication and Integrity only Ciphersuites
 
 draft-camwinget-tls-ts13-macciphersuites-01.txt
 Date: 19/10/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-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-community-leaders-00.txt
 Some Thoughts on IETF Community Leadership
 
 draft-carpenter-community-leaders-00.txt
 Date: 07/09/2018
 Authors: Brian Carpenter
 Working Group: Individual Submissions (none)
 Formats: txt xml
This is a personal view of what the IETF community might expect of its members who serve in leadership positions such as Area Directors and IAB members. It is intended as personal input to the Nominating Committee, but posted as a draft since there is nothing private about it.
    
draft-carpenter-limited-domains-05.txt
 Limited Domains and Internet Protocols
 
 draft-carpenter-limited-domains-05.txt
 Date: 12/12/2018
 Authors: Brian Carpenter, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
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, also known as controlled environments, and emerging solutions, and develops a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the needs for a precise definition of limited domain membership and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.
    
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-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-lsr-flooding-reduction-00.txt
 LS Flooding Reduction
 
 draft-cc-lsr-flooding-reduction-00.txt
 Date: 10/12/2018
 Authors: Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an approach to flood link states on a topology that is a subgraph of the complete 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 area.
    
draft-cc-ospf-flooding-reduction-04.txt
 LS Flooding Reduction
 
 draft-cc-ospf-flooding-reduction-04.txt
 Date: 20/09/2018
 Authors: Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt pdf
This document proposes an approach to flood link states on a topology that is a subgraph of the complete 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 area.
    
draft-ce-lsr-ppr-graph-01.txt
 Preferred Path Route Graph Structure
 
 draft-ce-lsr-ppr-graph-01.txt
 Date: 23/10/2018
 Authors: Uma Chunduri, Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a graph structure for the Preferred Path Route (PPR) for IS-IS, OSPFv2 and OSPFv3 protocols. This structure helps further scale of the PPR and reduce domain level global entries needed in some data planes.
    
draft-cel-nfsv4-reminv-design-09.txt
 Using Remote Invalidation With RPC-Over-RDMA Transports
 
 draft-cel-nfsv4-reminv-design-09.txt
 Date: 19/11/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-rpc-tls-01.txt
 Remote Procedure Call Encryption By Default
 
 draft-cel-nfsv4-rpc-tls-01.txt
 Date: 19/11/2018
 Authors: Trond Myklebust, Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a mechanism that enables encryption of in- transit Remote Procedure Call (RPC) transactions with little administrative overhead and full interoperation with RPC implementations that do not support this mechanism. This document updates RFC 5531.
    
draft-cel-nfsv4-rpcrdma-reliable-reply-04.txt
 Improving the Performance and Reliability of RPC Replies on RPC-over-RDMA Transports
 
 draft-cel-nfsv4-rpcrdma-reliable-reply-04.txt
 Date: 19/11/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-08.txt
 RPC-over-RDMA Version 2 Protocol
 
 draft-cel-nfsv4-rpcrdma-version-two-08.txt
 Date: 08/11/2018
 Authors: Chuck Lever, David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a new version of the transport protocol that conveys Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA). The new version of this protocol is extensible.
    
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: Individual Submissions (none)
 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-04.txt
 Adaptive IPv4 Address Space
 
 draft-chen-ati-adaptive-ipv4-address-space-04.txt
 Date: 11/12/2018
 Authors: Abraham Chen, Ramamurthy Ati, Abhay Karandikar, David Crowe
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and the IoT (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to indepdently choose this system. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of routers for interfacing between the Internet fabic (core plus edge routers) and the end user premises. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy EzIP as address expansion using as little as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied by 512M times or even more. EzIP will immediately resolve local IPv4 address shortages, while being transparent to the rest of the Internet. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity and to provide the availability levels required for delivering a long-term general service.
    
draft-chen-bfd-unsolicited-03.txt
 Unsolicited BFD for Sessionless Applications
 
 draft-chen-bfd-unsolicited-03.txt
 Date: 03/08/2018
 Authors: Enke Chen, Naiming Shen, Robert Raszuk
 Working Group: Bidirectional Forwarding Detection (bfd)
 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-rpcs-yang-01.txt
 YANG Data Model for BIER RPCs
 
 draft-chen-bier-rpcs-yang-01.txt
 Date: 28/08/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-detnet-loss-delay-01.txt
 DetNet Packet Loss and Delay Performance Measurement
 
 draft-chen-detnet-loss-delay-01.txt
 Date: 22/10/2018
 Authors: Mach Chen, Andrew Malis
 Working Group: Individual Submissions (none)
 Formats: txt
Deterministic Networking (DetNet) is defined to provide end-to-end bounded latency and extremely low packet loss rates for critical flows. It's important to measure and monitor the packet loss rates and end-to-end delay and delay variation of a DetNet flow path, which allows evaluation of whether the Service Level Agreements (SLA) of the provided DetNet services are satisfied. These metrics are also useful in network/traffic planning, trouble shooting, and network performance evaluation. This document defines protocol mechanisms to support passive Performance Measurement (PM) for DetNet service.
    
draft-chen-detnet-sr-based-bounded-latency-00.txt
 Segment Routing (SR) Based Bounded Latency
 
 draft-chen-detnet-sr-based-bounded-latency-00.txt
 Date: 19/10/2018
 Authors: Mach Chen, Xuesong Geng, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
One of the goals of DetNet is to provide bounded end-to-end latency for critical flows. This document defines how to leverage Segment Routing (SR) to implement bounded latency. Specifically, the SR Identifier (SID) is used to specify transmission time (cycles) of a packet. When forwarding devices along the path follow the instructions carried in the packet, the bounded latency is achieved. This is called Cycle Specified Queuing and Forwarding (CSQF) in this document. Since SR is a source routing technology, no per-flow state is maintained at intermediate and egress nodes, SR-based CSQF naturally supports flow aggregation that is deemed to be a key capability to allow DetNet to scale to large networks.
    
draft-chen-isis-black-hole-avoid-03.txt
 Avoiding Traffic Black-Holes for Route Aggregation in IS-IS
 
 draft-chen-isis-black-hole-avoid-03.txt
 Date: 06/09/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-nfsv4-rocev2-cm-problem-statement-00.txt
 Problem Statement of RoCEv2 Congestion Management
 
 draft-chen-nfsv4-rocev2-cm-problem-statement-00.txt
 Date: 10/08/2018
 Authors: Fei Chen, Wenhao Sun
 Working Group: Individual Submissions (none)
 Formats: txt
On IP-routed datacenter networks, RDMA is deployed using RoCEv2 protocol. RoCEv2 specification does not define the congestion management and load balancing methods. RoCEv2 relies on the existing Link-Layer Flow-Control IEEE 802.1Qbb(Priority-based Flow Control, PFC)to provide a lossless network. RoCEv2 Congestion Management(RCM) use ECN(Explicit Congestion Notification, defined in RFC3168) to signal the congestion to the destination and use the congestion notification to reduce the rate of injection and increase the injection rate when the extent of congestion decreases. More and more practice of congestion management for RoCEv2 appear in the industry, such as DCQCN(Data Center Quantized Congestion Notification). There is a demanding for the new RoCE protocol(temporary alias RoCEv3) to provide stronger congestion management and load balancing mechanisms for RDMA deployment in modern datacenter.
    
draft-chen-nvo3-vxlan-yang-07.txt
 YANG Data Model for VxLAN Protocol
 
 draft-chen-nvo3-vxlan-yang-07.txt
 Date: 28/08/2018
 Authors: fangwei hu, Ran Chen, Mallik Mahalingam, Zu Qiang, Shahram Davari, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for VxLAN protocol.
    
draft-chen-nvo3-yang-00.txt
 YANG Data Model for NVO3 Protocol
 
 draft-chen-nvo3-yang-00.txt
 Date: 09/11/2018
 Authors: Ran Chen, fangwei hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for NVO3 configuration and operation. This YANG model covers two types of encapsulations: Geneve, and VXLAN-GPE
    
draft-chen-pce-bier-04.txt
 PCEP Extensions for BIER
 
 draft-chen-pce-bier-04.txt
 Date: 15/11/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-spring-anycast-sid-frr-00.txt
 Anycast-SID FRR in SR
 
 draft-chen-spring-anycast-sid-frr-00.txt
 Date: 28/08/2018
 Authors: Ran Chen, Shaofu Peng, Jie Han
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the fast redundancy protection mechanism, aimed at providing protection of the links and domain boundary nodes for network that use segment routing.
    
draft-cheng-spring-mpls-path-segment-03.txt
 Path Segment in MPLS Based Segment Routing Network
 
 draft-cheng-spring-mpls-path-segment-03.txt
 Date: 18/10/2018
 Authors: Weiqiang Cheng, Lei Wang, Han Li, Mach Chen, Rakesh Gandhi, Royi Zigler, Shuangping Zhan
 Working Group: Individual Submissions (none)
 Formats: txt
A Segment Routing (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 a pre-requisite for various use-cases such as performance measurement (PM) of an SR path. This document defines a new type of segment that is referred to as Path Segment, which 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 node of the SR path. Path Segment can be used by the egress node to implement path identification hence to support various use-cases including SR path PM, end-to-end 1+1 SR path protection and bidirectional SR paths correlation.
    
draft-cheshire-dnssd-roadmap-03.txt
 Service Discovery Road Map
 
 draft-cheshire-dnssd-roadmap-03.txt
 Date: 23/10/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-14.txt
 Special Use Domain Name 'ipv4only.arpa'
 
 draft-cheshire-sudn-ipv4only-dot-arpa-14.txt
 Date: 03/11/2018
 Authors: Stuart Cheshire, David Schinazi
 Working Group: Individual Submissions (none)
 Formats: xml txt
The specification for how a client discovers its local network's NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but in its Domain Name Reservation Considerations section that specification indicates that the name actually has no particularly special properties would require special handling, and does not request IANA to record the name in the Special-Use Domain Names registry. 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 describes the special treatment required, formally declares the special properties of the name, and adds similar declarations for the corresponding reverse mapping names.
    
draft-chkim-vlc-iot-00.txt
 Framework of Visible Light Communications in IoT Networks
 
 draft-chkim-vlc-iot-00.txt
 Date: 18/10/2018
 Authors: Cheol-Min Kim, Seok Koh
 Working Group: Individual Submissions (none)
 Formats: txt
The LED-based Visible Light Communication (VLC) has been proposed as the IEEE 802.15.7-2011 standard and regarded as a new wireless access medium in IoT environment. With this trend, many works have so far been made to improve the performance of VLC. However, how to effectively integrate VLC services into IoT networks has not been studied enough. In this document, we propose a scheme for device management and data transport in IoT networks using VLC. Specifically, we discuss how to manage VLC transmitters and receivers, and to support VLC data transmission in IoT networks. The proposed scheme considers uni-directional VLC transmissions from transmitter to receivers for delivery of location-based VLC data. The backward transmission from VLC receivers will be made by using platform server and aggregation agents in the network.
    
draft-chodorek-traffic-flow-option-09.txt
 An IP option for describing the traffic flow
 
 draft-chodorek-traffic-flow-option-09.txt
 Date: 25/07/2018
 Authors: Robert Chodorek
 Working Group: Individual Submissions (none)
 Formats: txt
Information about the behavior of the stream that will be transmitted in the near future will allow for better management of queues in the router and thus improve QoS and reduce the potential for a serious overload. Such information is often available in the transmitter. The proposed IP option allows for the sending of information about forthcoming traffic from the transmitter to the intermediate nodes.
    
draft-choi-anima-trust-networking-01.txt
 Trust networking and procedures for Autonomic Networking
 
 draft-choi-anima-trust-networking-01.txt
 Date: 14/10/2018
 Authors: Taesang Choi, Taesoo Chung, Junkyun Choi, Jaeseob Han
 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-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-01.txt
 IS-IS Multi Topology Deployment Considerations
 
 draft-chunduri-lsr-isis-mt-deployment-cons-01.txt
 Date: 22/10/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 underlays). This document explores the nuances around the terminology and usage of various IS-IS address families, topologies and considerations, while choosing the right combination for a specific deployment scenario. This document also discusses various ways one can deploy IPv6 only IS-IS topology.
    
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-01.txt
 Multiple Algorithm support for IS-IS Prefixes
 
 draft-chunduri-lsr-isis-prefix-multi-algo-01.txt
 Date: 22/10/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-03.txt
 Extension of Probabilistic Routing Protocol using History of Encounters and Transitivity for Information Centric Network
 
 draft-chung-dtn-extension-prophet-icn-03.txt
 Date: 22/10/2018
 Authors: Yun Chung, Min Kang, Dong Seo, 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-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-clemm-netmod-push-smart-filters-01.txt
 Smart Filters for Push Updates
 
 draft-clemm-netmod-push-smart-filters-01.txt
 Date: 22/10/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-02.txt
 Transport Network aware Mobility for 5G
 
 draft-clt-dmm-tn-aware-mobility-02.txt
 Date: 16/10/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-contreras-layered-sdn-03.txt
 Cooperating Layered Architecture for Software Defined Networking (CLAS)
 
 draft-contreras-layered-sdn-03.txt
 Date: 22/11/2018
 Authors: Luis Contreras, Carlos Bernardos, Diego Lopez, Mohamed Boucadair, Paola Iovanna
 Working Group: Individual Submissions (none)
 Formats: txt xml
Software Defined Networking adheres to the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or sevice intelligence is moved to these control entities. 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 an approach named Cooperating Layered Architecture for Software Defined Networking. 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-cooper-wugh-github-wg-configuration-02.txt
 GitHub Configuration for IETF Working Groups
 
 draft-cooper-wugh-github-wg-configuration-02.txt
 Date: 17/12/2018
 Authors: Alissa Cooper, Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
The use of GitHub in IETF working group processes is increasing. This document describes possible uses and conventions for working groups which are considering starting to use GitHub. It does not mandate any processes, and does not intend to change the processes used by current working groups. Discussion of this document takes place on the ietf-and-github mailing list (ietf-and-github@ietf.org), which is archived at .
    
draft-cth-rtgwg-bgp-control-00.txt
 Architecture for Use of BGP as Central Controller
 
 draft-cth-rtgwg-bgp-control-00.txt
 Date: 22/10/2018
 Authors: Huaimo Chen, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
BGP is a core part of a network including Software-Defined Networking (SDN) system. It has the traffic engineering information on the network topology and can compute optimal paths for a given traffic flow acrosss the network. This document describes the architecture for BGP as a central controller. A BGP-based central controller can simplify the operations on the network and use network resources efficiently for providing services with high quality.
    
draft-cuspdt-rtgwg-cu-separation-bng-architecture-03.txt
 Architecture for Control Plane and User Plane Separated BNG
 
 draft-cuspdt-rtgwg-cu-separation-bng-architecture-03.txt
 Date: 16/12/2018
 Authors: Shujun Hu, Fengwei Qin, Zhenqiang Li, Tee Chua, Victor Lopezalvarez, Donald Eastlake, Zitao Wang, Jun Song
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines an architecture for Broadband Network Gateway (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 are deployed separately at different network layers.
    
draft-cuspdt-rtgwg-cu-separation-bng-deployment-02.txt
 Control Plane and User Plane Separated BNG Deployment Model
 
 draft-cuspdt-rtgwg-cu-separation-bng-deployment-02.txt
 Date: 12/12/2018
 Authors: Rong Gu, Sujun Hu, Zitao Wang, Donald Eastlake, fangwei hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the deployment model for a Broadband Network Gateway (BNG) device with Control Plane (CP) and User Plane(UP) separation. It is intended to give guidance for the deployment of CP and UP separated BNG devices in an operators' network.
    
draft-cuspdt-rtgwg-cu-separation-bng-protocol-03.txt
 Control-Plane and User-Plane Separation BNG Control Channel Protocol
 
 draft-cuspdt-rtgwg-cu-separation-bng-protocol-03.txt
 Date: 30/11/2018
 Authors: Shujun Hu, Donald Eastlake, Zitao Wang, Fengwei Qin, Zhenqiang Li, Jun Song, Tee Chua
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the CU Separation Broadband Network Gateway (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-03.txt
 Information Model of Control-Plane and User-Plane Separation BNG
 
 draft-cuspdt-rtgwg-cu-separation-infor-model-03.txt
 Date: 22/10/2018
 Authors: Shujun Hu, Donald Eastlake, 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 operational expense, the Control-Plane and User-Plane separation concept is defined in Broadband Forum TR-384. This document describes the information model for the interface between the Control-Plane (CP) and the User-Plane (UP) in the CP/UP separation BNG. This information model may involve both the control channel interface and the configuration channel interface. The interface for the control channel allows the Control-Plane to send flow tables to the User- Plane, such as user's information table, user's interface table, and user's QoS table. And it also allows the User-Plane to report resource and statistics information to the Control-Plane. The interface for the configuration channel is in charge of the protocol version negotiation between the Control-Plane and User-Plane, the configuration for devices of the Control-Plane and User-Plane, and the reports of User-Plane's capabilities, etc. The information model defined in this document supports defining a standardized data model. Such a data model can be used to specify an interface to the CU separation BNG.
    
draft-cuspdt-rtgwg-cu-separation-yang-model-01.txt
 YANG Data Model for Configuration Interface of Control-Plane and User- Plane separation BNG
 
 draft-cuspdt-rtgwg-cu-separation-yang-model-01.txt
 Date: 05/12/2018
 Authors: fangwei hu, Sujun Hu, Fengwei Qin
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the YANG data model for management of Control- Plane and User-Plane separation BNGs (Broadband Network Gateways).
    
draft-cuspdt-rtgwg-cusp-requirements-03.txt
 Requirements for Control Plane and User Plane Separated BNG Protocol
 
 draft-cuspdt-rtgwg-cusp-requirements-03.txt
 Date: 22/10/2018
 Authors: Sujun Hu, Victor Lopezalvarez, Fengwei Qin, Zhenqiang Li, Tee Chua, Donald Eastlake, Zitao Wang, Jun Song
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the Control Plane and User Plane separated BNG (Broadband Network Gateway) architecture and defines a set of associated terminology. It also specifies a set of protocol requirements for communication between the BNG-CP and the BNG-UPs 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: Individual Submissions (none)
 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-dawes-sipcore-mediasec-parameter-09.txt
 Security Mechanism Names for Media
 
 draft-dawes-sipcore-mediasec-parameter-09.txt
 Date: 09/11/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-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-04.txt
 BGP Link State extensions for IPv6 Segment Routing(SRv6)
 
 draft-dawra-idr-bgpls-srv6-ext-04.txt
 Date: 03/09/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-05.txt
 BGP Signaling for SRv6 based Services.
 
 draft-dawra-idr-srv6-vpn-05.txt
 Date: 22/10/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-deconinck-quic-multipath-01.txt
 Multipath Extension for QUIC
 
 draft-deconinck-quic-multipath-01.txt
 Date: 04/09/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-5g-session-continuity-support-in-mptcp-00.txt
 5G Session Continuity Support in MPTCP
 
 draft-defoy-5g-session-continuity-support-in-mptcp-00.txt
 Date: 19/10/2018
 Authors: Xavier de Foy, Ulises Olvera, Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes how 5G session continuity can affect MPTCP. For now only potential performance issues are identified. This document aims to document discussions that took place at the IETF on this subject, to facilitate future deployment of MPTCP over 5G.
    
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-12.txt
 remoteStorage
 
 draft-dejong-remotestorage-12.txt
 Date: 08/12/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-04.txt
 IP address space reclassification
 
 draft-deshpande-intarea-ipaddress-reclassification-04.txt
 Date: 09/10/2018
 Authors: Vineet Deshpande
 Working Group: Individual Submissions (none)
 Formats: txt
This draft proposes IP address reclassification. By understanding how the Network is evolving from wireless technologies and comparing with an abstract mathematical topological space model, changes such as addition of a Virtual address space and Virtual BGP neighborship are proposed. The limitations of current Internet Architecture are identified and the corrections needed for the traffic bottleneck present in the current Internet Architecture are described further. The interdependence of IPv6 ULA addressing scheme, multipath and multipath TCP with the virtual neighborship and the virtual address space are explored.
    
draft-deutch-lamps-client-app-encrypt-00.txt
 Client Application Layer Encryption
 
 draft-deutch-lamps-client-app-encrypt-00.txt
 Date: 24/08/2018
 Authors: Benjamin Deutsch
 Working Group: Individual Submissions (none)
 Formats: txt
The protocol for Client Application Layer Encryption offers organizations a method of securely providing users data with very few authentication steps. This protocol makes use of X.509 public key infrastructure and SHOULD NOT be implemented without transport layer security. The protocol described below helps to ensure that response messages may only be read by the intended recipient.
    
draft-dhanaraj-bier-isis-non-mpls-extensions-00.txt
 ISIS Extensions for BIER in Non-MPLS Networks
 
 draft-dhanaraj-bier-isis-non-mpls-extensions-00.txt
 Date: 23/11/2018
 Authors: Senthil Dhanaraj, IJsbrand Wijnands, Peter Psenak, Gang Yan, Jingrong Xie
 Working Group: Individual Submissions (none)
 Formats: txt xml
Bit Index Explicit Replication (BIER) [RFC8279] is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. The common BIER header format and encapsulation for MPLS and non-MPLS networks is specified in [RFC8296]. BIER in Ethernet encapsulation is an example of BIER encapsulation in non-MPLS networks. [RFC8401] specifies the required extensions to the IS-IS [RFC1195] protocol for the distribution of BIER sub-domain information including the Sub-sub-TLV required to support BIER in MPLS encapsulation for MPLS networks. This document specifies the required extensions to the IS-IS [RFC1195] protocol for supporting BIER in non-MPLS networks using BIER in Ethernet encapsulation.
    
draft-dharini-ccamp-dwdm-if-param-yang-06.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-06.txt
 Date: 22/10/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. The use of this model does not guarantee interworking of transceivers over a DWDM. Optical path feasibility and interoperability has to be determined by means outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers.
    
draft-dharinigert-ccamp-dwdm-if-lmp-08.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-08.txt
 Date: 22/10/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-extension-pce-controller-p2mp-00.txt
 PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for P2MP LSPs
 
 draft-dhody-pce-pcep-extension-pce-controller-p2mp-00.txt
 Date: 22/10/2018
 Authors: Dhruv Dhody, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. The PCE has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). PCE was developed to derive paths for MPLS P2MP LSPs, which are supplied to the head end (root) of the LSP using PCEP. PCEP has been proposed as a control protocol to allow the PCE to be fully enabled as a central controller. A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/setup/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network devices along the P2MP path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCEP protocol extensions for using the PCE as the central controller for P2MP TE LSP.
    
draft-dhody-pce-pcep-extension-pce-controller-srv6-00.txt
 PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for SRv6
 
 draft-dhody-pce-pcep-extension-pce-controller-srv6-00.txt
 Date: 22/10/2018
 Authors: Dhruv Dhody, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). But SDN has a broader applicability than signaled (G)MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases. PCEP has been proposed as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document specifies the procedures and PCEP protocol extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers for Segment Routing in IPv6 (SRv6), in addition to computing the SRv6 paths for packet flows and telling the edge routers what instructions to attach to packets as they enter the network.
    
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-pcep-srv6-yang-00.txt
 A YANG Data Model for Segment Routing in IPv6 (SRv6) support in Path Computation Element Communications Protocol (PCEP)
 
 draft-dhody-pce-pcep-srv6-yang-00.txt
 Date: 19/10/2018
 Authors: Dhruv Dhody, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document augments a YANG data model for the management of Path Computation Element communications Protocol (PCEP) for communications between a Path Computation Client (PCC) and a Path Computation Element (PCE), or between two PCEs in support for Segment Routing in IPv6. The data model includes configuration data and state data (status information and counters for the collection of statistics).
    
draft-dhody-pce-recv-srlg-07.txt
 PCEP Extensions for Receiving SRLG Information
 
 draft-dhody-pce-recv-srlg-07.txt
 Date: 22/10/2018
 Authors: Dhruv Dhody, Fatai Zhang, Xian Zhang, Mahendra Negi, Victor Lopezalvarez, Oscar de Dios
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS). This document provides extensions for the Path Computation Element Protocol (PCEP) to receive Shared Risk Link Group (SRLG) information during path computation via encoding this information in the path computation reply message.
    
draft-dhody-pce-stateful-pce-interdomain-07.txt
 Stateful Path Computation Element (PCE) Inter-domain Considerations
 
 draft-dhody-pce-stateful-pce-interdomain-07.txt
 Date: 29/08/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-02.txt
 Extension for Stateful PCE to allow Optional Processing of PCEP Objects.
 
 draft-dhody-pce-stateful-pce-optional-02.txt
 Date: 22/10/2018
 Authors: Dhruv Dhody, Stephane Litkowski
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-05.txt
 Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for stateful PCE.
 
 draft-dhody-pce-stateful-pce-vendor-05.txt
 Date: 29/08/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-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-ding-dinrg-biot-00.txt
 Blockchain-based IoT Infrastructure Functional Requirements
 
 draft-ding-dinrg-biot-00.txt
 Date: 14/09/2018
 Authors: Hui Ding, Zhenzhen Jiao
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This document specifies the functional requirements for a Blockchain-based IoT infrastructure, including the IoT device identity management, service demand and supply matching, support of smart contract, etc.
    
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-dkg-tls-reject-static-dh-01.txt
 TLS clients should reject static Diffie-Hellman
 
 draft-dkg-tls-reject-static-dh-01.txt
 Date: 04/12/2018
 Authors: Daniel Gillmor
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft addresses problematic proposals that contradict the expected security properties of TLS. In particular, the ETSI "Middlebox Security Protocol" standard deliberately weakens the cryptographic guarantees of TLS unilaterally by the server, using static Diffie-Hellman keys where ephemeral keys are expected. Responsible TLS clients should avoid connecting to servers that appear to implement such a specification.
    
draft-dm-net2cloud-gap-analysis-02.txt
 Gap Analysis of Interconnecting Underlay with Cloud Overlay
 
 draft-dm-net2cloud-gap-analysis-02.txt
 Date: 19/10/2018
 Authors: Linda Dunbar, Andrew Malis, Christian Jacquenet
 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-04.txt
 Seamless Interconnect Underlay to Cloud Overlay Problem Statement
 
 draft-dm-net2cloud-problem-statement-04.txt
 Date: 14/12/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 third party data centers (a.k.a. Cloud 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-dold-payto-02.txt
 The 'payto' URI scheme for payments
 
 draft-dold-payto-02.txt
 Date: 08/10/2018
 Authors: Florian Dold, Christian Grothoff
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments.
    
draft-dolson-transport-middlebox-05.txt
 An Inventory of Transport-centric Functions Provided by Middleboxes: An Operator Perspective
 
 draft-dolson-transport-middlebox-05.txt
 Date: 06/12/2018
 Authors: David Dolson, Juho Snellman, Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document summarizes an operator's perception of the benefits that may 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.
    
draft-dong-i2nsf-asf-config-01.txt
 Configuration of Advanced Security Functions with I2NSF Security Controller
 
 draft-dong-i2nsf-asf-config-01.txt
 Date: 15/10/2018
 Authors: Wei Pan, 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-lsr-sr-enhanced-vpn-01.txt
 IGP Extensions for Segment Routing based Enhanced VPN
 
 draft-dong-lsr-sr-enhanced-vpn-01.txt
 Date: 22/10/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, RFC 4915 and RFC5340, can be extended to signal the network resources allocated in the underlay network to construct the customized virtual networks for enhanced VPN services, together with the Segment Routing Identifiers (SIDs) used to identify and access the network resources allocated for each virtual network in the data plane.
    
draft-dong-spring-sr-for-enhanced-vpn-02.txt
 Segment Routing for Enhanced VPN Service
 
 draft-dong-spring-sr-for-enhanced-vpn-02.txt
 Date: 22/10/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 from both control and data plane's perspective 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 underpinning 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. The proposed mechanism is applicable to both SR with MPLS data plane and SR with IPv6 data plane (SRv6).
    
draft-dong-teas-enhanced-vpn-03.txt
 A Framework for Enhanced Virtual Private Networks (VPN+) Service
 
 draft-dong-teas-enhanced-vpn-03.txt
 Date: 15/11/2018
 Authors: Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka, Young Lee
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a framework for using existing, modified and potential new networking technologies as components to provide an Enhanced Virtual Private Networks (VPN+) service. The purpose is to enable VPNs to support the needs of new applications, particularly applications that are associated with 5G services. Typically, VPN+ can be used to form the underpinning of network slicing, but will also be of use in its own right.
    
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-douglass-serverside-subscriptions-00.txt
 Serverside Subscriptions
 
 draft-douglass-serverside-subscriptions-00.txt
 Date: 04/09/2018
 Authors: Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This specification provides a mechanism whereby subscriptions to external resources can be handled by the server. This specification updates [RFC4791] to add new properies for the MKCOL request.
    
draft-draft-li-intent-classification-00.txt
 Intent Classification
 
 draft-draft-li-intent-classification-00.txt
 Date: 22/10/2018
 Authors: Chen Li, Ying Cheng, John Strassner, Olga Havel, Weiping Xu
 Working Group: Individual Submissions (none)
 Formats: txt
RFC 7575 [RFC7575] defines Intent as an abstract high-level policy used to operate the network. Intent management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their lifecycle. Up to now, there is no commonly agreed definition, interface or model of intent. This document discusses what intent means to different stakeholders, describes different ways to classify intent, and an associated taxonomy of this classification.
    
draft-dreibholz-ipv4-flowlabel-28.txt
 An IPv4 Flowlabel Option
 
 draft-dreibholz-ipv4-flowlabel-28.txt
 Date: 05/09/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-25.txt
 Applicability of Reliable Server Pooling for Real-Time Distributed Computing
 
 draft-dreibholz-rserpool-applic-distcomp-25.txt
 Date: 05/09/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-24.txt
 Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility
 
 draft-dreibholz-rserpool-applic-mobility-24.txt
 Date: 05/09/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-23.txt
 Handle Resolution Option for ASAP
 
 draft-dreibholz-rserpool-asap-hropt-23.txt
 Date: 05/09/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-22.txt
 Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling
 
 draft-dreibholz-rserpool-delay-22.txt
 Date: 05/09/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-20.txt
 Takeover Suggestion Flag for the ENRP Handle Update Message
 
 draft-dreibholz-rserpool-enrp-takeover-20.txt
 Date: 05/09/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-10.txt
 Ideas for a Next Generation of the Reliable Server Pooling Framework
 
 draft-dreibholz-rserpool-nextgen-ideas-10.txt
 Date: 05/09/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-23.txt
 Reliable Server Pooling (RSerPool) Bakeoff Scoring
 
 draft-dreibholz-rserpool-score-23.txt
 Date: 05/09/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-tsvwg-sctp-nextgen-ideas-08.txt
 Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)
 
 draft-dreibholz-tsvwg-sctp-nextgen-ideas-08.txt
 Date: 05/09/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-17.txt
 SCTP Socket API Extensions for Concurrent Multipath Transfer
 
 draft-dreibholz-tsvwg-sctpsocket-multipath-17.txt
 Date: 05/09/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-17.txt
 Sender Queue Info Option for the SCTP Socket API
 
 draft-dreibholz-tsvwg-sctpsocket-sqinfo-17.txt
 Date: 05/09/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-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-03.txt
 QUIC-LB: Generating Routable QUIC Connection IDs
 
 draft-duke-quic-load-balancers-03.txt
 Date: 10/12/2018
 Authors: Martin Duke
 Working Group: Individual Submissions (none)
 Formats: xml txt
QUIC connection IDs allow continuation of connections across address/ port 4-tuple changes, and can store routing information for stateless or low-state load balancers. They also can 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 methods for encoding routing information and proposes an optional protocol called QUIC_LB to exchange the parameters of that encoding.
    
draft-dukes-spring-mtu-overhead-analysis-01.txt
 Comparative Analysis of MTU overhead in the context of SPRING
 
 draft-dukes-spring-mtu-overhead-analysis-01.txt
 Date: 14/09/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-01.txt
 SR For SDWAN: VPN with Underlay SLA
 
 draft-dukes-spring-sr-for-sdwan-01.txt
 Date: 04/12/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-05.txt
 MISP core format
 
 draft-dulaunoy-misp-core-format-05.txt
 Date: 08/08/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-05.txt
 MISP galaxy format
 
 draft-dulaunoy-misp-galaxy-format-05.txt
 Date: 27/09/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] [MISP-G-DOC] 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-02.txt
 MISP object template format
 
 draft-dulaunoy-misp-object-template-format-02.txt
 Date: 15/10/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates [MISP-O] is available and relies on the MISP object reference format.
    
draft-dulaunoy-misp-taxonomy-format-06.txt
 MISP taxonomy format
 
 draft-dulaunoy-misp-taxonomy-format-06.txt
 Date: 30/11/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: xml txt
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 called MISP taxonomies is available and relies on the MISP taxonomy format. MISP taxonomies are used to classify cyber security events, threats, suspicious events, or indicators.
    
draft-dunbar-e2e-latency-arch-view-and-gaps-02.txt
 Architectural View of E2E Latency and Gaps
 
 draft-dunbar-e2e-latency-arch-view-and-gaps-02.txt
 Date: 30/08/2018
 Authors: Linda Dunbar
 Working Group: Individual Submissions (none)
 Formats: txt
Ultra-Low Latency is a highly desired property for many types of services, such as 5G MTC (Machine Type Communication) requiring E2E connection for V2V to be less than 2ms, AR/VR requiring delay less than 5ms, V2X less than 20ms, etc. This draft examines the E2E latency from architectural perspective, from studying how different OSI layers contribute to E2E latency, how different domains, which can be different operators' domains or administrative domains, contribute to E2E latency, to analyzing the gaps of recent technology advancement in reducing latency. By studying the contributing factors to E2E latency from various angles, the draft identifies some gaps of recent technology advancement for E2E services traversing multiple domains and involving multiple layers. The discussion might touch upon multiple IETF areas.
    
draft-dunbar-idr-bgp-sdwan-overlay-ext-03.txt
 BGP Extension for SDWAN Overlay Networks
 
 draft-dunbar-idr-bgp-sdwan-overlay-ext-03.txt
 Date: 07/11/2018
 Authors: Linda Dunbar, Haibo Wang, Hao Weiguo
 Working Group: Individual Submissions (none)
 Formats: txt
The document defines a new BGP SAFI with a new NLRI in order to advertise a SD-WAN node's properties with other SD-WAN nodes through third party untrusted networks. The goal is for SD-WAN network to scale; enabling SD-WAN overlay among large number of SD-WAN nodes with minimal provisioning, and allow services to be carried by different SD-WAN transport networks based on user specified criteria. A "SD-WAN" network consists of many segments of IPsec tunnels between SD-WAN nodes. An "end-point" is referring to a port on a SD- WAN node throughout this document. This document specifies new sub-TLVs for the SD-WAN End Point's Attributes.
    
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-dunglas-mercure-02.txt
 The Mercure Protocol
 
 draft-dunglas-mercure-02.txt
 Date: 21/10/2018
 Authors: Kevin Dunglas
 Working Group: Individual Submissions (none)
 Formats: txt xml
Mercure is a protocol allowing to push data updates to web browsers and other HTTP clients in a fast, reliable and battery-efficient way. It is especially useful to publish real-time updates of resources served through web APIs, to reactive web and mobile apps.
    
draft-dykim-6man-sid6-00.txt
 Subnet ID Deprecation for IPv6
 
 draft-dykim-6man-sid6-00.txt
 Date: 03/09/2018
 Authors: Kim Dy
 Working Group: Individual Submissions (none)
 Formats: txt xml
Deprecation of the subnet ID in IPv6 networking is proposed; the subnet ID is set to zero so that all nodes in a site carry the same prefix. While the procedures for neighbor discovery and duplicate address detection have to be changed, possible simplification gains in IPv6 networking including that of intra-site host- and subnet- mobility might be worth the modification. Site-external behaviors don't change through this modification, enabling incremental deployment of the proposal. Sites of manageable sizes for which scalability is not much a critical issue might consider the mode of operation proposed in this document.
    
draft-eastlake-bess-enhance-evpn-all-active-01.txt
 EVPN All Active Usage Enhancement
 
 draft-eastlake-bess-enhance-evpn-all-active-01.txt
 Date: 05/09/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-16.txt
 The FNV Non-Cryptographic Hash Algorithm
 
 draft-eastlake-fnv-16.txt
 Date: 10/12/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-08.txt
 Additional XML Security Uniform Resource Identifiers (URIs)
 
 draft-eastlake-rfc6931bis-xmlsec-uris-08.txt
 Date: 02/10/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-02.txt
 Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH)
 
 draft-eastlake-sfc-nsh-ecn-support-02.txt
 Date: 21/10/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 feed back information about congestion 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-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-eggert-irtf-rfc2014bis-05.txt
 IRTF Research Group Guidelines and Procedures
 
 draft-eggert-irtf-rfc2014bis-05.txt
 Date: 23/11/2018
 Authors: Lars Eggert
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Internet Research Task Force (IRTF) has responsibility for organizing groups to investigate research topics related to the Internet protocols, applications, and technology. IRTF activities are organized into Research Groups. This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). The basic duties of IRTF participants, including the IRTF Chair, Research Group Chairs and IRSG members are defined. This document obsoletes RFC2014.
    
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-elkins-hrpc-ifilter-00.txt
 Human Rights Considerations of Internet Filtering
 
 draft-elkins-hrpc-ifilter-00.txt
 Date: 17/10/2018
 Authors: Nalini Elkins, Barry Shein, Vittorio Bertola
 Working Group: Individual Submissions (none)
 Formats: txt
This document is a survey of the filtering of content. The focus is on the human rights involved as cited in the Universal Declaration of Human Rights" which is one of the foundational documents for HRPC. The recent years have seen an increase in content filtering for a variety of reasons including to further the aims of governments who wish to maintain their rule and suppress dissent but also to enforce cultural norms, human rights and compliance with the law. Filters also exist for security (botnets, malware etc.), user-defined policies (parental control, corporate blocking of social networks during work time, etc.), spam control, upload of copyrighted material and other reasons. This document is based on several real world considerations: the existence of national and regional sovereignty, Internet Service Providers (ISPs) and Content Distribution Networks (CDNs) that provide connectivity and content hosting services, Over- the-top (OTTs) and Content Delivery Platforms (CDPs) that play a disproportionate role in capturing the attention and "eyeballs" of many of the users of the Internet.
    
draft-elkschul-conflict-problem-01.txt
 Conflict Resolution within a Working Group: Problem Statement
 
 draft-elkschul-conflict-problem-01.txt
 Date: 05/12/2018
 Authors: Nalini Elkins, Henning Schulzrinne
 Working Group: Individual Submissions (none)
 Formats: txt
At the IETF, we currently use a set of methods to communicate a point of view, to solicit input, to resolve conflict and attempt to obtain consensus within the group. These methods include: writing an Internet Draft, discussion on email lists, discussion at face-to- face, interim or virtual meetings, and design teams. At times, these methods fall short. People become entrenched in their positions. A Working Group may be split for a prolonged period wasting time and energy. There may be a lasting impact. While the authors support rough consensus, the collateral damage of this process, at times can be considerable. This document discusses the benefits and drawbacks of each of the current methods of communication focusing solely on their efficacy at conflict resolution. A companion document will propose some solutions including alternative methods of conflict resolution.
    
draft-elris-hrpc-righttolife-00.txt
 Right to Life Issues in Internet Content and Protocols
 
 draft-elris-hrpc-righttolife-00.txt
 Date: 05/08/2018
 Authors: Nalini Elkins, William Jouris
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a new IANA registry of Guidance for Blocked Content. Blocked Content is content which has no significant valid use and conflicts with the "Universal Declaration of Human Rights" . The format of the proposed registry is provided, and some initial categories; for example, human trafficking and 3d printed guns.
    
draft-emailwhois-pradeepkumarxplorer-01.txt
 Extensions to WHois service to allow query on email identities
 
 draft-emailwhois-pradeepkumarxplorer-01.txt
 Date: 18/10/2018
 Authors: pradeep xplorer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the need for a WHois email address service similar to the internet domainname WHois service. Theres a need for a registered email address as opposed to non-registered email address to fight internet SPAM, as well as encouraging email use for personal, commercial and legal and all kinds of purposes.An internet user can have multiple email identities.
    
draft-enghardt-panrg-path-properties-00.txt
 A Vocabulary of Path Properties
 
 draft-enghardt-panrg-path-properties-00.txt
 Date: 18/10/2018
 Authors: Theresa Enghardt, Cyrill Krahenbuhl
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines and categorizes information about Internet paths that an endpoint might have or want to have. This information is expressed as properties of paths between two endpoints.
    
draft-erdtman-jose-cleartext-jws-01.txt
 Cleartext JSON Web Signature (JWS)
 
 draft-erdtman-jose-cleartext-jws-01.txt
 Date: 06/09/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 JSON canonicalization defined by [I-D.rundgren-json-canonicalization-scheme]. 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-15.txt
 NAT traversal for LISP
 
 draft-ermagan-lisp-nat-traversal-15.txt
 Date: 01/10/2018
 Authors: Vina Ermagan, Dino Farinacci, Darrel Lewis, Jesper Skriver, Fabio Maino, Chris White
 Working Group: Individual Submissions (none)
 Formats: xml 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-06.txt
 LISP Control Plane integration with NSH
 
 draft-ermagan-lisp-nsh-06.txt
 Date: 01/10/2018
 Authors: Vina Ermagan, Paul Quinn, Darrel Lewis, Fabio Maino, Florin Coras
 Working Group: Individual Submissions (none)
 Formats: xml 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-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-evenwu-opsawg-yang-composed-vpn-01.txt
 YANG Data Model for Composed VPN Service Delivery
 
 draft-evenwu-opsawg-yang-composed-vpn-01.txt
 Date: 21/10/2018
 Authors: Roni Even, Qin Wu, Ying Cheng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a YANG data model that can be used by a network operator to configure a VPN service at one layer interconnecting VPN service at another layer and manage how a hybrid VPN service is engineered in the network [RFC8309]. This model is intended to be instantiated at the management system to deliver the overall service. It is not a configuration model to be used directly on network elements. This model provides an abstracted view of VPN service configuration components at different layer. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements to deliver the service. How configuration of network elements is done is out of scope of the document.
    
draft-fairhurst-udp-options-cco-00.txt
 Checksum Compensation Options for UDP Options
 
 draft-fairhurst-udp-options-cco-00.txt
 Date: 19/10/2018
 Authors: Gorry Fairhurst, Tom Jones, Raffaele Zullo
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a robust method for calculating checksums for use with UDP Options. The new method proposes an alternative checksum calculation for coverage of the option space. This is based on the IP checksum calculation, but uses an updated pseudoheader. The new method only checks the option portion of a UDP packet, but creates a checksum that compensates for the range of IP and UDP chekcsum validation methods that have been deployed, in this way the new method enhances the proability of NAPT traversal for packets that carry UDP-Options.
    
draft-faltstrom-unicode11-06.txt
 IDNA2008 and Unicode 11.0.0
 
 draft-faltstrom-unicode11-06.txt
 Date: 09/12/2018
 Authors: Patrik Faltstrom
 Working Group: Applications and Real-Time Area (art)
 Formats: txt xml
This document describes the changes between Unicode 6.3.0 and Unicode 11.0.0 in the context of IDNA2008. It further suggests a path forward for the IETF to ensure IDNA2008 follows the evolution of the Unicode Standard. Some changes have been made in the Unicode Standard related to the algorithm IDNA2008 specifies. IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document makes no such changes. Thus this document requests that IANA update the tables to Unicode 11. The document also recomments that all DNS registries continue the practice of calculating a repertoire using conservatism and inclusion principles. TO BE REMOVED AT TIME OF PUBLICATION AS AN RFC: This document is discussed on the i18nrp@ietf.org mailing list of the IETF.
    
draft-farinacci-lisp-decent-02.txt
 A Decent LISP Mapping System (LISP-Decent)
 
 draft-farinacci-lisp-decent-02.txt
 Date: 30/11/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-geo-06.txt
 LISP Geo-Coordinate Use-Cases
 
 draft-farinacci-lisp-geo-06.txt
 Date: 15/10/2018
 Authors: Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols.
    
draft-farinacci-lisp-mobile-network-04.txt
 LISP for the Mobile Network
 
 draft-farinacci-lisp-mobile-network-04.txt
 Date: 11/09/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-06.txt
 LISP Distinguished Name Encoding
 
 draft-farinacci-lisp-name-encoding-06.txt
 Date: 11/09/2018
 Authors: Dino Farinacci
 Working Group: Individual Submissions (none)
 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-farmer-6man-exceptions-64-09.txt
 Exceptions to the Standard Subnet Boundary in IPv6 Addressing
 
 draft-farmer-6man-exceptions-64-09.txt
 Date: 09/08/2018
 Authors: David Farmer
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document clarifies exceptions to the standard subnet boundary in IPv6 addressing. The exceptions include unicast IPv6 addresses with the first three bits 000, manually configured addresses, DHCPv6 assigned addresses, IPv6 on-link determination, and the possibility of an exception specified in separate IPv6 link-type specific documents. Further, operational guidance is provided, and Appendix A discusses the valid options for configuring the parameters of an IPv6 subnet.
    
draft-farrel-spring-sr-domain-interconnect-05.txt
 Interconnection of Segment Routing Domains - Problem Statement and Solution Landscape
 
 draft-farrel-spring-sr-domain-interconnect-05.txt
 Date: 13/10/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-fattore-dmm-n6-cpdp-trafficsteering-00.txt
 Control-/Data Plane Aspects for N6 Traffic Steering
 
 draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt
 Date: 20/09/2018
 Authors: Umberto Fattore, Marco Liebsch
 Working Group: Individual Submissions (none)
 Formats: txt
Current standardization effort on the evolution of the mobile communication system reconsiders the mobile data plane protocol. The IETF DMM Working Group has work that proposes and analyzes various protocols as alternative to the GPRS Tunneling Protocol for User Plane (GTP-U) for an overlay deployment in between the mobile device's assigned data plane anchor and its current radio base station, which are denoted as N9 and N3 interfaces. In the view of some future deployment and the original intent per the very early DMM WG charter, a mobile device's data plane anchor may be highly distributed and re-selected for optimization throughout a mobile device's communication with one or more correspondent services. Such re-configuration has impact on the packet routing in between the mobile device's data plane anchor and the one or multiple data networks hosting the services, which is denoted as N6 interface. This draft proposes and discusses a solution to control, setup and maintain traffic treatment policy on the cellular communication system's N6 interface while taking the UE's PDU session settings per the cellular system's control plane, such as QoS and locator information, into account.
    
draft-fear-ippm-mpdm-02.txt
 IPv6 Marking and Performance and Diagnostic Metrics (MPDM)
 
 draft-fear-ippm-mpdm-02.txt
 Date: 21/10/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-feng-dmm-ra-prefixtype-03.txt
 Router Advertisement Prefix Option Extension for On-Demand Mobility
 
 draft-feng-dmm-ra-prefixtype-03.txt
 Date: 12/09/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 mobility service type availability to mobile hosts. Mobile hosts can then configure their IP address to the preferred type of mobile connectivity. Two possibilities are considered: (i) creating an extension to the router advertisement prefix information option to allow the router to specify mobility connectivity types, and (ii) specifying a new RA options that allows the router to specify the mobility connectivity types.
    
draft-fiebig-acme-esecacme-00.txt
 Extended Security Considerations for the Automatic Certificate Management Environment (ESecACME)
 
 draft-fiebig-acme-esecacme-00.txt
 Date: 21/10/2018
 Authors: Tobias Fiebig, Kevin Borgolte
 Working Group: Individual Submissions (none)
 Formats: txt
By now, most Public Key Infrastructure X.509 (PKIX) certificates are issued via the ACME protocol. Recently, several attacks against domain validation (DV) have been published, including IP-use-after- free, (forced) on-path attacks, and attacks on protocols used for validation. In general, these attacks can be mitigated by (selectively) requirering additional challenges, e.g., DNS validation, proof of prior-key-ownership, or in severe cases even extended validation (EV) instead of DV. This document provides a list of critical cases and describes which mitigations can be used to reduce the threat of issuing a certificate to an unauthorized party.
    
draft-filsfils-spring-large-scale-interconnect-12.txt
 Interconnecting Millions Of Endpoints With Segment Routing
 
 draft-filsfils-spring-large-scale-interconnect-12.txt
 Date: 29/08/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 DCs 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-02.txt
 SR Policy Implementation and Deployment Considerations
 
 draft-filsfils-spring-sr-policy-considerations-02.txt
 Date: 21/10/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-srv6-interop-01.txt
 SRv6 interoperability report
 
 draft-filsfils-spring-srv6-interop-01.txt
 Date: 11/09/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-06.txt
 SRv6 Network Programming
 
 draft-filsfils-spring-srv6-network-programming-06.txt
 Date: 22/10/2018
 Authors: Clarence Filsfils, Pablo Camarillo, John Leddy, daniel.voyer@bell.ca, Satoru Matsushima, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the SRv6 network programming concept and its most basic functions.
    
draft-finkelman-httpbis-has-redirecting-00.txt
 HTTP Redirects in HTTP Adaptive Streaming
 
 draft-finkelman-httpbis-has-redirecting-00.txt
 Date: 04/11/2018
 Authors: Ori Finkelman, Ali Begen
 Working Group: Individual Submissions (none)
 Formats: txt
This document motivates the need for clarifications of client behavior in cases of HTTP redirect to a content delivery network (CDN) when the redirected object contains relative references. This document focuses on HTTP Adaptive Streaming (HAS) use cases, but it might be possible to generalize to other use cases. The goal of this document is to present the current status of things and to explore potential solutions.
    
draft-finn-detnet-bounded-latency-02.txt
 DetNet Bounded Latency
 
 draft-finn-detnet-bounded-latency-02.txt
 Date: 22/10/2018
 Authors: Norman Finn, Jean-Yves Le Boudec, Ehsan Mohammadpour, Jiayi Zhang, Balazs Varga, Janos Farkas
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents a parameterized timing model for Deterministic Networking (DetNet), so that existing and future standards can achieve the DetNet quality of service features of bounded latency and zero congestion loss. It defines requirements for resource reservation protocols or servers. It calls out queuing mechanisms, defined in other documents, that can provide the DetNet quality of service.
    
draft-finzi-priority-switching-scheduler-04.txt
 Priority Switching Scheduler
 
 draft-finzi-priority-switching-scheduler-04.txt
 Date: 22/10/2018
 Authors: Fred Baker, Anais Finzi, Fabrice Frances, Nicolas Kuhn, Emmanuel Lochin, Ahlem Mifdaoui
 Working Group: Individual Submissions (none)
 Formats: txt xml
We detail the implementation of a network rate scheduler based on both a packet-based implementation of the generalized processor sharing (GPS) and a strict priority policies. This credit based scheduler called Priority Switching Scheduler (PSS), inherits from the standard Strict Priority Scheduler (SP) but dynamically changes the priority of one or several queues. Usual scheduling architectures often combine rate schedulers with SP to implement DiffServ service classes. Furthermore, usual implementations of rate scheduler schemes (such as WRR, DRR, ...) do not allow to efficiently guarantee the capacity dedicated to both AF and DF DiffServ 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. PSS allows a more predictable output rate per traffic class and is a one fit all scheme allowing to enable both SP and rate scheduling policies within a single algorithm.
    
draft-flanagan-fiftyyears-00.txt
 Fifty Years of RFCs
 
 draft-flanagan-fiftyyears-00.txt
 Date: 20/10/2018
 Authors: Heather Flanagan
 Working Group: Individual Submissions (none)
 Formats: xml txt
This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points, as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series.
    
draft-fmm-nvo3-pm-alt-mark-03.txt
 Performance Measurement (PM) with Alternate Marking in Network Virtualization Overlays (NVO3)
 
 draft-fmm-nvo3-pm-alt-mark-03.txt
 Date: 23/10/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-03.txt
 IPv6 Source Routing for ultralow Latency
 
 draft-foglar-ipv6-ull-routing-03.txt
 Date: 30/08/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-tsvwg-lola-00.txt
 A Loss-Latency Trade-off Signal for the Mobile Network
 
 draft-fossati-tsvwg-lola-00.txt
 Date: 16/12/2018
 Authors: Thomas Fossati, Gorry Fairhurst, Pedro Gutierrez, Mirja Kuehlewind
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a marking scheme for tagging low-latency flows (for example: interactive voice and video, gaming, machine to machine applications) that is safe to use by the mobile network for matching such flows to suitable per-hop behaviors (EPS bearers defined by 3GPP) in its core and radio segments. The suggested scheme re-uses NQB, a DiffServ-based signalling scheme with compatible rate-delay trade-off semantics that has been recently introduced in the context of fixed access to allow differential treatment of non-queue building vs queue building flows.
    
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-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-anima-brski-over-802dot11-00.txt
 BRSKI over IEEE 802.11
 
 draft-friel-anima-brski-over-802dot11-00.txt
 Date: 18/10/2018
 Authors: Owen Friel, Eliot Lear, Jerome Henry, 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 draft is a discussion document and no final recommendations are made on the recommended approaches to take. However, the advantages and downsides of each possible method are evaluated.
    
draft-friel-tls-atls-01.txt
 Application-Layer TLS
 
 draft-friel-tls-atls-01.txt
 Date: 31/07/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-galimbe-ccamp-iv-yang-07.txt
 A YANG model to manage the optical parameters for in a WDM network
 
 draft-galimbe-ccamp-iv-yang-07.txt
 Date: 22/10/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. The use of this model does not guarantee interworking of transceivers over a DWDM. Optical path feasibility and interoperability has to be determined by means outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers.
    
draft-galis-anima-autonomic-slice-networking-05.txt
 Autonomic Slice Networking
 
 draft-galis-anima-autonomic-slice-networking-05.txt
 Date: 26/09/2018
 Authors: A. Galis, Kiran Makhijani, 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-galis-precision-netslices-problem-statement-00.txt
 Management of Precision Network Slicing - Problem Statement
 
 draft-galis-precision-netslices-problem-statement-00.txt
 Date: 04/11/2018
 Authors: A. Galis
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces Precision Network Slicing Management problems and their context. It represents an initial review of the Management of Network Slicing problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem. It complements and brings together the efforts being carried out in several other IETF working groups covering certain aspects of Network Slicing management functions and operations.
    
draft-gandhi-spring-ioam-sr-mpls-00.txt
 Segment Routing with MPLS Data Plane encapsulation for In-situ OAM Data
 
 draft-gandhi-spring-ioam-sr-mpls-00.txt
 Date: 23/10/2018
 Authors: Rakesh Gandhi, Zafar Ali, Clarence Filsfils, Frank Brockners, Bin Wen, Voitek Kozak
 Working Group: Individual Submissions (none)
 Formats: txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the data packet while the packet traverses a path between two points in the network. This document defines how IOAM data fields are transported with the Segment Routing with MPLS data plane (SR-MPLS) encapsulation.
    
draft-gandhi-spring-sr-mpls-pm-03.txt
 Performance Measurement in Segment Routing Networks with MPLS Data Plane
 
 draft-gandhi-spring-sr-mpls-pm-03.txt
 Date: 14/09/2018
 Authors: Rakesh Gandhi, Clarence Filsfils, 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 protocol extensions.
    
draft-gandhi-spring-udp-pm-02.txt
 UDP Path for In-band Performance Measurement for Segment Routing Networks
 
 draft-gandhi-spring-udp-pm-02.txt
 Date: 14/09/2018
 Authors: Rakesh Gandhi, Clarence Filsfils, daniel.voyer@bell.ca, Stefano Salsano, Pier Ventre, Mach Chen
 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 procedures for using UDP path for sending and processing in-band probe query and response messages for Performance Measurement. The procedure uses the RFC 6374 defined mechanisms for Delay and Loss performance measurement. The procedure specified is applicable to 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 Return Path Segment List TLV for two-way performance measurement and Block Number TLV for loss 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-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-01.txt
 Flexible Session Protocol
 
 draft-gao-flexible-session-protocol-01.txt
 Date: 16/10/2018
 Authors: Jun-an, Gao
 Working Group: Individual Submissions (none)
 Formats: txt
FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied to protect authenticity of the origin of the FSP packets. It introduces the concept of transmit transaction to facilitate a quad-party sub-protocol for 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-gao-fsp-motivations-00.txt
 Motivations and Design Choices of the Flexible Session Protocol
 
 draft-gao-fsp-motivations-00.txt
 Date: 17/10/2018
 Authors: Jun-an, Gao
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces the motivation to design the Flexible Session Protocol which supports mobility and multihoming at the transport layer. FSP is to avoid, if not to extirpate, the routing scalability problem in the IPv6 internetwork. The document serves to explain choices of design goals of FSP as well.
    
draft-garciamorchon-t2trg-automated-iot-security-01.txt
 Automated IoT Security
 
 draft-garciamorchon-t2trg-automated-iot-security-01.txt
 Date: 19/10/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 but 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 describes a comprehensive agile security framework to integrate existing security processes such as risk assessment or vulnerability assessment in the lifecycle of a smart object in an IoT application. 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). PASC 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 configuration - applicable to the device or the system - to defeat the identified risks. The assigned security configuration 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.
    
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-detnet-info-distribution-03.txt
 IGP-TE Extensions for DetNet Information Distribution
 
 draft-geng-detnet-info-distribution-03.txt
 Date: 22/10/2018
 Authors: Xuesong Geng, Mach Chen, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document extends the IGP-TE, including OSPF-TE and ISIS-TE, to support DetNet by specifying new information that can be placed in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for DetNet computations.
    
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-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-gerdes-ace-c3dc-00.txt
 C3DC -- Constrained Client/Cross-Domain Capable Authorization Profile for Authentication and Authorization for Constrained Environments (ACE)
 
 draft-gerdes-ace-c3dc-00.txt
 Date: 23/10/2018
 Authors: Stefanie Gerdes, Olaf Bergmann, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
Resource-constrained nodes come in various sizes and shapes and often have constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document specifies a profile that describes how two autonomous resource-constrained devices, a client and a server, obtain the required keying material and authorization information to securely communicate with each other. Each of the devices is coupled with a less-constrained device, the authorization manager, that helps with difficult authentication and authorization tasks. The constrained devices do not need to register with authorization managers from other security domains. The profile specifically targets constrained clients and servers. It is designed to consider the security objectives of the owners on the server and the client side.
    
draft-ggalimbe-ccamp-flex-if-lmp-06.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-06.txt
 Date: 22/10/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-05.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-05.txt
 Date: 22/10/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-lsr-isis-invalid-tlv-01.txt
 Invalid TLV Handling in IS-IS
 
 draft-ginsberg-lsr-isis-invalid-tlv-01.txt
 Date: 02/12/2018
 Authors: Les Ginsberg, Paul Wells, Tony Li, Tony Przygienda, Shraddha Hegde
 Working Group: Individual Submissions (none)
 Formats: xml txt
Key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type/Length/Value (TLV) tuples. Although there are explicit statements in existing specifications, in some cases the expected behavior is "well known" but not explicitly stated. This document discusses the "well known behaviors" and makes them explicit in order to insure that interoperability is maximized. This document when approved updates RFC3563, RFC5305, RFC6232, and RFC6233.
    
draft-gondwana-sieve-mailboxid-01.txt
 Sieve Email Filtering: delivery by mailboxid
 
 draft-gondwana-sieve-mailboxid-01.txt
 Date: 12/08/2018
 Authors: Bron Gondwana
 Working Group: Individual Submissions (none)
 Formats: xml txt
The OBJECTID capability of the IMAP protocol (I-D.ietf-extra-imap- objectid) allows clients to identify mailboxes by a unique identifier which survives rename. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a method for specifying the unique identifier of a mailbox as a target for fileinto rules, and a method for testing the existence of a mailbox by its unique identifier.
    
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-04.txt
 Registry Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-carney-regext-registry-04.txt
 Date: 22/10/2018
 Authors: James Gould, Lin Jia, Roger Carney, 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-casanova-regext-unhandled-namespaces-00.txt
 Extensible Provisioning Protocol (EPP) Unhandled Namespaces
 
 draft-gould-casanova-regext-unhandled-namespaces-00.txt
 Date: 01/10/2018
 Authors: James Gould, Martin Casanova
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs. How should the server handle service data that needs to be returned in the response when the client does not support the required service namespace URI, which is referred to as an unhandled namespace? An unhandled namespace is a significant issue for the processing of RFC 5730 poll messages, since poll messages are inserted by the server prior to knowing the supported client services, and the client needs to be capable of processing all poll messages. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs that is compliant with the negotiated services defined in RFC 5730.
    
draft-gould-idn-table-07.txt
 Extensible Provisioning Protocol (EPP) Internationalized Domain Name (IDN) Table Mapping
 
 draft-gould-idn-table-07.txt
 Date: 15/10/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-dataset-02.txt
 Data Set File Format
 
 draft-gould-regext-dataset-02.txt
 Date: 05/09/2018
 Authors: James Gould
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a Data Set File (DSF) format that can be used to define and pass bulk data between a client and a server. This format is extensible to pass any set of simple data types in a set of records contained in the body of the file. The file format also supports storing the result of processing the data set that MAY be generated by the server and returned to the client. The file format consists of an XML definition header and a Comma-Separated Values (CSV) data section delimited by "-----BEGIN DATA SET-----" and "----- END DATA SET-----" lines. The XML definition header defines the format of the CSV data section, contains additional meta-data, and optionally includes a digital signature to identify the source and ensure that the data has not been tampered with between the parties (source, client, and server). The interface (manual or automated) that is used to submit the file and receive the result file is not defined within this document.
    
draft-gould-regext-launch-policy-01.txt
 Launch Phase Policy Extensions Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-launch-policy-01.txt
 Date: 17/08/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-02.txt
 Login Security Extension for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-login-security-02.txt
 Date: 17/08/2018
 Authors: James Gould, Matthew Pozun
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-gould-regext-login-security-policy-01.txt
 Login Security Policy Extensions Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-login-security-policy-01.txt
 Date: 10/12/2018
 Authors: James Gould
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an Extensible Provisioning Protocol (EPP) extension of the Registry Mapping to define the server policy of the Login Security EPP extension. The server policy of the Login Security EPP extension includes the MAYs, SHOULDs, and options implemented by the server.
    
draft-gpujol-oauth-atrl-01.txt
 OAuth 2.0 Token Revocation List
 
 draft-gpujol-oauth-atrl-01.txt
 Date: 10/09/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-route-leak-detection-00.txt
 BMP for BGP Route Leak Detection
 
 draft-gu-grow-bmp-route-leak-detection-00.txt
 Date: 22/10/2018
 Authors: Yunan Gu, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: xml txt
According to RFC7908 [RFC7908], Route leaks refer to case that the delivery range of route advertisements is beyond the expected range. For many current security protection solutions, the ISPs (Internet Service Providers) are focusing on finding ways to detect the happening of route leaks. However, the real-time route leak detection if any occurs is important as well. This document extends the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing security scheme suitable for ISPs to detect BGP route leaks within their own networks.
    
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-spring-nsh-sr-00.txt
 NSH and Segment Routing Integration for Service Function Chaining (SFC)
 
 draft-guichard-spring-nsh-sr-00.txt
 Date: 27/09/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-01.txt
 Mobility-aware Floating Anchor (MFA)
 
 draft-gundavelli-dmm-mfa-01.txt
 Date: 19/09/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-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-gwerder-messagevortexmain-00.txt,.ps
 MessageVortex Protocol
 
 draft-gwerder-messagevortexmain-00.txt,.ps
 Date: 29/11/2018
 Authors: Martin Gwerder
 Working Group: Individual Submissions (none)
MessageVortex Protocol specifies messages embedded within existing transfer protocols such as SMTP or XMPP to send them anonymously from peer to peer. The protocol outperforms other protocols by decoupling transport from the final transmitter and receiver party. There is no trust put into any infrastructure except for the infrastructure of the sending and receiving party of a message. The Message flow is entirely selected by the creator of the routing block. Routing nodes gain no non- obvious knowledge about messages even when collaborating. Third- party anonymity is always achieved. Furthermore, one out of sender and receiver anonymity may be achieved.
    
draft-gwock-rmcat-ccfs-00.txt
 Congestion Control based on Forward path Status
 
 draft-gwock-rmcat-ccfs-00.txt
 Date: 03/09/2018
 Authors: jungnam.gwock
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes CCFS(Congestion Control based on Forward path Status), rate adaptation scheme for interactive real-time media applications, such as video conferencing. CCFS manages forward path's status based on the estimated three major parameters - serving bitrate, queue delay and queue delay by cross traffics. Considering only forward path status minimizes the effects of backward path's network event such as congestion. It also is free from compatibility issues because it defines generalized feedback message and minimizes receiver's role.
    
draft-h-dots-mitigation-offload-expansion-00.txt
 DDoS mitigation offload usecase and YANG module expansion in signal channel
 
 draft-h-dots-mitigation-offload-expansion-00.txt
 Date: 14/10/2018
 Authors: Yuhei Hayashi, Kaname Nishizuka
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a DDoS Mitigation offload usecase and an expansion of the YANG module in the DOTS signal channel for mitigating DDoS attack traffic correctly with general routers or switches. The proposed usecase and YANG module enhance DOTS capability to send attacker information and enable service providers to mitigate DDoS attack traffic by using general routers or switches in their intra-domain NW.
    
draft-haas-bfd-large-packets-01.txt
 BFD Encapsulated in Large Packets
 
 draft-haas-bfd-large-packets-01.txt
 Date: 16/10/2018
 Authors: Jeffrey Haas, Albert Fu
 Working Group: Bidirectional Forwarding Detection (bfd)
 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-03.txt
 IASA 2.0 Design Team Recommendations
 
 draft-haberman-iasa20dt-recs-03.txt
 Date: 27/11/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. This document reflects the final snapshot of the design team discussion and is published for historical posterity.
    
draft-haindl-lisp-gb-atn-02.txt
 Ground-Based LISP for the Aeronautical Telecommunications Network
 
 draft-haindl-lisp-gb-atn-02.txt
 Date: 04/12/2018
 Authors: Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras, Victor Moreno, Fabio Maino, Balaji Venkatachalapathy
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization. The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures.
    
draft-hall-censorship-tech-06.txt
 A Survey of Worldwide Censorship Techniques
 
 draft-hall-censorship-tech-06.txt
 Date: 22/10/2018
 Authors: Joseph Hall, Michael Aaron, Stan Adams, Ben Jones, Nick Feamster
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-02.txt
 Data At Rest Encryption Part 2: DARE Container
 
 draft-hallambaker-dare-container-02.txt
 Date: 27/08/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes DARE Container, a message and file syntax that allows an append-only sequence of data frames to be represented with cryptographic integrity, signature and encryption enhancements. The format supports data integrity checks using digest chains and Merkle trees. The simplest supports efficient 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-02.txt
 Data At Rest Encryption Part 1: DARE Message Syntax
 
 draft-hallambaker-dare-message-02.txt
 Date: 27/08/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-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-advanced-00.txt
 Mathematical Mesh Part III: Advanced Cryptographic Services
 
 draft-hallambaker-mesh-advanced-00.txt
 Date: 31/08/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh ?The Mesh? is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the advanced encryption services supported by the Mesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-advanced.html [1] .
    
draft-hallambaker-mesh-architecture-06.txt
 Mathematical Mesh Part I: Architecture Guide
 
 draft-hallambaker-mesh-architecture-06.txt
 Date: 31/08/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 architecture of the Mesh and examples of typical applications are described. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- architecture.html [1] .
    
draft-hallambaker-mesh-reference-10.txt
 Mathematical Mesh Part II: Reference
 
 draft-hallambaker-mesh-reference-10.txt
 Date: 31/08/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-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-ip-transport-qos-01.txt
 Resource Reservation Protocol for IP Transport QoS
 
 draft-han-tsvwg-ip-transport-qos-01.txt
 Date: 19/10/2018
 Authors: Lin Han, Yingzhen Qu, Lijun Dong, Renwei Li, Thomas Nadeau, Kevin Smith, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
IP is designed for use in Best Effort Networks, which are networks that provide no guarantee that data is delivered, or that delivery meets any specified quality of service parameters. 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-hao-bess-evpn-centralized-df-03.txt
 Centralized EVPN DF Election
 
 draft-hao-bess-evpn-centralized-df-03.txt
 Date: 14/10/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 some issues with the 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 election mechanism.
    
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-06.txt
 Public Key Exchange
 
 draft-harkins-pkex-06.txt
 Date: 06/08/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-04.txt
 Secure Password Ciphersuites for Transport Layer Security (TLS)
 
 draft-harkins-tls-dragonfly-04.txt
 Date: 23/08/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-harris-early-pipe-01.txt
 SMTP Service Extension for Early Pipelining
 
 draft-harris-early-pipe-01.txt
 Date: 13/09/2018
 Authors: Jeremy Harris
 Working Group: Individual Submissions (none)
 Formats: txt xml
PIPE_CONNECT is an SMTP extension supporting the pipelining of banner, EHLO and one following command or traditionally-pipelined sequence in an SMTP conversation. It permits a reduction in delivery latency by eliminating a nunmber of network round-trips.
    
draft-hartke-core-apps-08.txt
 CoRE Applications
 
 draft-hartke-core-apps-08.txt
 Date: 22/10/2018
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The application programmable interfaces of RESTful, hypermedia-driven Web applications consist of a number of reusable components such as Internet media types and link relation types. This document proposes "CoRE Applications", a convention for application designers to build the interfaces of their applications in a structured way, so that implementers can easily build interoperable clients and servers, and other designers can reuse the components in their own applications.
    
draft-hartke-core-stateless-02.txt
 Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
 
 draft-hartke-core-stateless-02.txt
 Date: 22/10/2018
 Authors: Klaus Hartke
 Working Group: Constrained RESTful Environments (core)
 Formats: txt
This document provides considerations for alleviating CoAP clients and intermediaries of maintaining per-request state. Additionally, it introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323.
    
draft-hartke-t2trg-ciri-00.txt
 Constrained Internationalized Resource Identifiers
 
 draft-hartke-t2trg-ciri-00.txt
 Date: 22/10/2018
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies Constrained Internationalized Resource Identifier References, a serialization of Internationalized Resource Identifier (IRI) references that encodes the IRI components as Concise Binary Object Representation (CBOR) data items rather than a string of characters. This intends to simplify parsing, reference resolution, and comparison of IRIs in Constrained RESTful Environments (CoRE).
    
draft-hartke-t2trg-coral-06.txt
 The Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-06.txt
 Date: 22/10/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"), as well as simple resource metadata.
    
draft-hartke-t2trg-data-hub-02.txt
 Thing-to-Thing Data Hub
 
 draft-hartke-t2trg-data-hub-02.txt
 Date: 22/10/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 communications to share data items such as thing descriptions, configurations, resource descriptions, or firmware updates at a central location.
    
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-he-coin-datacenter-00.txt
 In-Network Data-Center Computing
 
 draft-he-coin-datacenter-00.txt
 Date: 11/10/2018
 Authors: Jeffrey He, Lijuan Chen, Marie-Jose Montpetit
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft wants to review the existing research and the open issues that relate to the addition of data plane programmability in Data Center. While some of the research hypotheses that are at the center of in-network-computing have been investigated since the time of active networking, recent developments in software defined networking, virtualization programmable switches and new network programming languages like P4 have generated a new enthusiasm in the research community and a flourish of new projects in systems and applications alike. This is what this draft is addressing.
    
draft-he-teas-gmpls-signaling-smp-00.txt
 GMPLS Signaling Extensions for Shared Mesh Protection
 
 draft-he-teas-gmpls-signaling-smp-00.txt
 Date: 22/10/2018
 Authors: He Jia, Italo Busi
 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. RFC 7412 provides requirements for any mechanism that would be used to implement SMP in an MPLS-TP network. 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-mpls-spring-epe-oam-01.txt
 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer engineering Segment Identifiers (SIDs) with MPLS Data Planes
 
 draft-hegde-mpls-spring-epe-oam-01.txt
 Date: 26/11/2018
 Authors: Shraddha Hegde, Kapil Arora
 Working Group: Individual Submissions (none)
 Formats: txt xml
Egress Peer Engineering is an application of Segment Routing to solve the problem of egress peer selection. The SR-based BGP-EPE solution allows a centralized (Software Defined Network, SDN)controller to program any egress peer. The EPE solution requires a node to program PeerNodeSID, PeerAdjSID, PeerSetSID as described in [I-D.ietf-spring-segment-routing-central-epe].This document provides Target FEC stack TLV definitions as defined in [RFC8029] for the EPE SIDs.
    
draft-hegde-spring-node-protection-for-sr-te-paths-04.txt
 Node Protection for SR-TE Paths
 
 draft-hegde-spring-node-protection-for-sr-te-paths-04.txt
 Date: 17/10/2018
 Authors: Shraddha Hegde, Chris Bowers, Stephane Litkowski, Xiaohu Xu, Feng Xu
 Working Group: Individual Submissions (none)
 Formats: xml pdf 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-hegde-spring-traffic-accounting-for-sr-paths-02.txt
 Traffic Accounting for MPLS Segment Routing Paths
 
 draft-hegde-spring-traffic-accounting-for-sr-paths-02.txt
 Date: 17/10/2018
 Authors: Shraddha Hegde
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
Traffic statistics form an important part of operations and maintenance data that are used to create demand matrices and for capacity planning in networks. Segment Routing (SR) is a source routing paradigm that uses stack of labels to represent a path. The SR path specific state is not stored in any other node in the network except the head-end node of the SR path. Traffic statistics specific to each SR path are an important component of the data which helps the controllers to lay out the SR paths in a way that optimizes the use of network resources. SR paths are inherently ECMP aware. As SR paths do not have state in the core of the network, it is not possible to collect the SR path traffic statistics accurately on each interface. This document describes an MPLS forwarding plane mechanism to identify the SR path to which a packet belongs and so facilitate accounting of traffic for MPLS SR paths. The mechanisms described in this document may also be applied to other MPLS paths (i.e., Label Switched Paths) and can be used to track traffic statistics in multipoint-to-point environments such as those where LDP is in use.
    
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-heitz-idr-msdc-bgp-aggregation-00.txt
 Aggregating BGP routes in Massive Scale Data Centers
 
 draft-heitz-idr-msdc-bgp-aggregation-00.txt
 Date: 22/10/2018
 Authors: Jakob Heitz, Dhananjaya Rao
 Working Group: Individual Submissions (none)
 Formats: xml txt
A design for a fabric of switches to connect up to one million servers in a data center is described. At that scale, it is impractical for every switch to maintain knowledge about every other switch and every other link in the fabric. Aggregation of routes is an excellent way to scale such a fabric. However, aggregation presents some problems under link failures or switch failures. This design solves those problems.
    
draft-heitz-idr-msdc-fabric-autoconf-01.txt
 Automatic discovery and configuration of the network fabric in Massive Scale Data Centers
 
 draft-heitz-idr-msdc-fabric-autoconf-01.txt
 Date: 04/11/2018
 Authors: Jakob Heitz, Kausik Majumdar, Acee Lindem
 Working Group: Individual Submissions (none)
 Formats: xml txt
A switching fabric in a massive scale data center can comprise many 10,000's of switches and 100,000's of IP hosts. To connect and configure a network of such size needs automation to avoid errors. Zero Touch Provisioning (ZTP) protocols exist. These can configure IP devices that are reachable by the ZTP agents. A method to combine BGP, DHCPv6 and SRv6 with ZTP that can be used to discover and configure an entire network of devices is described. It is designed to scale well, because each networked device is not required to know about more than its directly connected neighborhood.
    
draft-henry-tsvwg-diffserv-to-qci-00.txt
 Diffserv to QCI Mapping
 
 draft-henry-tsvwg-diffserv-to-qci-00.txt
 Date: 16/10/2018
 Authors: Jerome Henry, Tim Szigeti
 Working Group: Individual Submissions (none)
 Formats: txt
As communication devices become more hybrid, smart devices include more media-rich communication applications, and the boundaries between telecommunication and other applications becomes less clear. Simultaneously, as the end-devices become more mobile, application traffic transits more often between enterprise networks, the Internet, and cellular telecommunication networks. In this context, it is crucial that quality of service be aligned between these different environments. However, this is not always the case by default, and cellular communication networks use a different QoS nomenclature from the Internet and enterprise networks. This document specifies a set of 3rd Generation Partnership Project (3GPP) Quality of Service (QoS) Class Identifiers (QCI) to Differentiated Services Code Point (DSCP) mappings, to reconcile the marking recommendations offered by the 3GPP with the recommendations offered by the IETF, so as to maintain a consistent QoS treatment between cellular networks and the Internet.
    
draft-herbert-fast-03.txt
 Firewall and Service Tickets
 
 draft-herbert-fast-03.txt
 Date: 19/09/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 IPv6 Hop-by-Hop options.
    
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-intarea-gue-ctrl-messages-00.txt
 Control Messages for Generic UDP Encapsulation
 
 draft-herbert-intarea-gue-ctrl-messages-00.txt
 Date: 01/10/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines a set of basic control messages for Generic UDP Encapsulation (GUE). One pair of messages provides a means to query the GUE capabilities of a peer, another pair defines an echo request and response exchange for testing reachability.
    
draft-herbert-ipv6-update-opts-00.txt
 Updates to Requirements for IPv6 Options
 
 draft-herbert-ipv6-update-opts-00.txt
 Date: 14/09/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document updates requirements for IPv6 Destination and Hop-by- Hop Options. The requirements that option type and option length cannot change en route, as well as the requirements that options cannot be added or removed, are made explicit. The meaning and requirements of a Destination Option marked as changeable are clarified. Finally, the requirement that all destinations listed in a Routing header must process options in a Destination Options header preceding the Routing header is relaxed.
    
draft-herbert-route-fast-00.txt
 Encoding Routing in Firewall and Service Tickets
 
 draft-herbert-route-fast-00.txt
 Date: 10/10/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a method to encode routing information in Firewall and Service Tickets (FAST). Encoded routing information provides the local routing for packets sent in either the forward or return paths of a flow. FAST ticket reflection at peer hosts ensures that the routing information is attached to packets being sent in the return path. When a packet with a FAST ticket containing routing information enters the network in which the ticket was issued, the ticket is parsed to extract the routing information and is forwarded per the information. Routing in Firewall and Service Tickets has a number of use cases. It can be used as a type of source routing, used with identifier-locator protocols to provide a locator in the return path, and can be used to specify a backend instance in Layer 4 load balancing for processing connections to a virtual IP address.
    
draft-herbert-sub-path-ps-00.txt
 Sub-path Transport Layer Problem Statement
 
 draft-herbert-sub-path-ps-00.txt
 Date: 25/09/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents the problem statement and use cases for a sub- path transport layer. A sub-path is a portion of a network path that has localized characteristics that are of interest to an operator to manage. The structure for managing a sub-path is the "sub-path transport layer". A sub-path transport layer can provide transport layer mechanisms, such as reliability and congestion control, over the aggregate of packets traversing the sub-path. Additionally, a sub-path transport layer can provide performance measurements of traffic over a sub-path which in turn can be input to operations and management. The sub-path transport layer implies the possibility that traffic may be subject to two transport layer control loops, that of the sub-path and that of a higher layer transport protocol, any such solution must consider the ramifications of that.
    
draft-herbert-tsvwg-gte-00.txt
 Generic TCP Encapsulation
 
 draft-herbert-tsvwg-gte-00.txt
 Date: 28/09/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This specification describes Generic TCP Encapsulation (GTE) which is a method to encapsulate packets of different IP protocols within TCP data streams. Encapsulating packets in TCP facilitates communications across networks that block or sub-optimally handle non-TCP traffic. GTE is an adaptation of Generic UDP Encapsulation (GUE) to work in the context of TCP. GTE employs the GUE encapsulation format and optional extensions.
    
draft-hevroni-oauth-seamless-flow-01.txt
 Seamless OAuth 2.0 Client Assertion Grant
 
 draft-hevroni-oauth-seamless-flow-01.txt
 Date: 02/08/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-hinden-6man-mtu-option-00.txt
 IPv6 Minimum Path MTU Hop-by-Hop Option
 
 draft-hinden-6man-mtu-option-00.txt
 Date: 16/10/2018
 Authors: Robert Hinden, Gorry Fairhurst
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a new Hop-by-Hop IPv6 option that is used to record the minimum Path MTU from a source to a destination host. This collects a minimum recorded MTU along the path to the destination. The value can then be communicated back to the source host by an ICMPv6 Packet Too Big message. This Hop-by-Hop option is intended to be used in environments like Data Centers and on paths between Data Centers, to allow them to better take advantage of paths able to support a large Path MTU.
    
draft-historic-simple-ip-03.txt
 Simple Internet Protocol (SIP) Specification
 
 draft-historic-simple-ip-03.txt
 Date: 06/09/2018
 Authors: Steve Deering, Robert Hinden
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document is published for the historical record. The Simple Internet Protocol was the basis for one of the candidates for the IETF's Next Generation (IPng) work that became IPv6. The publication date of the original Internet-Draft was November 10, 1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable. The paragraph that follows is the Abstract from the original draft. 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-hmm-dmm-5g-uplane-analysis-02.txt
 User Plane Protocol and Architectural Analysis on 3GPP 5G System
 
 draft-hmm-dmm-5g-uplane-analysis-02.txt
 Date: 22/10/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-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-c2pq-04.txt
 The Transition from Classical to Post-Quantum Cryptography
 
 draft-hoffman-c2pq-04.txt
 Date: 13/08/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-special-labels-00.txt
 IANA Registry for Special Labels in the DNS
 
 draft-hoffman-dns-special-labels-00.txt
 Date: 01/10/2018
 Authors: Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines an new IANA registry for special labels in the DNS. The registry is useful because the labels cause special handling in DNS entities such as stub resolvers, recursive resolvers, and applications that use DNS, and developers of software for those entities should be aware of the many types of special labels in use. [[ A GitHub repo for this document is at https://github.com/paulehoffman/dns-special-labels ]]
    
draft-hoffman-resolver-associated-doh-07.txt
 Associating a DoH Server with a Resolver
 
 draft-hoffman-resolver-associated-doh-07.txt
 Date: 14/12/2018
 Authors: Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
Browsers and web applications may want to know if there are one or more DoH servers associated with the DNS recursive resolver that the operating system is already using. This would allow them to get DNS responses from a resolver that the user (or, more likely, the user's network administrator) has already chosen. This document describes two protocols for a resolver to tell a client what its associated DoH servers are. It also describes a protocol for a client to find out the address of the resolver it is using, if it cannot find that address by an operating system API or some other means.
    
draft-hohendorf-secure-sctp-26.txt
 Secure SCTP
 
 draft-hohendorf-secure-sctp-26.txt
 Date: 05/09/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-10.txt
 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect
 
 draft-hollenbeck-regext-rdap-openid-10.txt
 Date: 29/08/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-hollenbeck-vcarddav-icann-rdap-extensions-00.txt
 vCard Format Extensions: Internet Corporation for Assigned Names and Numbers (ICANN) Extensions for the Registration Data Access Protocol (RDAP)
 
 draft-hollenbeck-vcarddav-icann-rdap-extensions-00.txt
 Date: 07/11/2018
 Authors: Scott Hollenbeck, Roger Carney
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP). The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies.
    
draft-homma-dmm-5gs-id-loc-coexistence-02.txt
 Co-existence of 3GPP 5GS and Identifier-Locator Separation Architecture
 
 draft-homma-dmm-5gs-id-loc-coexistence-02.txt
 Date: 21/10/2018
 Authors: Shunsuke Homma, Kenta Kawakami, Arashmid Akhavain, Alberto Rodriguez-Natal, Ravi Shekhar
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an approach to introduce Identifier Locator Separation architecture into 3GPP 5GS with low-impact on its specifications, 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-homma-nmrg-slice-gateway-00.txt
 Gateway Function for Network Slicing
 
 draft-homma-nmrg-slice-gateway-00.txt
 Date: 22/10/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 function or function group for handling data plane traffic, such as 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-06.txt
 A YANG Data Model for Monitoring I2NSF Network Security Functions
 
 draft-hong-i2nsf-nsf-monitoring-data-model-06.txt
 Date: 15/11/2018
 Authors: Jaehoon Jeong, Jinyong Kim, Dongjin Hong, Susan Hares, Liang Xia, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes an information model and the corresponding YANG data model for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) framework. If the monitoring of NSFs is performed in a comprehensive 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 YANG data diagram 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: Jungha Hong, 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: Jungha Hong, 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-01.txt
 Problem Statement of IoT integrated with Edge Computing
 
 draft-hong-iot-edge-computing-01.txt
 Date: 22/10/2018
 Authors: Jungha Hong, Yong-Geun Hong, Joo-Sang Youn
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes new challenges for IoT services originated from the changes in 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 discribes the concept of IoT integrated with Edge computing as well as its use cases. It discusses benefits and challenges of Edge computing, focusing mainly on IoT data. The direction of Edge computing for IoT should be discussed in IETF/IRTF.
    
draft-hou-6lo-plc-05.txt
 Transmission of IPv6 Packets over PLC Networks
 
 draft-hou-6lo-plc-05.txt
 Date: 21/10/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-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: Russell 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-tls-tls13-cert-with-extern-psk-03.txt
 TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key
 
 draft-housley-tls-tls13-cert-with-extern-psk-03.txt
 Date: 08/11/2018
 Authors: Russell 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-hsmit-lsr-isis-dnfm-00.txt
 IS-IS Sparse Link-State Flooding
 
 draft-hsmit-lsr-isis-dnfm-00.txt
 Date: 22/10/2018
 Authors: Henk Smit, Gunter Van de Velde
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a technology extension to reduce link-state flooding in highly resilient dense networks. It does this by using simple and backwards-compatible extensions to reduce the number of adjacencies over which link-state flooding takes place. "IS-IS Sparse Link-State Flooding" is an extension to the IS-IS routing protocol. It is relatively easy to understand and implement. It is backwards compatible. It requires no per-node configuration. It uses a distributed algorithm, therefor no centralized computations are required. No complex computations are required on each node in the network. The algorithm has no requirements for the network topology. It can be deployed in a redundant way to improve robustness and convergence-times.
    
draft-hsmit-lsr-isis-flooding-over-tcp-00.txt
 IS-IS Flooding over TCP
 
 draft-hsmit-lsr-isis-flooding-over-tcp-00.txt
 Date: 12/10/2018
 Authors: Henk Smit, Gunter Van de Velde
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a solution to use TCP for IS-IS flooding. The proposed solution is a relative simple extension to implement. IS-IS flooding over TCP brings BGP's property of scalable transport via TCP to Link-State protocols. This proposal defines a new TLV in point-to-point IIHs to signal the intent of a router to do flooding over TCP, and it defines a small header to encapsulate IS-IS PDUs in the TCP byte-stream.
    
draft-httpemaildevphone-00.txt
 Need for associating email address to device address and phone numbers
 
 draft-httpemaildevphone-00.txt
 Date: 12/12/2018
 Authors: pradeep xplorer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the need for associating email address to device address and phone numbers
    
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-bier-bfd-02.txt
 BIER BFD
 
 draft-hu-bier-bfd-02.txt
 Date: 11/10/2018
 Authors: fangwei hu, Gregory Mirsky, Quan Xiong, Chang Liu
 Working Group: Individual Submissions (none)
 Formats: txt
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network.
    
draft-hu-isis-srv6-yang-00.txt
 YANG Data Model for IS-IS SRv6
 
 draft-hu-isis-srv6-yang-00.txt
 Date: 31/07/2018
 Authors: Zhibo Hu, Dan Ye, Yingzhen Qu, Jiajia Dong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage IS-IS SRv6 [I-D.bashandy-isis-srv6-extensions].
    
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-lsr-ospf-srv6-yang-00.txt
 YANG Data Model for OSPF SRv6
 
 draft-hu-lsr-ospf-srv6-yang-00.txt
 Date: 22/10/2018
 Authors: Zhibo Hu, Kamran Raza, Yingzhen Qu, Jiajia Dong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage OSPF SRv6 [I-D.li-ospf-ospfv3-srv6-extensions].
    
draft-hu-mpls-sr-inter-domain-use-cases-00.txt
 Segment Routing in MPLS-TP Inter-domain Use Cases
 
 draft-hu-mpls-sr-inter-domain-use-cases-00.txt
 Date: 09/12/2018
 Authors: fangwei hu, Quan Xiong, Gregory Mirsky, Weiqiang Cheng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses SR-MPLS-TP inter-domain scenarios and use cases, and also SR-MPLS-TP inter-working with MPLS-TP network requirement and use cases.
    
draft-hu-nvo3-vxlan-gpe-extension-for-vbng-01.txt
 VXLAN GPE Extension for Packets Exchange Between Control and User Plane of vBNG
 
 draft-hu-nvo3-vxlan-gpe-extension-for-vbng-01.txt
 Date: 09/12/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-pce-stitching-lsp-association-00.txt
 Stitching LSP Association
 
 draft-hu-pce-stitching-lsp-association-00.txt
 Date: 10/12/2018
 Authors: fangwei hu, Quan Xiong, Gregory Mirsky, Weiqiang Cheng
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the stitching LSP association type and stitching LSP association TLV for the inter-domain Segment Routing MPLS-TP network.
    
draft-hu-spring-segment-routing-proxy-forwarding-00.txt
 Segment Routing Proxy Forwarding
 
 draft-hu-spring-segment-routing-proxy-forwarding-00.txt
 Date: 22/10/2018
 Authors: Zhibo Hu, Huaimo Chen, Junda Yao
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing Traffic Engineering (SR-TE) supports the creation of explicit paths using adjacency-sids, node-sids, and binding-sids. In the SR-TE path, by providing proxy forwarding to the neighbor nodes of the faulty node, it is ensured that the traffic can reach the neighbor node of the faulty node normally in the case of the SR-TE of the loose path or strict path. If the failed node is a node that provides the Binding-sids service, the neighbor node can perform the binding-sids forwarding behavior to swap the corresponding label stack through the proxy forwarding of the neighbor node. [I-D.bashandy-rtgwg-segment-routing-ti-lfa] defines the usecase of protecting the node failure of segment list. This document describes how to implement the proxy forwarding mechanism of a faulty node at the neighbor node of the faulty node on the SR-TE path .
    
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-huang-rsca-sdm-eon-01.txt
 RSCA method with Dividing Frequency Slots Area in Space Division Multiplexing Elastic Optical Networks
 
 draft-huang-rsca-sdm-eon-01.txt
 Date: 13/11/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-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-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-03.txt
 Algorithm Negotiation in DNSSEC
 
 draft-huque-dnssec-alg-nego-03.txt
 Date: 22/07/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, J., PARK, 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-06.txt
 I2NSF Registration Interface Data Model
 
 draft-hyun-i2nsf-registration-interface-dm-06.txt
 Date: 26/07/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, J., PARK
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an information model and a YANG data model for Interface to Network Security Functions (I2NSF) Registration Interface between Security Controller and Developer's Management System (DMS). The objective of these information and data models is to support NSF search, instantiation and registration according to required security capabilities via I2NSF Registration Interface.
    
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, J., PARK
 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-path-signals-02.txt
 Transport Protocol Path Signals
 
 draft-iab-path-signals-02.txt
 Date: 19/11/2018
 Authors: Ted Hardie
 Working Group: Internet Architecture Board (iab)
 Formats: txt
This document discusses the nature of signals seen by on-path elements examining transport protocols, 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. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.
    
draft-iab-protocol-maintenance-01.txt
 The Harmful Consequences of the Robustness Principle
 
 draft-iab-protocol-maintenance-01.txt
 Date: 21/10/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 in the short term, but can negatively affect the protocol ecosystem. For a protocol that is actively maintained, the Postel's robustness principle can, and should, be avoided.
    
draft-iab-rfc7991bis-01.txt
 The "xml2rfc" version 3 Vocabulary
 
 draft-iab-rfc7991bis-01.txt
 Date: 19/10/2018
 Authors: Paul Hoffman
 Working Group: Internet Architecture Board (iab)
 Formats: txt
This document defines the "xml2rfc" version 3 vocabulary: an XML- based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the earlier v3 grammar described in RFC 7991, which in turn obsoleted the v2 grammar in RFC 7749. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the xml2rfc-dev@ietf.org mailing list, which has its home page at .
    
draft-iab-wire-image-01.txt
 The Wire Image of a Network Protocol
 
 draft-iab-wire-image-01.txt
 Date: 05/11/2018
 Authors: Brian Trammell, Mirja Kuehlewind
 Working Group: Internet Architecture Board (iab)
 Formats: txt xml
This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol. This abstraction is intended to shed light on the implications on increased encryption has for network functions that use the wire image.
    
draft-icann-registrar-interfaces-01.txt
 ICANN Registrar Interfaces
 
 draft-icann-registrar-interfaces-01.txt
 Date: 18/09/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-idr-bgp-route-refresh-options-05.txt
 Extension to BGP's Route Refresh Message
 
 draft-idr-bgp-route-refresh-options-05.txt
 Date: 29/08/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-ietf-6lo-ap-nd-09.txt
 Address Protected Neighbor Discovery for Low-power and Lossy Networks
 
 draft-ietf-6lo-ap-nd-09.txt
 Date: 13/12/2018
 Authors: Pascal Thubert, Mohit Sethi, Rene Struik, Behcet Sarikaya
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This document specifies an extension to 6LoWPAN Neighbor Discovery (ND) defined in RFC6775 and updated in [I-D.ietf-6lo-rfc6775-update]. The new extension is called Address Protected Neighbor Discovery (AP- ND) and it protects the owner of an address against address theft and impersonation attacks in a low-power and lossy network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto- ID) and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof-of-ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.
    
draft-ietf-6lo-backbone-router-09.txt
 IPv6 Backbone Router
 
 draft-ietf-6lo-backbone-router-09.txt
 Date: 05/12/2018
 Authors: Pascal Thubert, Charles Perkins, Eric Levy-Abegnoli
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
Backbone Routers are RFC8505 Routing Registrars that provide proxy services for IPv6 Neighbor Discovery. Backbone Routers federate multiple wireless Links over a Backbone Link to form a MultiLink Subnet. Backbone Routers placed along the wireless edge of the Backbone handle IPv6 Neighbor Discovery, and route packets on behalf of registered nodes.
    
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-03.txt
 Packet Delivery Deadline time in 6LoWPAN Routing Header
 
 draft-ietf-6lo-deadline-time-03.txt
 Date: 15/10/2018
 Authors: Lijo Thomas, Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: 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-fragment-recovery-00.txt
 6LoWPAN Selective Fragment Recovery
 
 draft-ietf-6lo-fragment-recovery-00.txt
 Date: 20/09/2018
 Authors: Pascal Thubert
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This draft updates RFC 4944 with a simple protocol to recover individual fragments across a route-over mesh network, with a minimal flow control to protect the network against bloat.
    
draft-ietf-6lo-minimal-fragment-00.txt
 LLN Minimal Fragment Forwarding
 
 draft-ietf-6lo-minimal-fragment-00.txt
 Date: 18/10/2018
 Authors: Thomas Watteyne, Carsten Bormann, Pascal Thubert
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This document gives an overview of LLN Minimal Fragment Forwarding. When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it. This has been always possible with the original fragmentation design of RFC4944. This document is a companion document to [I-D.ietf-lwig-6lowpan-virtual-reassembly], which details the virtual Reassembly Buffer (VRB) implementation technique which reduces the latency and increases end-to-end reliability in route-over forwarding.
    
draft-ietf-6lo-nfc-12.txt
 Transmission of IPv6 Packets over Near Field Communication
 
 draft-ietf-6lo-nfc-12.txt
 Date: 05/11/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: xml txt
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-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-ipv6only-flag-04.txt
 IPv6 Router Advertisement IPv6-Only Flag
 
 draft-ietf-6man-ipv6only-flag-04.txt
 Date: 04/11/2018
 Authors: Robert Hinden, Brian Carpenter
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
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 RFC4861 and RFC5175.
    
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-15.txt
 IPv6 Segment Routing Header (SRH)
 
 draft-ietf-6man-segment-routing-header-15.txt
 Date: 22/10/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-architecture-19.txt
 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4
 
 draft-ietf-6tisch-architecture-19.txt
 Date: 17/12/2018
 Authors: Pascal Thubert
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
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-03.txt
 6tisch Zero-Touch Secure Join protocol
 
 draft-ietf-6tisch-dtsecurity-zerotouch-join-03.txt
 Date: 22/10/2018
 Authors: Michael Richardson
 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-enrollment-enhanced-beacon-00.txt
 IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information
 
 draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt
 Date: 20/07/2018
 Authors: Diego Dujovne, Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
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-ietf-6tisch-minimal-security-09.txt
 Minimal Security Framework for 6TiSCH
 
 draft-ietf-6tisch-minimal-security-09.txt
 Date: 20/11/2018
 Authors: Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml 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, 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-msf-01.txt
 6TiSCH Minimal Scheduling Function (MSF)
 
 draft-ietf-6tisch-msf-01.txt
 Date: 22/10/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: 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-ietf-ace-actors-07.txt
 An architecture for authorization in constrained environments
 
 draft-ietf-ace-actors-07.txt
 Date: 22/10/2018
 Authors: Stefanie Gerdes, Ludwig Seitz, Goeran Selander, Carsten Bormann
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks.
    
draft-ietf-ace-coap-est-06.txt
 EST over secure CoAP (EST-coaps)
 
 draft-ietf-ace-coap-est-06.txt
 Date: 08/10/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: xml pdf txt
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-05.txt
 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
 
 draft-ietf-ace-cwt-proof-of-possession-05.txt
 Date: 09/11/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-05.txt
 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
 
 draft-ietf-ace-dtls-authorize-05.txt
 Date: 08/10/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 that allows constrained servers to delegate client authentication and authorization. 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 server 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-17.txt
 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
 
 draft-ietf-ace-oauth-authz-17.txt
 Date: 26/11/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-oauth-params-01.txt
 Additional OAuth Parameters for Authorization in Constrained Environments (ACE)
 
 draft-ietf-ace-oauth-params-01.txt
 Date: 26/11/2018
 Authors: Ludwig Seitz
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with framework for authentication and authorization for constrained environments (ACE). These are used to express the desired audience of a requested access token, the desired proof-of-possession key, the proof-of-possession key that the AS has selected, and the key the RS should use to authenticate to the client.
    
draft-ietf-ace-oscore-profile-05.txt
 OSCORE profile of the Authentication and Authorization for Constrained Environments Framework
 
 draft-ietf-ace-oscore-profile-05.txt
 Date: 07/11/2018
 Authors: Francesca Palombini, Ludwig Seitz, Goeran Selander, Martin Gunnarsson
 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-17.txt
 Automatic Certificate Management Environment (ACME)
 
 draft-ietf-acme-acme-17.txt
 Date: 17/12/2018
 Authors: Richard Barnes, Jacob Hoffman-Andrews, Daniel McCarney, James Kasten
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
Public Key Infrastructure X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) 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 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-01.txt
 ACME Challenges Using an Authority Token
 
 draft-ietf-acme-authority-token-01.txt
 Date: 22/10/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-01.txt
 TNAuthList profile of ACME Authority Token
 
 draft-ietf-acme-authority-token-tnauthlist-01.txt
 Date: 22/10/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-04.txt
 Extensions to Automatic Certificate Management Environment for end user S/MIME certificates
 
 draft-ietf-acme-email-smime-04.txt
 Date: 19/10/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-05.txt
 Extensions to Automatic Certificate Management Environment for email TLS
 
 draft-ietf-acme-email-tls-05.txt
 Date: 25/07/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-04.txt
 ACME IP Identifier Validation Extension
 
 draft-ietf-acme-ip-04.txt
 Date: 27/07/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-04.txt
 Support for Short-Term,Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)
 
 draft-ietf-acme-star-04.txt
 Date: 19/10/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 unauthorized entity. 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) X.509 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-star-delegation-00.txt
 An ACME Profile for Generating Delegated STAR Certificates
 
 draft-ietf-acme-star-delegation-00.txt
 Date: 13/12/2018
 Authors: Yaron Sheffer, Diego Lopez, Antonio Pastor, Thomas Fossati
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This memo proposes a profile of the ACME protocol that allows the owner of an identifier (e.g., a domain name) to delegate to a third party access to a certificate associated with said identifier. A primary use case is that of a CDN (the third party) terminating TLS sessions on behalf of a content provider (the owner of a domain name). The presented mechanism allows the owner of the identifier to retain control over the delegation and revoke it at any time by cancelling the associated STAR certificate renewal with the ACME CA. Another key property of this mechanism is it does not require any modification to the deployed TLS ecosystem.
    
draft-ietf-acme-tls-alpn-05.txt
 ACME TLS ALPN Challenge Extension
 
 draft-ietf-acme-tls-alpn-05.txt
 Date: 17/08/2018
 Authors: Roland Shoemaker
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
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-04.txt
 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO
 
 draft-ietf-alto-cdni-request-routing-alto-04.txt
 Date: 21/11/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) framework [RFC6707] defines a set of protocols to interconnect 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 described in [RFC7336] is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI). [RFC8008] defines precisely the semantics of FCI and provides guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. In this document, we follow the guidelines to define an FCI protocol using the Application-Layer Traffic Optimization (ALTO) protocol.
    
draft-ietf-alto-cost-calendar-09.txt
 ALTO Cost Calendar
 
 draft-ietf-alto-cost-calendar-09.txt
 Date: 13/11/2018
 Authors: Sabine Randriamasy, Yang Yang, Qin Wu, Deng Lingli, Nico Schwan
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
This document is an extension to the base ALTO protocol [RFC7285]. It extends the ALTO cost information service such that applications decide not only 'where' to connect, but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces ALTO Cost Calendars, with which 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 Information Resources Directory and ALTO Server responses.
    
draft-ietf-alto-incr-update-sse-15.txt
 ALTO Incremental Updates Using Server-Sent Events (SSE)
 
 draft-ietf-alto-incr-update-sse-15.txt
 Date: 10/12/2018
 Authors: Wendy Roome, Y. Yang, Shiwei Chen
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: xml 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 network 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 ALTO 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 ALTO 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-06.txt
 ALTO Performance Cost Metrics
 
 draft-ietf-alto-performance-metrics-06.txt
 Date: 28/11/2018
 Authors: Qin Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: xml txt
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 has documented only one single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [RFC7285]). 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-05.txt
 Unified Properties for the ALTO Protocol
 
 draft-ietf-alto-unified-props-new-05.txt
 Date: 10/12/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-04.txt
 Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
 
 draft-ietf-alto-xdom-disc-04.txt
 Date: 13/11/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 (typically, "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-18.txt
 An Autonomic Control Plane (ACP)
 
 draft-ietf-anima-autonomic-control-plane-18.txt
 Date: 07/08/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-17.txt
 Bootstrapping Remote Secure Key Infrastructures (BRSKI)
 
 draft-ietf-anima-bootstrapping-keyinfra-17.txt
 Date: 05/11/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-02.txt
 Constrained Voucher Artifacts for Bootstrapping Protocols
 
 draft-ietf-anima-constrained-voucher-02.txt
 Date: 11/09/2018
 Authors: Michael Richardson, Peter van der Stok, Panos Kampanakis
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
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: 13/07/2017
 Authors: Carsten Bormann, Brian Carpenter, Bing Liu
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.
    
draft-ietf-anima-grasp-api-02.txt
 Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)
 
 draft-ietf-anima-grasp-api-02.txt
 Date: 29/06/2018
 Authors: Brian Carpenter, Bing Liu, Wendong Wang, Xiangyang Gong
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
This document is a conceptual outline of an application programming interface (API) for the Generic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASA) calling the GRASP protocol module to exchange autonomic network messages with other ASAs.
    
draft-ietf-anima-prefix-management-07.txt
 Autonomic IPv6 Edge Prefix Management in Large-scale Networks
 
 draft-ietf-anima-prefix-management-07.txt
 Date: 18/12/2017
 Authors: Sheng Jiang, Zongpeng Du, Brian Carpenter, Qiong Sun
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure.
    
draft-ietf-anima-reference-model-10.txt
 A Reference Model for Autonomic Networking
 
 draft-ietf-anima-reference-model-10.txt
 Date: 22/11/2018
 Authors: Michael Behringer, Brian Carpenter, Toerless Eckert, Laurent Ciavaglia, Jeferson Nobre
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.
    
draft-ietf-avtcore-cc-feedback-message-02.txt
 RTP Control Protocol (RTCP) Feedback for Congestion Control
 
 draft-ietf-avtcore-cc-feedback-message-02.txt
 Date: 15/07/2018
 Authors: Zaheduzzaman Sarker, Colin Perkins, Varun Singh, Michael Ramalho
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt
This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends RTCP feedback packets to the sender containing the information the sender needs to perform congestion control.
    
draft-ietf-avtcore-multi-media-rtp-session-13.txt
 Sending Multiple Types of Media in a Single RTP Session
 
 draft-ietf-avtcore-multi-media-rtp-session-13.txt
 Date: 18/12/2015
 Authors: Magnus Westerlund, Colin Perkins, Jonathan Lennox
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: xml txt
This document specifies how an RTP session can contain RTP Streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session.
    
draft-ietf-avtcore-multiplex-guidelines-08.txt
 Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams
 
 draft-ietf-avtcore-multiplex-guidelines-08.txt
 Date: 14/12/2018
 Authors: Magnus Westerlund, Bo Burman, Colin Perkins, Harald Alvestrand, Roni Even
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: xml txt
The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability, but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams.
    
draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt
 Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback
 
 draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt
 Date: 02/03/2016
 Authors: Jonathan Lennox, Magnus Westerlund, Qin Wu, Colin Perkins
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt
RTP allows multiple RTP streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios.
    
draft-ietf-avtext-framemarking-08.txt
 Frame Marking RTP Header Extension
 
 draft-ietf-avtext-framemarking-08.txt
 Date: 23/10/2018
 Authors: Mo Zanaty, Espen Berger, Suhas Nandakumar
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt xml
This document describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information.
    
draft-ietf-avtext-lrr-07.txt
 The Layer Refresh Request (LRR) RTCP Feedback Message
 
 draft-ietf-avtext-lrr-07.txt
 Date: 02/07/2017
 Authors: Jonathan Lennox, Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman
 Working Group: Audio/Video Transport Extensions (avtext)
 Formats: xml txt
This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats.
    
draft-ietf-avtext-rid-09.txt
 RTP Stream Identifier Source Description (SDES)
 
 draft-ietf-avtext-rid-09.txt
 Date: 06/10/2016
 Authors: Adam Roach, Suhas Nandakumar, Peter Thatcher
 Working Group: Audio/Video Transport Extensions (avtext)
 Formats: txt
This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair.
    
draft-ietf-babel-applicability-05.txt
 Applicability of the Babel routing protocol
 
 draft-ietf-babel-applicability-05.txt
 Date: 14/11/2018
 Authors: Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. In this document, we argue that there exist niches where Babel is useful and that are not adequately served by more mature protocols.
    
draft-ietf-babel-dtls-02.txt
 Babel Routing Protocol over Datagram Transport Layer Security
 
 draft-ietf-babel-dtls-02.txt
 Date: 14/11/2018
 Authors: Antonin Decimo, David Schinazi, Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
The Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This documents describes a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). This document updates RFC 6126bis.
    
draft-ietf-babel-hmac-01.txt
 HMAC authentication for the Babel routing protocol
 
 draft-ietf-babel-hmac-01.txt
 Date: 14/11/2018
 Authors: Clara Do, Weronika Kolodziejak, Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
This document describes a cryptographic authentication for the Babel routing protocol that has provisions for replay avoidance. This document updates RFC 6126bis and obsoletes RFC 7298.
    
draft-ietf-babel-information-model-04.txt
 Babel Information Model
 
 draft-ietf-babel-information-model-04.txt
 Date: 22/10/2018
 Authors: Barbara Stark
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
This Babel Information Model can be used to create data models under various data modeling regimes (e.g., YANG). It allows a Babel implementation (via a management protocol such as NETCONF) to report on its current state and may allow some limited configuration of protocol constants.
    
draft-ietf-babel-rfc6126bis-07.txt
 The Babel Routing Protocol
 
 draft-ietf-babel-rfc6126bis-07.txt
 Date: 14/11/2018
 Authors: Juliusz Chroboczek, David Schinazi
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557
    
draft-ietf-babel-source-specific-04.txt
 Source-Specific Routing in Babel
 
 draft-ietf-babel-source-specific-04.txt
 Date: 23/10/2018
 Authors: Matthieu Boutier, Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
Source-specific routing (also known as Source-Address Dependent Routing, SADR) is an extension to traditional next-hop routing where packets are forwarded according to both their destination and their source address. This document describes an extension for source- specific routing to the Babel routing protocol.
    
draft-ietf-babel-yang-model-00.txt
 YANG Data Model for Babel
 
 draft-ietf-babel-yang-model-00.txt
 Date: 18/12/2018
 Authors: Mahesh Jethanandani, Barbara Stark
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language.
    
draft-ietf-behave-syslog-nat-logging-06.txt
 Syslog Format for NAT Logging
 
 draft-ietf-behave-syslog-nat-logging-06.txt
 Date: 24/01/2014
 Authors: Zhonghua Chen, Cathy Zhou, Tina Tsou, Tom Taylor
 Working Group: Individual Submissions (none)
 Formats: txt xml
NAT devices are required to log events like creation and deletion of translations and information about the resources the NAT is managing. The logs are required to identify an attacker or a host that was used to launch malicious attacks, and for various other purposes of accounting and management. Since there is no standard way of logging this information, different NAT devices behave differently. The lack of a consistent way makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the information that is required to be logged by the NAT devices. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 7011). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging.
    
draft-ietf-bess-bgp-vpls-control-flags-06.txt
 Updated processing of control flags for BGP VPLS
 
 draft-ietf-bess-bgp-vpls-control-flags-06.txt
 Date: 17/08/2018
 Authors: Ravi Singh, Kireeti Kompella, Senad Palislamovic
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document updates the meaning of the "control flags" fields inside the "layer2 info extended community" used for BGP-VPLS NLRI as defined in RFC4761. If approved, this document updates RFC4761.
    
draft-ietf-bess-dci-evpn-overlay-10.txt
 Interconnect Solution for EVPN Overlay networks
 
 draft-ietf-bess-dci-evpn-overlay-10.txt
 Date: 02/03/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Ali Sajassi, John Drake
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes how Network Virtualization Overlays (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPN) and other L2VPN technologies used in the WAN, such as Virtual Private LAN Services (VPLS), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how the existing technical specifications apply to the Interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, and the use of the Unknown MAC route to avoid MAC scale issues on Data Center Network Virtualization Edge (NVE) devices.
    
draft-ietf-bess-evpn-bum-procedure-updates-05.txt
 Updates on EVPN BUM Procedures
 
 draft-ietf-bess-evpn-bum-procedure-updates-05.txt
 Date: 13/12/2018
 Authors: Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation.
    
draft-ietf-bess-evpn-df-election-framework-06.txt
 Framework for EVPN Designated Forwarder Election Extensibility
 
 draft-ietf-bess-evpn-df-election-framework-06.txt
 Date: 04/12/2018
 Authors: Jorge Rabadan, satyamoh@cisco.com, Ali Sajassi, John Drake, Kiran Nagaraj, Senthil Sathappan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The Designated Forwarder (DF) in EVPN networks is the Provider Edge (PE) router responsible for sending broadcast, unknown unicast and multicast (BUM) traffic to a multi-homed Customer Equipment (CE) device, on a given VLAN on a particular Ethernet Segment (ES). The DF is selected out of a list of candidate PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network. By default, EVPN uses a DF Election algorithm referred to as "Service Carving" and it is based on a modulus function (V mod N) that takes the number of PEs in the ES (N) and the VLAN value (V) as input. This default DF Election algorithm has some inefficiencies that this document addresses by defining a new DF Election algorithm and a capability to influence the DF Election result for a VLAN, depending on the state of the associated Attachment Circuit (AC). In addition, this document creates a registry with IANA, for future DF Election Algorithms and Capabilities. It also presents a formal definition and clarification of the DF Election Finite State Machine.
    
draft-ietf-bess-evpn-igmp-mld-proxy-02.txt
 IGMP and MLD Proxy for EVPN
 
 draft-ietf-bess-evpn-igmp-mld-proxy-02.txt
 Date: 25/06/2018
 Authors: Ali Sajassi, Samir Thoria, Keyur Patel, Derek Yeung, John Drake, Wen Lin
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Ethernet Virtual Private Network (EVPN) solution [RFC 7432] is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services, and in service provider (SP) applications for next generation virtual private LAN services. This draft describes how to support efficiently endpoints running IGMP for the above services over an EVPN network by incorporating IGMP proxy procedures on EVPN PEs.
    
draft-ietf-bess-evpn-inter-subnet-forwarding-05.txt
 Integrated Routing and Bridging in EVPN
 
 draft-ietf-bess-evpn-inter-subnet-forwarding-05.txt
 Date: 18/07/2018
 Authors: Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
EVPN provides an extensible and flexible multi-homing VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and End Devices while maintaining the multi-homing capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements.
    
draft-ietf-bess-evpn-irb-mcast-01.txt
 EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding
 
 draft-ietf-bess-evpn-irb-mcast-01.txt
 Date: 16/07/2018
 Authors: Wen Lin, Zhaohui Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the endusers to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to leave a given router and then reenter that same router. These procedures also accommodate IP multicast traffic that needs to travel to or from systems that are outside the EVPN domain.
    
draft-ietf-bess-evpn-na-flags-02.txt
 Propagation of IPv6 Neighbor Advertisement Flags in EVPN
 
 draft-ietf-bess-evpn-na-flags-02.txt
 Date: 19/10/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. However, if the Neighbor information is learnt via EVPN, the PE would not know if a particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address as this information is not carried in the MAC/IP route advertisements. This document proposes an OPTIONAL advertisement of the Flags defined in [RFC4861] along with the EVPN MAC/IP Advertisement routes, so that an EVPN PE implementing a proxy-ND function can reply to Neighbor Solicitations with the correct Flag information in Neighbor Advertisements.
    
draft-ietf-bess-evpn-optimized-ir-06.txt
 Optimized Ingress Replication solution for EVPN
 
 draft-ietf-bess-evpn-optimized-ir-06.txt
 Date: 19/10/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Wen Lin, Mukul Katiyar, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Network Virtualization Overlay (NVO) networks using EVPN as control plane may use Ingress Replication (IR) or PIM (Protocol Independent Multicast) based trees to convey the overlay BUM traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the NVO core network. IR avoids the dependency on PIM in the NVO network core. While IR provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of IR in NVO networks.
    
draft-ietf-bess-evpn-per-mcast-flow-df-election-00.txt
 Per multicast flow Designated Forwarder Election for EVPN
 
 draft-ietf-bess-evpn-per-mcast-flow-df-election-00.txt
 Date: 04/09/2018
 Authors: Ali Sajassi, mankamana mishra, Samir Thoria, Jorge Rabadan, John Drake
 Working Group: BGP Enabled ServiceS (bess)
 Formats: pdf txt
[RFC7432] describes mechanism to elect designated forwarder (DF) at the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in case of VLAN bundle or VLAN-aware bundle service). However, the current level of granularity of per-VLAN is not adequate for some applications.[I-D.ietf-bess-evpn-df-election-framework] improves base line DF election by introducing HRW DF election. [I-D.ietf-bess-evpn-igmp-mld-proxy] introduces applicability of EVPN to Multicast flows, routes to sync them and a default DF election. This document is an extension to HRW base draft [I-D.ietf-bess-evpn-df-election-framework] and further enhances HRW algorithm for the Multicast flows to do DF election at the granularity of (ESI, VLAN, Mcast flow).
    
draft-ietf-bess-evpn-pref-df-02.txt
 Preference-based EVPN DF Election
 
 draft-ietf-bess-evpn-pref-df-02.txt
 Date: 22/10/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Tony Przygienda, Wen Lin, John Drake, Ali Sajassi, satyamoh@cisco.com
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The Designated Forwarder (DF) in (PBB-)EVPN networks is defined as the PE responsible for sending broadcast, multicast and unknown unicast traffic (BUM) to a multi-homed device/network in the case of an all-active multi-homing ES, or BUM and unicast in the case of single-active multi-homing. The DF is selected out of a candidate list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default DF Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the DF across different EVIs or ISIDs in the ES, there are some use-cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on-demand DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes an extension to the Default DF election procedures so that the above requirements can be met.
    
draft-ietf-bess-evpn-prefix-advertisement-11.txt
 IP Prefix Advertisement in EVPN
 
 draft-ietf-bess-evpn-prefix-advertisement-11.txt
 Date: 18/05/2018
 Authors: Jorge Rabadan, Wim Henderickx, John Drake, Wen Lin, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The BGP MPLS-based Ethernet VPN (EVPN) [RFC7432] mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO (Network Virtualization Overlay) [RFC7365] network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used.
    
draft-ietf-bess-evpn-proxy-arp-nd-05.txt
 Operational Aspects of Proxy-ARP/ND in EVPN Networks
 
 draft-ietf-bess-evpn-proxy-arp-nd-05.txt
 Date: 04/11/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Wim Henderickx, Greg Hankins, Thomas King, Daniel Melzer, Erik Nordmark
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The EVPN MAC/IP Advertisement route can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs. This document describes how the EVPN Proxy-ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains.
    
draft-ietf-bess-evpn-unequal-lb-00.txt
 Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing
 
 draft-ietf-bess-evpn-unequal-lb-00.txt
 Date: 19/09/2018
 Authors: Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
In an EVPN-IRB based network overlay, EVPN LAG enables all-active multi-homing for a host or CE device connected to two or more PEs via a LAG bundle, such that bridged and routed traffic from remote PEs can be equally load balanced (ECMPed) across the multi-homing PEs. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi- homing PEs in order to: o provide greater flexibility, with respect to adding or removing individual PE-CE links within the access LAG o handle PE-CE LAG member link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs
    
draft-ietf-bess-evpn-virtual-eth-segment-00.txt
 EVPN Virtual Ethernet Segment
 
 draft-ietf-bess-evpn-virtual-eth-segment-00.txt
 Date: 19/06/2018
 Authors: Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
EVPN and PBB-EVPN introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced capabilities among which their multi-homing capabilities. These solutions define two types of multi-homing for an Ethernet Segment (ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment is defined as a set of links between the multi-homed device/network and the set of PE devices that they are connected to. Some Service Providers want to extend the concept of the physical links in an ES to Ethernet Virtual Circuits (EVCs) where many of such EVCs can be aggregated on a single physical External Network-to- Network Interface (ENNI). An ES that consists of a set of EVCs instead of physical links is referred to as a virtual ES (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN.
    
draft-ietf-bess-evpn-vpls-seamless-integ-05.txt
 (PBB-)EVPN Seamless Integration with (PBB-)VPLS
 
 draft-ietf-bess-evpn-vpls-seamless-integ-05.txt
 Date: 27/11/2018
 Authors: Ali Sajassi, Samer Salam, Nick Regno, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This draft specifies procedures for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB- EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions (PBB-)VPLS. It also provides mechanisms for seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this draft enables service providers to introduce (PBB-)EVPN PEs in their brown-field deployments of (PBB-)VPLS networks.
    
draft-ietf-bess-evpn-yang-06.txt
 Yang Data Model for EVPN
 
 draft-ietf-bess-evpn-yang-06.txt
 Date: 22/10/2018
 Authors: Patrice Brissette, Himanshu Shah, Iftekhar Hussain, Kishore Tiruveedhula, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes a YANG data model for Ethernet VPN services. The model is agnostic of the underlay. It apply to MPLS as well as to VxLAN encapsulation. The model is also agnostic of the services including E-LAN, E-LINE and E-TREE services. This document mainly focuses on EVPN and Ethernet-Segment instance framework.
    
draft-ietf-bess-l2l3-vpn-mcast-mib-16.txt
 L2L3 VPN Multicast MIB
 
 draft-ietf-bess-l2l3-vpn-mcast-mib-16.txt
 Date: 07/09/2018
 Authors: Zhaohui Zhang, Hiroshi Tsunoda
 Working Group: BGP Enabled ServiceS (bess)
 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 describes two MIB modules which will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast.
    
draft-ietf-bess-l2vpn-yang-09.txt
 YANG Data Model for MPLS-based L2VPN
 
 draft-ietf-bess-l2vpn-yang-09.txt
 Date: 22/10/2018
 Authors: Himanshu Shah, Patrice Brissette, Ing-When Chen, Iftekhar Hussain, Bin Wen, Kishore Tiruveedhula
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes a YANG data model for Layer 2 VPN (L2VPN) services over MPLS networks. These services include point-to-point Virtual Private Wire Service (VPWS) and multipoint Virtual Private LAN service (VPLS) that uses LDP and BGP signaled Pseudowires. It is expected that this model will be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. This document also describes the YANG data model for the Pseudowires. The independent definition of the Pseudowires facilitates its use in Ethernet Segment and EVPN data models defined in separate document.
    
draft-ietf-bess-l3vpn-yang-04.txt
 Yang Data Model for BGP/MPLS L3 VPNs
 
 draft-ietf-bess-l3vpn-yang-04.txt
 Date: 19/10/2018
 Authors: Dhanendra Jain, Keyur Patel, Patrice Brissette, Zhenbin Li, Shunwan Zhuang, Xufeng Liu, Jeffrey Haas, Santosh Esale, Bin Wen
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage BGP Layer 3 VPNs.
    
draft-ietf-bess-mvpn-evpn-aggregation-label-02.txt
 MVPN/EVPN Tunnel Aggregation with Common Labels
 
 draft-ietf-bess-mvpn-evpn-aggregation-label-02.txt
 Date: 18/12/2018
 Authors: Zhaohui Zhang, Eric Rosen, Wen Lin, Zhenbin Li, IJsbrand Wijnands
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple VPNs. The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD. (In some cases, a distinct upstream-assigned is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures.
    
draft-ietf-bess-mvpn-expl-track-13.txt
 Explicit Tracking with Wild Card Routes in Multicast VPN
 
 draft-ietf-bess-mvpn-expl-track-13.txt
 Date: 28/11/2018
 Authors: Andrew Dolganow, Jayant Kotalwar, Eric Rosen, Zhaohui Zhang
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The Multicast VPN (MVPN) specifications provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, 7524, 7582, and 7900.
    
draft-ietf-bess-mvpn-fast-failover-04.txt
 Multicast VPN fast upstream failover
 
 draft-ietf-bess-mvpn-fast-failover-04.txt
 Date: 06/11/2018
 Authors: Thomas Morin, Robert Kebler, Gregory Mirsky
 Working Group: BGP Enabled ServiceS (bess)
 Formats: xml txt
This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a standby upstream PE.
    
draft-ietf-bess-mvpn-mib-12.txt
 BGP/MPLS Layer 3 VPN Multicast Management Information Base
 
 draft-ietf-bess-mvpn-mib-12.txt
 Date: 16/09/2018
 Authors: Hiroshi Tsunoda
 Working Group: BGP Enabled ServiceS (bess)
 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 describes managed objects to configure and/or monitor Multicast communication over IP Virtual Private Networks (VPNs) supported by MultiProtocol Label Switching/Border Gateway Protcol (MPLS/BGP) on a Provider Edge router.
    
draft-ietf-bess-nsh-bgp-control-plane-04.txt
 BGP Control Plane for NSH SFC
 
 draft-ietf-bess-nsh-bgp-control-plane-04.txt
 Date: 01/07/2018
 Authors: Adrian Farrel, John Drake, Eric Rosen, Jim Uttaro, Luay Jalil
 Working Group: BGP Enabled ServiceS (bess)
 Formats: xml txt
This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC AFI/SAFI with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header. This document adopts the SFC architecture described in RFC 7665.
    
draft-ietf-bess-service-chaining-06.txt
 Service Function Chaining using Virtual Networks with BGP VPNs
 
 draft-ietf-bess-service-chaining-06.txt
 Date: 04/12/2018
 Authors: Rex Fernando, Stuart Mackie, Dhananjaya Rao, Bruno Rijsman, Maria Napierala, Thomas Morin
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt xml
This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain.
    
draft-ietf-bess-vpls-multihoming-02.txt
 BGP based Multi-homing in Virtual Private LAN Service
 
 draft-ietf-bess-vpls-multihoming-02.txt
 Date: 14/09/2018
 Authors: Bhupesh Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, Jim Uttaro
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions.
    
draft-ietf-bfcpbis-bfcp-websocket-15.txt
 The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)
 
 draft-ietf-bfcpbis-bfcp-websocket-15.txt
 Date: 08/02/2017
 Authors: Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo Salgueiro, Ram R
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies the use of Binary Floor Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliable transport mechanism between BFCP entities in new scenarios.
    
draft-ietf-bfcpbis-rfc4582bis-16.txt
 The Binary Floor Control Protocol (BFCP)
 
 draft-ietf-bfcpbis-rfc4582bis-16.txt
 Date: 13/11/2015
 Authors: Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16.
    
draft-ietf-bfcpbis-rfc4583bis-27.txt
 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
 
 draft-ietf-bfcpbis-rfc4583bis-27.txt
 Date: 08/12/2018
 Authors: Gonzalo Camarillo, Tom Kristensen, Christer Holmberg
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: xml txt
This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing Binary Floor Control Protocol (BFCP) streams. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 14.
    
draft-ietf-bfd-multipoint-19.txt
 BFD for Multipoint Networks
 
 draft-ietf-bfd-multipoint-19.txt
 Date: 13/12/2018
 Authors: Dave Katz, David Ward, Juniper Networks, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. This document updates RFC 5880.
    
draft-ietf-bfd-multipoint-active-tail-10.txt
 BFD Multipoint Active Tails.
 
 draft-ietf-bfd-multipoint-active-tail-10.txt
 Date: 28/11/2018
 Authors: Dave Katz, David Ward, Juniper Networks, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: xml txt
This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks.
    
draft-ietf-bfd-optimizing-authentication-07.txt
 Optimizing BFD Authentication
 
 draft-ietf-bfd-optimizing-authentication-07.txt
 Date: 08/11/2018
 Authors: Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC5880.
    
draft-ietf-bfd-vxlan-04.txt
 BFD for VXLAN
 
 draft-ietf-bfd-vxlan-04.txt
 Date: 23/11/2018
 Authors: Juniper Networks, Sudarsan Paragiri, Vengada Govindan, Mallik Mudigonda, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: xml txt
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay networks.
    
draft-ietf-bfd-yang-17.txt
 YANG Data Model for Bidirectional Forwarding Detection (BFD)
 
 draft-ietf-bfd-yang-17.txt
 Date: 02/08/2018
 Authors: Reshad Rahman, Lianshu Zheng, Mahesh Jethanandani, Juniper Networks, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).
    
draft-ietf-bier-bar-ipa-03.txt
 BIER Underlay Path Calculation Algorithm and Constraints
 
 draft-ietf-bier-bar-ipa-03.txt
 Date: 16/11/2018
 Authors: Zhaohui Zhang, Tony Przygienda, Andrew Dolganow, Hooman Bidgoli, IJsbrand Wijnands, Arkadiy Gulko
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
This document specifies general rules for interaction between the BAR (BIER Algorithm) and IPA (IGP Algorithm) fields defined in ISIS/ OSPFv2 Extensions for BIER.
    
draft-ietf-bier-bgp-ls-bier-ext-04.txt
 BGP Link-State extensions for BIER
 
 draft-ietf-bier-bgp-ls-bier-ext-04.txt
 Date: 07/10/2018
 Authors: Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any 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. The BIER header contains a bitstring 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 setting the bits that correspond to those routers in the BIER header. This document specifies extensions to the BGP Link-state address- family in order to advertising BIER information.
    
draft-ietf-bier-bier-yang-04.txt
 YANG Data Model for BIER Protocol
 
 draft-ietf-bier-bier-yang-04.txt
 Date: 29/09/2018
 Authors: Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
This document defines a YANG data model for BIER configuration and operation.
    
draft-ietf-bier-entropy-staged-dc-clos-00.txt
 Use of BIER Entropy for Data Center CLOS Networks
 
 draft-ietf-bier-entropy-staged-dc-clos-00.txt
 Date: 05/11/2018
 Authors: Jingrong Xie, Xiaohu Xu, Gang Yan, Mike McBride
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) introduces a new multicast- specific BIER Header. BIER can be applied to the Multi Protocol Label Switching (MPLS) data plane or Non-MPLS data plane. Entropy is a technique used in BIER to support load-balancing. This document examines and describes how BIER Entropy is to be applied to Data Center CLOS networks for path selection.
    
draft-ietf-bier-mld-01.txt
 BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols
 
 draft-ietf-bier-mld-01.txt
 Date: 29/06/2018
 Authors: Pierre Pfister, IJsbrand Wijnands, Stig Venaas, Cui(Linda) Wang, Zheng Zhang, Markus Stenberg
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
This document specifies the ingress part of a multicast flow overlay for BIER networks. Using existing multicast listener discovery protocols, it enables multicast membership information sharing from egress routers, acting as listeners, toward ingress routers, acting as queriers. Ingress routers keep per-egress-router state, used to construct the BIER bit mask associated with IP multicast packets entering the BIER domain.
    
draft-ietf-bier-mvpn-11.txt
 Multicast VPN Using BIER
 
 draft-ietf-bier-mvpn-11.txt
 Date: 19/03/2018
 Authors: Eric Rosen, Mahesh Sivakumar, Sam Aldrin, Andrew Dolganow, Tony Przygienda
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a Service Provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over an SP backbone network.
    
draft-ietf-bier-non-mpls-bift-encoding-01.txt
 An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation
 
 draft-ietf-bier-non-mpls-bift-encoding-01.txt
 Date: 18/10/2018
 Authors: IJsbrand Wijnands, Xiaohu Xu, Hooman Bidgoli
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The Multicast packet is encapsulated using a BIER Header and transported through an MPLS or non-MPLS network. When MPLS is used as the transport, the Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. When non-MPLS transport is used, the BIFT is identified by a 20bit value. This document describes one way of encoding the 20bit value.
    
draft-ietf-bier-oam-requirements-06.txt
 Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer
 
 draft-ietf-bier-oam-requirements-06.txt
 Date: 28/08/2018
 Authors: Gregory Mirsky, Erik Nordmark, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Lianshu Zheng, Mach Chen, Nobo Akiya, Santosh Pallagatti
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt xml
This document describes a list of functional requirement toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network.
    
draft-ietf-bier-path-mtu-discovery-05.txt
 Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer
 
 draft-ietf-bier-path-mtu-discovery-05.txt
 Date: 18/12/2018
 Authors: Gregory Mirsky, Tony Przygienda, Andrew Dolganow
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt xml
This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer.
    
draft-ietf-bier-php-01.txt
 BIER Penultimate Hop Popping
 
 draft-ietf-bier-php-01.txt
 Date: 28/11/2018
 Authors: Zhaohui Zhang
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) can be used as provider tunnel for MVPN/GTM [RFC6514] [RFC7716] or EVPN BUM [RFC7432]. It is possible that not all routers in the provider network support BIER and there are various methods to handle BIER incapable transit routers. However the MVPN/EVPN PEs are assumed to be BIER capable - they are BFIRs/BFERs. This document specifies a method to allow BIER incapable routers to act as MVPN/EVPN PEs with BIER as the transport, by having the upstream BFR (connected directly or indirectly via a tunnel) of a PE remove the BIER header and send the payload to the PE.
    
draft-ietf-bier-pim-signaling-04.txt
 PIM Signaling Through BIER Core
 
 draft-ietf-bier-pim-signaling-04.txt
 Date: 17/10/2018
 Authors: Hooman Bidgoli, Andrew Dolganow, Jayant Kotalwar, Fengman Xu, mankamana mishra, Zhaohui Zhang
 Working Group: Bit Indexed Explicit Replication (bier)
 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-ietf-bier-ping-04.txt
 BIER Ping and Trace
 
 draft-ietf-bier-ping-04.txt
 Date: 21/10/2018
 Authors: Nagendra Kumar, Carlos Pignataro, Nobo Akiya, Lianshu Zheng, Mach Chen, Gregory Mirsky
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt xml
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any 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. The BIER 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 setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on BIER data plane.
    
draft-ietf-bier-pmmm-oam-05.txt
 Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer
 
 draft-ietf-bier-pmmm-oam-05.txt
 Date: 11/12/2018
 Authors: Gregory Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
This document describes a hybrid performance measurement method for multicast service over Bit Index Explicit Replication (BIER) domain.
    
draft-ietf-bier-te-arch-01.txt
 Traffic Engineering for Bit Index Explicit Replication (BIER-TE)
 
 draft-ietf-bier-te-arch-01.txt
 Date: 23/10/2018
 Authors: Toerless Eckert, Gregory Cauchie, Wolfgang Braun, Michael Menth
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
This document proposes an architecture for BIER-TE: Traffic Engineering for Bit Index Explicit Replication (BIER). BIER-TE shares part of its architecture with BIER as described in [RFC8279]. It also proposes to share the packet format with BIER. BIER-TE forwards and replicates packets like BIER based on a BitString in the packet header but it does not require an IGP. It does support traffic engineering by explicit hop-by-hop forwarding and loose hop forwarding of packets. It does support Fast ReRoute (FRR) for link and node protection and incremental deployment. Because BIER-TE like BIER operates without explicit in-network tree- building but also supports traffic engineering, it is more similar to SR than RSVP-TE.
    
draft-ietf-bier-use-cases-07.txt
 BIER Use Cases
 
 draft-ietf-bier-use-cases-07.txt
 Date: 28/07/2018
 Authors: Nagendra Kumar, Rajiv Asati, Mach Chen, Xiaohu Xu, Andrew Dolganow, Tony Przygienda, Arkadiy Gulko, Dom Robinson, Vishal Arya, Caitlin Bestler
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt xml
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any 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. The BIER 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 setting the bits that correspond to those routers in the BIER header. This document describes some of the use-cases for BIER.
    
draft-ietf-bmwg-evpntest-01.txt
 Benchmarking Methodology for EVPN and PBB-EVPN
 
 draft-ietf-bmwg-evpntest-01.txt
 Date: 26/11/2018
 Authors: sudhin jacob, Kishore Tiruveedhula
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
This document defines methodologies for benchmarking EVPN and PBB- EVPN performance. EVPN is defined in RFC 7432, and is being deployed in Service Provider networks. Specifically this document defines the methodologies for benchmarking EVPN/PBB-EVPN convergence, data plane performance, and control plane performance.
    
draft-ietf-calext-caldav-attachments-03.txt
 CalDAV Managed Attachments
 
 draft-ietf-calext-caldav-attachments-03.txt
 Date: 24/07/2017
 Authors: Cyrus Daboo, Arnaud Quillaud, Ken Murchison
 Working Group: Calendaring Extensions (calext)
 Formats: txt xml
This specification defines an extension to the calendar access protocol (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server. This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards-Track due to its non-standard method of updating an existing resource via HTTP.
    
draft-ietf-calext-eventpub-extensions-10.txt
 Event Publishing Extensions to iCalendar
 
 draft-ietf-calext-eventpub-extensions-10.txt
 Date: 19/10/2018
 Authors: Michael Douglass
 Working Group: Calendaring Extensions (calext)
 Formats: pdf xml txt