Internet Drafts - Sorted by name


    
draft-7996-bis-00.txt
 SVG Drawings for RFCs: SVG 1.2 RFC
 
 draft-7996-bis-00.txt
 Date: 12/12/2017
 Authors: Nevil Brownlee
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies SVG 1.2 RFC - an SVG profile for use in diagrams that may appear in RFCs - and considers some of the issues concerning the creation and use of such diagrams.
    
draft-aanchal-time-implementation-guidance-00.txt
 On Implementing Time
 
 draft-aanchal-time-implementation-guidance-00.txt
 Date: 30/10/2017
 Authors: Aanchal Malhotra, Martin Hoffmann, Willem Toorop
 Working Group: Network Time Protocol (ntp)
 Formats: xml txt
This document describes the properties of different types of time values available on digital systems and provides guidance on choices of these time values to the implementors of applications that use time in some form to provide the basic functionality and security guarantees.
    
draft-aboba-avtcore-quic-multiplexing-01.txt
 QUIC Multiplexing
 
 draft-aboba-avtcore-quic-multiplexing-01.txt
 Date: 29/10/2017
 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 STUN flows running on a single UDP port. This memo discusses options for how to perform such demultiplexing. It also considers demultiplexing of QUIC and WebRTC traffic (both media and data) when running on a single UDP port.
    
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-02.txt
 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery
 
 draft-acee-idr-lldp-peer-discovery-02.txt
 Date: 26/12/2017
 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-rtgwg-yang-rib-extend-06.txt
 RIB YANG Data Model
 
 draft-acee-rtgwg-yang-rib-extend-06.txt
 Date: 08/01/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. The document [ROUTING-CFG] 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-01.txt
 Deprecating ASM for Interdomain Multicast
 
 draft-acg-mboned-deprecate-interdomain-asm-01.txt
 Date: 29/03/2018
 Authors: Mikael Abrahamsson, Tim Chown, Leonard Giuliano, Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-add-ackfreq-to-tcp-00.txt
 Custom TCP Ack. Frequency
 
 draft-add-ackfreq-to-tcp-00.txt
 Date: 26/11/2017
 Authors: Marc Larue
 Working Group: Individual Submissions (none)
 Formats: txt
You should be able to configure the amount of unacknowledged packets a tcp socket uses to throttle sends.
    
draft-adubey-bfd-service-redundancy-01.txt
 Service Redundancy using BFD
 
 draft-adubey-bfd-service-redundancy-01.txt
 Date: 27/11/2017
 Authors: Sami Boutros, Ankur Dubey, Reshad Rahman
 Working Group: Individual Submissions (none)
 Formats: txt
In a data center, when multiple routing/service nodes are providing single active redundancy for a set of L2, L3 and/or L4-L7 services. Both non-revertive and revertive fail over modes are required for the services. This draft describes a method to achieve the non-revertive and revertive fail over modes for services using Bidirectional Forwarding Detection (BFD).
    
draft-ahn-manet-dsr-crri-02.txt
 DSR Extensions for the Resolution of Cached Route Reply Implosion
 
 draft-ahn-manet-dsr-crri-02.txt
 Date: 30/11/2017
 Authors: Sanghyun Ahn
 Working Group: Individual Submissions (none)
 Formats: txt
In DSR, a node can generate a route reply in response to a received route request if it has a fresh route to the destination in its route cache. However, this can incur the cached route reply implosion problem and DSR just tries to mitigate this problem by reducing the possibility of cached route reply collisions. This document describes how DSR can be extended for the resolution of the cached route reply problem.
    
draft-ahn-manet-dsr-vanet-01.txt
 DSR Usage for the VANET Routing
 
 draft-ahn-manet-dsr-vanet-01.txt
 Date: 30/11/2017
 Authors: Sanghyun Ahn
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how DSR [1] can be applied in the vehicular ad hoc network (VANET) environment. Since DSR uses the source routing mechanism, it can be appropriate for the VANET routing mechanisms operating based on the source routing. Therefore, in this draft, we describe how we can modify DSR for the VANET source routing.
    
draft-ahn-manet-multipath-aodv-00.txt
 AODV Extensions for Multipath Routing
 
 draft-ahn-manet-multipath-aodv-00.txt
 Date: 30/11/2017
 Authors: Sanghyun Ahn
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how AODV [1] can be extended for the support of MANET multipath routing. In AODV, the route information is not avilable either at the source or at the destination. So, AODV is less appropriate in establishing multiple routes with more desirable properties, compared with DSR [2]. But, for the sake of reliability and load balancing, in this draft, we describe how we can extend AODV to establish multiple routes from the source to the destination.
    
draft-ahn-manet-multipath-dsr-01.txt
 DSR Extensions for Multipath Routing
 
 draft-ahn-manet-multipath-dsr-01.txt
 Date: 30/11/2017
 Authors: Sanghyun Ahn
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how DSR [1] can be extended for the support of MANET multipath routing. In DSR, the route record informatio is available at the destination, so the destination can select multiple routes with good characteristics and notify the source of them. Therefore, in this draft, we describe how we can extend the Route Request option to specify the number of routes selected at the destination.
    
draft-alavarez-hamelin-tictoc-sic-00.txt
 Synchronizing Internet Clocks (sic)
 
 draft-alavarez-hamelin-tictoc-sic-00.txt
 Date: 28/02/2018
 Authors: Jose Alvarez-Hamelin, David Samaniego, Alfredo Ortega
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo introduces 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. This type of synchronization is useful for some kind of measurements, like traffic, load, or relative time measurements. The "sic" proposal is highly accurate, with an MTIE (Maximum Time Interval Error) less than 25 microseconds by a minute for the 90% of the cases, and it is based on a regular packets exchange.
    
draft-ali-spring-bfd-sr-policy-00.txt
 Bidirectional Forwarding Detection (BFD) for Segment Routing Policies for Traffic Engineering
 
 draft-ali-spring-bfd-sr-policy-00.txt
 Date: 05/03/2018
 Authors: Zafar Ali, Ketan Talaulikar, Clarence Filsfils
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path using a segment list which is referred to as a SR Policy. Intermediate per-flow states are eliminated thanks to source routing. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. Bidirectional Forwarding Detection (BFD) is used to monitor different kinds of paths between node. BFD mechanisms can be also used to monitor the availability of the path indicated by a SR Policy and to detect any failures. Seamless BFD (SBFD) extensions provide a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale. This document describes the use of Seamless BFD (SBFD) mechanism to monitor the SR Policies that are used for Traffic Engineering (TE) in SR deployments.
    
draft-ali-spring-sr-traffic-accounting-00.txt
 Traffic Accounting in Segment Routing Networks
 
 draft-ali-spring-sr-traffic-accounting-00.txt
 Date: 05/03/2018
 Authors: Zafar Ali, Clarence Filsfils, Ketan Talaulikar, Siva Sivabalan, Martin Horneffer, Robert Raszuk, Stephane Litkowski, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
Capacity planning is the continuous art of forecasting traffic load and failures to evolve the network topology, its capacity, and its routing to meet a defined Service-Level Agreement (SLA). This document takes a holistic view of network capacity planning and identifies the role of traffic accounting in network operation and capacity planning, without creating any additional states in the SR fabric.
    
draft-ali-spring-srv6-oam-00.txt
 Operations,Administration,and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
 
 draft-ali-spring-srv6-oam-00.txt
 Date: 26/02/2018
 Authors: Zafar Ali, Clarence Filsfils, Nagendra Kumar, Carlos Pignataro, faiqbal@cisco.com, Rakesh Gandhi, John Leddy, Satoru Matsushima, Robert Raszuk, Bart Peirens, Gaurav Naik
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes mechanisms for Operations, Administration, and Maintenance (OAM) in Segment Routing with IPv6 data plane (SRv6) network.
    
draft-allen-sipcore-sip-tree-cap-indicators-02.txt
 Internet Assigned Numbers Authority (IANA) Registration of the Session Initiation Protocol (SIP) Feature-Capability indicators
 
 draft-allen-sipcore-sip-tree-cap-indicators-02.txt
 Date: 18/01/2018
 Authors: Andrew Allen, Roland Jesske
 Working Group: Individual Submissions (none)
 Formats: txt
This document registers with IANA SIP Feature-Capability indicators in the "SIP Feature-Capability Indicator Registration Tree" of the IANA "Proxy-Feature Feature-Capability Indicator Trees" registry for use with the SIP Feature-Caps header field and defines their usage and interpretation.
    
draft-am-bfd-performance-00.txt
 BFD Performance Measurement
 
 draft-am-bfd-performance-00.txt
 Date: 25/11/2017
 Authors: Ashesh Mishra, Mahesh Jethanandani
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document describes an extension to the Bidirectional Forwarding Detection (BFD) protocol to determine the optimal BFD transmit interval for links with high one-way delay.
    
draft-ama-mpls-fm-rdi-00.txt
 Reverse Defect Indicator for MPLS FM OAM
 
 draft-ama-mpls-fm-rdi-00.txt
 Date: 25/11/2017
 Authors: Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document describes extensions to the MPLS Fault Management Operations, Administration, and Management (MPLS FM OAM) in RFC 6427 [RFC6427] to support Remote Defect Indication (RDI) functionality. Specifically, it describes a mechanism for propagating MPLS FM OAM messages to the upstream Label Edge Router (LER) in MPLS-TP [RFC5921] bi-directional (associated and co-routed) Label Switched Paths (LSPs).
    
draft-amf-ippm-route-01.txt
 Advanced Unidirectional Route Assessment
 
 draft-amf-ippm-route-01.txt
 Date: 26/10/2017
 Authors: Jose Alvarez-Hamelin, Al Morton, Joachim Fabini
 Working Group: Individual Submissions (none)
 Formats: xml txt
This memo introduces an advanced unidirectional route assessment metric and associated measurement methodology, based on the IP Performance Metrics (IPPM) Framework RFC 2330. This memo updates RFC 2330 in the areas of path-related terminology and path description, primarily to include the possibility of parallel subpaths between a given Source and Destination pair, owing to the presence of multi- path technologies.
    
draft-amsuess-core-rd-replication-01.txt
 Resource Directory Replication
 
 draft-amsuess-core-rd-replication-01.txt
 Date: 02/03/2018
 Authors: Christian Amsuess
 Working Group: Individual Submissions (none)
 Formats: xml txt
Discovery of endpoints and resources in M2M applications over large networks is enabled by Resource Directories, but no special consideration has been given to how such directories can scale beyond what can be managed by a single device. This document explores different ways in which Resource Directories can be scaled up from single network to enterprise and global scale. It does not attempt to standardize any of those methods, but only to demonstrate the feasibility of such extensions and to provide terminology and exploratory groundwork for later documents.
    
draft-an-savi-mib-14.txt
 Definition of Managed Objects for SAVI Protocol
 
 draft-an-savi-mib-14.txt
 Date: 15/01/2018
 Authors: Changqing An, Jiahai Yang, Jianping Wu, Jun Bi
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing SAVI (Source Address Validation Improvements) protocol instance.
    
draft-an-savi-yang-03.txt
 A Yang Data Model for SAVI Management
 
 draft-an-savi-yang-03.txt
 Date: 08/02/2018
 Authors: Changqing An, Jiahai Yang, Jianping Wu, Jun Bi
 Working Group: Individual Submissions (none)
 Formats: txt
This document contains a specification of YANG modules for the management of SAVI (Source Address Validation Improvements) protocol. The core SAVI data module ietf-savi serves as a framework for configuring and managing SAVI instance and provides common building blocks. It is expected to be augmented by additional YANG modules for specific IP address assignment methods. The other four modules augment the core SAVI data module and define data models for different IP address assignment methods. Module ietf-savi-fcfs defines module specific for Stateless Address Auto Configuration (SLAAC), module ietf-savi-dhcpv4 and ietf-savi-dhcpv6 define modules specific for Dynamic Host Configuration Protocol version 4 and version 6 (DHCPv4 and DHCPv6), and module ietf-savi- send defines module specific for Secure Neighbor Discovery (SEND).
    
draft-anand-ippm-po-ioam-00.txt
 Integrated Packet-Optical In-Situ OAM
 
 draft-anand-ippm-po-ioam-00.txt
 Date: 26/02/2018
 Authors: Madhukar Anand, Sanjoy Bardhan, Radha Valiveti, Ramesh Subrahmaniam, Carlos Pignataro, Shwetha Bhandari, Randy Zhang, Rajiv Asati
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a way to extend in-situ OAM techniques to include operational data from multiple network layers with a view to create an integrated record of OAM information as the data flows between two network entities. An instance of this technique that is elaborated here focuses on packet-optical networks that are traditionally transport centric. The mechanisms described are general enough to allow future extensibility of in-situ OAM techniques into other non-packet domains.
    
draft-anand-spring-poi-sr-05.txt
 Packet-Optical Integration in Segment Routing
 
 draft-anand-spring-poi-sr-05.txt
 Date: 06/02/2018
 Authors: Madhukar Anand, Sanjoy Bardhan, Ramesh Subrahmaniam, Jeff Tantsura, Utpal Mukhopadhyaya, Clarence Filsfils
 Working Group: Individual Submissions (none)
 Formats: txt
This document illustrates a way to integrate a new class of nodes and links in segment routing to represent transport networks in an opaque way into the segment routing domain. An instance of this class would be optical networks that are typically transport centric. In the IP centric network, this will help in defining a common control protocol for packet optical integration that will include optical paths as 'transport segments' or sub-paths as an augmentation to packet paths. The transport segment option also defines a general mechanism to allow for future extensibility of segment routing into non-packet domains.
    
draft-ananthakrishnan-pce-stateful-path-protection-05.txt
 PCEP Extensions for MPSL-TE LSP Path Protection with stateful PCE
 
 draft-ananthakrishnan-pce-stateful-path-protection-05.txt
 Date: 27/02/2018
 Authors: Hariharan Ananthakrishnan, Siva Sivabalan, Colby Barth, Raveendra Torvi, Ina Minei, Edward Crabbe, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: xml txt
A stateful Path Computation Element (PCE) is capable of computing as well as controlling via Path Computation Element Protocol (PCEP) Multiprotocol Label Switching Traffic Engineering Label Switched Paths (MPLS LSP). Furthermore, it is also possible for a stateful PCE to create, maintain, and delete LSPs. This document describes PCEP extension to associate two or more LSPs to provide end-to-end path protection.
    
draft-andersdotter-intarea-update-to-rfc6302-00.txt
 An update to RFC6302 on Logging Recommendations for Internet-Facing Servers
 
 draft-andersdotter-intarea-update-to-rfc6302-00.txt
 Date: 22/04/2018
 Authors: Amelia Andersdotter
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft seeks to update RFC6302 on Logging Recommendations for Internet-Facing Servers. The new recommendations aim to be a best practice for service providers and server maintainers, by following recommendations outlined in RFC6973 and taking into account new regulatory requirements in the privacy area.
    
draft-andersen-historic-4406-etal-01.txt
 Status Change for RFCs 4405,4406,4407 to Historic
 
 draft-andersen-historic-4406-etal-01.txt
 Date: 24/03/2018
 Authors: Kurt Andersen
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
This document acknowledges that Sender ID did not pass its experiment, and changes the status of RFCs 4405 [RFC4405], 4406 [RFC4406], and 4407 [RFC4407] to Historic.
    
draft-anish-reliable-pim-registers-02.txt
 Reliable Transport For PIM Register States
 
 draft-anish-reliable-pim-registers-02.txt
 Date: 19/03/2018
 Authors: Anish Peter, Robert Kebler, Vikram Nagarajan, Toerless Eckert, Stig Venaas
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a hard-state, reliable transport for the existing PIM-SM registers states. This eliminates the needs for periodic NULL-registers and register-stop in response to each data- register or NULL-registers. This specification uses the existing PIM reliability mechanisms defined by PIM Over Reliable Transport [RFC6559]. This is simply a means to transmit reliable PIM messages and does not require the support for Join/Prune messages over PORT as defined in [RFC6559].
    
draft-ao-nvo3-multi-encap-interconnect-00.txt
 Multi-encapsulation interconnection for Overlay Virtual Network
 
 draft-ao-nvo3-multi-encap-interconnect-00.txt
 Date: 01/03/2018
 Authors: Ting Ao, Gregory Mirsky, Fan Yongbing
 Working Group: Individual Submissions (none)
 Formats: txt
For an virtualized overlay network, there are many encapsulations that may be used. Different customer have their own preference. So if some of these different encapsulation can be interconnected together, the virtualized overlay network would be more compatible and have loose strict on access. This document is going to provide an architecture of different overlay encapsulation interconnection and an tranformer gateway for these end station connected to the virtual network.
    
draft-ao-sfc-oam-path-consistency-02.txt
 SFC OAM for path consistency
 
 draft-ao-sfc-oam-path-consistency-02.txt
 Date: 28/02/2018
 Authors: Ting Ao, Gregory Mirsky, Zhonghua Chen
 Working Group: Individual Submissions (none)
 Formats: txt
Service Function Chain (SFC) defines an ordered set of service functions (SFs) to be applied to packets and/or frames and/or flows selected as a result of classification. SFC Operation, Administration and Maintenance can monitor the continuity of the SFC, i.e., that all elements of the SFC are reachable to each other in the downstream direction. But SFC OAM must support verification that the order of traversing these SFs corresponds to the state defined by the SFC control plane or orchestrator, the metric referred in this document as the path consistency of the SFC. This document defines a new SFC OAM method to support SFC consistency, i.e. verification that all elements of the given SFC are being traversed in the expected order.
    
draft-ao-sfc-oam-return-path-specified-01.txt
 Controlled Return Path for Service Function Chain (SFC) OAM
 
 draft-ao-sfc-oam-return-path-specified-01.txt
 Date: 27/10/2017
 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 robustness of SFC OAM.
    
draft-ao-sfc-scalability-analysis-03.txt
 Analysis of the SFC scalability
 
 draft-ao-sfc-scalability-analysis-03.txt
 Date: 30/10/2017
 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-aragon-ace-ipsec-profile-01.txt
 IPsec profile of ACE
 
 draft-aragon-ace-ipsec-profile-01.txt
 Date: 29/10/2017
 Authors: Santiago Aragon, Marco Tiloca, Shahid Raza
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a profile of the ACE framework for authentication and authorization. It uses the IPsec protocol suite and the IKEv2 protocol to ensure secure communication, server authentication and proof-of-possession for a key bound to an OAuth 2.0 access token.
    
draft-aranda-nfvrg-recursive-vnf-05.txt
 High-level VNF Descriptors using NEMO
 
 draft-aranda-nfvrg-recursive-vnf-05.txt
 Date: 26/02/2018
 Authors: Pedro Gutierrez, Diego Lopez, Stefano Salsano, Elena Batanero
 Working Group: Individual Submissions (none)
 Formats: xml txt
Current efforts in the scope of Network Function Virtualisation(NFV) propose YAML-based descriptors for Virtual Network Functions (VNFs) and for their composition in Network Services (NS) These descriptors are human-readable but hardly understandable by humans. On the other hand, there has been an effort proposed to the IETF to define a human-readable (and understandable) representation for networks, known as NEMO. In this draft, we propose a simple extension to NEMO to accommodate VNF Descriptors (VNFDs) in a similar manner as inline assembly is integrated in higher-level programming languages. This approach enables the creation of recursive VNF forwarding graphs in Service Descriptors, practically making them recursive. An implementation generating VNF Descriptors (VNFDs) for OpenMANO and OSM is available.
    
draft-arias-noguchi-dnrd-objects-mapping-07.txt
 Domain Name Registration Data (DNRD) Objects Mapping
 
 draft-arias-noguchi-dnrd-objects-mapping-07.txt
 Date: 22/03/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-arkko-arch-low-latency-02.txt
 Low Latency Applications and the Internet Architecture
 
 draft-arkko-arch-low-latency-02.txt
 Date: 30/10/2017
 Authors: Jari Arkko, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
Some recent Internet technology developments relate to improvements in communications latency. For instance, improvements in radio communications or the recent work in IETF transport, security, and web protocols. There are also potential applications where latency would play a more significant role than it has traditionally been in the Internet communications. Modern networking systems offer many tools for building low-latency networks, from highly optimised individual protocol components to software controlled, virtualised and tailored network functions. This memo views the developments from a system viewpoint, and considers the potential future stresses that the strive for low-latency support for applications may bring.
    
draft-arkko-arch-virtualization-01.txt
 Considerations on Network Virtualization and Slicing
 
 draft-arkko-arch-virtualization-01.txt
 Date: 05/03/2018
 Authors: Jari Arkko, Jeff Tantsura, Joel Halpern, Balazs Varga
 Working Group: Individual Submissions (none)
 Formats: txt
This document makes some observations on the effects of virtualization on Internet architecture, as well as provides some guidelines for further work at the IETF relating to virtualization. This document also provides a summary of IETF technologies that relate to network virtualization. An understanding of what current technologies there exist and what they can or cannot do is the first step in developing plans for possible extensions.
    
draft-arkko-eap-aka-pfs-01.txt
 Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)
 
 draft-arkko-eap-aka-pfs-01.txt
 Date: 05/03/2018
 Authors: Jari Arkko, Karl Norrman, Vesa Torvinen
 Working Group: Individual Submissions (none)
 Formats: txt
Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. This specification is an optional extension to the EAP-AKA' authentication method which was defined in RFC 5448. The extension provides Perfect Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from merely passively eavesdropping the EAP-AKA' exchanges and deriving associated session keys, forcing attackers to use active attacks instead.
    
draft-arkko-eap-rfc5448bis-01.txt
 Improved Extensible Authentication Protocol Method for 3rd Generation Authentication and Key Agreement (EAP-AKA')
 
 draft-arkko-eap-rfc5448bis-01.txt
 Date: 05/03/2018
 Authors: Jari Arkko, Vesa Lehtovirta, Vesa Torvinen, Pasi Eronen
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines a new EAP method, EAP-AKA', a small revision of the EAP-AKA method. The change is a new key derivation function that binds the keys derived within the method to the name of the access network. The new key derivation mechanism has been defined in the 3rd Generation Partnership Project (3GPP). This specification allows its use in EAP in an interoperable manner. In addition, EAP-AKA' employs SHA-256 instead of SHA-1. This specification also updates RFC 4187 EAP-AKA to prevent bidding down attacks from EAP-AKA'. This version of the EAP-AKA' specification updates a reference to constructing one field in the protocol, so that EAP-AKA' becomes compatible with 5G deployments as well.
    
draft-arnold-sipcore-push-notification-gateway-00.txt
 Using a Push Notification Gateway to improve session initiation with SIP user agents
 
 draft-arnold-sipcore-push-notification-gateway-00.txt
 Date: 16/11/2017
 Authors: Michael Arnold
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes how a Push Notification Gateway (PNG) network element can be used to allow SIP User Agents (UA) to run on devices where background processing and monitoring is limited. In these circumstances, it cannot be assumed that the SIP UA can regularly REGISTER with the network or be able to detect inbound messages. A PNG stores details provided to it by the UA during registration to prompt a Push Notification Service (PNS) to generate a real-time notification for the UA to REGISTER with the network and therefore be available for inbound SIP messages.
    
draft-asaeda-icnrg-ccninfo-00.txt
 CCNinfo: Discovering Content and Network Information in Content-Centric Networks
 
 draft-asaeda-icnrg-ccninfo-00.txt
 Date: 05/03/2018
 Authors: Hitoshi Asaeda, Xun Shao
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN routing path information per name prefix, device name, and function/ application, 2) the Round-Trip Time (RTT) between content forwarder and consumer, and 3) the states of in-network cache per name prefix. In addition, it discovers a gateway that supports different protocols such as CCN and Named-Data Networks (NDN).
    
draft-asaeda-icnrg-contrace-04.txt
 Contrace: Traceroute Facility for Content-Centric Network
 
 draft-asaeda-icnrg-contrace-04.txt
 Date: 28/10/2017
 Authors: Hitoshi Asaeda, Xun Shao, Thierry Turletti
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the traceroute facility for Content-Centric Network (CCN), named "Contrace". Contrace investigates: 1) the routing path information per name prefix, device name, and function/ application, 2) the Round-Trip Time (RTT) between content forwarder and consumer, and 3) the states of in-network cache per name prefix. In addition, it discovers a gateway that supports different protocols such as CCN and NDN.
    
draft-asciirfc-minimal-02.txt
 A Minimal Internet-Draft In AsciiRFC
 
 draft-asciirfc-minimal-02.txt
 Date: 12/04/2018
 Authors: Josiah Carberry, Truman Grayson
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the "asciidoctor-rfc" Ruby gem.
    
draft-asechoud-rtgwg-qos-model-05.txt
 YANG Model for QoS
 
 draft-asechoud-rtgwg-qos-model-05.txt
 Date: 18/03/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-00.txt
 YANG Model for QoS Operational Parameters
 
 draft-asechoud-rtgwg-qos-oper-model-00.txt
 Date: 30/10/2017
 Authors: Aseem Choudhary, I. Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a YANG model for Quality of Service (QoS) operational parameters.
    
draft-asveren-dispatch-http-overload-control-00.txt
 HTTP Overload Control Mechanism
 
 draft-asveren-dispatch-http-overload-control-00.txt
 Date: 14/04/2018
 Authors: Tolga Asveren
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a generic overload control mechanism for HTTP/HTTPS applications.
    
draft-atarius-dispatch-meid-urn-17.txt
 A Uniform Resource Name Namespace for the Device Identity and the Mobile Equipment Identity (MEID)
 
 draft-atarius-dispatch-meid-urn-17.txt
 Date: 12/04/2018
 Authors: Roozbeh Atarius
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
This document defines a Uniform Resource Name (URN) namespace for the Third Generation Partnership Project 2 (3GPP2) and a Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID). The structure of an MEID is 15 hexadecimal digits long and is defined in the Third Generation Partnership Project 2 (3GPP2) (see [S.R0048-A]) to uniquely identify each individual mobile equipment (e.g., a handset or mobile phone). The 3GPP2 has a requirement to be able to use an MEID as a URN. This document fulfills that requirement.
    
draft-atarius-dispatch-meid-urn-as-instanceid-07.txt
 Using the Mobile Equipment Identity (MEID) Uniform Resource Name (URN) as an Instance ID
 
 draft-atarius-dispatch-meid-urn-as-instanceid-07.txt
 Date: 13/01/2018
 Authors: Roozbeh Atarius
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
This specification specifies how the Uniform Resource Name (URN) namespace reserved for the Third Generation Partnership Project 2 (3GPP2) identities and its Namespace Specific String (NSS) for the Mobile Equipment Identity (MEID) can be used as an instance-id. Its purpose is to fulfill the requirements for defining how a specific URN needs to be constructed and used in the "+sip.instance" Contact header field parameter for outbound behavior.
    
draft-atlas-external-normref-00.txt
 Normative References in RFCs from Open Source
 
 draft-atlas-external-normref-00.txt
 Date: 29/10/2017
 Authors: Alia Atlas, Eliot Lear, Joel Halpern, Heather Flanagan, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: xml txt
IETF procedures generally require that a standards track RFC may not have a normative reference to a non standards track specification except those from other standards bodies. This document creates an External Specification registry, similar to the DownRef registry that has been created based on [RFC3967] and permits normative references to community accepted external specifications.
    
draft-atlas-geo-focused-activities-01.txt
 Geographically-Focused IETF Activities
 
 draft-atlas-geo-focused-activities-01.txt
 Date: 29/10/2017
 Authors: Alia Atlas, Christian O'Flaherty, harish@nixi.in, Scott Bradner
 Working Group: Individual Submissions (none)
 Formats: xml txt
The IETF has a variety of activities beyond those that are part of the standards process. IETF activities that aren't part of the standards process are still quite useful for the IETF mission. Some of these activities, such as IETF hackathons, tutorials, and mentoring, occur at in-person meetings. There has been and continues to be interest in having such activities located in different geographical areas. The document defines how the IETF organizes our Geographically- Focused Activities. It is intended for eventual publication as a BCP but this is currently an initial strawman proposal based upon the existing variety of experience with the experimental activities in this space over the past several years.
    
draft-avasarala-diameter-error-invalid-identity-00.txt
 Diameter Invalid Mobile Identity
 
 draft-avasarala-diameter-error-invalid-identity-00.txt
 Date: 27/10/2017
 Authors: Ranjit Avasarala, Vamsidhar Sivadi
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification documents an extension to the Diameter Base Protocol RFC6733. This extension adds a new Diameter Protocol Error code to the Result-Code AVP to the Diameter responses for indicating error in the mobile identity in the Diameter requests. This extension is mainly applicable to the credit control applications defined in RFC4006 and user authorization procedures defined in RFC4740.
    
draft-baba-iot-problems-04.txt
 Problems in and among industries for the prompt realization of IoT and safety considerations
 
 draft-baba-iot-problems-04.txt
 Date: 30/10/2017
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Koichi KUNITAKE, Kaoru Maeda
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document contains opinions gathered from enterprises engaging in the IoT business as stated in the preceding version hereof, and also examines the possibilities of new social problems in the IoT era. Recognition of the importance of information security has grown in step with the rising use of the Internet. Closer examination reveals that the IoT era may see a new direct physical threat to users. For instance, the situation at a smart house may lead it to judge that the owner has only temporarily stepped out, causing it to unlock the front door, which in turn makes it easier for thieves to enter. These kinds of scenarios may occur without identity fraud, hacking, and other means of compromising information security. Therefore, for the purpose of this document, this issue shall be referred to as "IoT Safety" to distinguish it from Information Security. We believe that it is necessary to deepen our understanding of these new IoT-related threats through discussion and ensure there are measures to address these threats in the future. At the same time, we must also coordinate these measures with the solutions to the problems described in the previous version of this document.
    
draft-baba-iot-webapi-02.txt
 Report on Problem Solving Experiment for Realization of Web-API-based IoT
 
 draft-baba-iot-webapi-02.txt
 Date: 30/10/2017
 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-backman-secevent-token-03.txt
 Security Event Token (SET)
 
 draft-backman-secevent-token-03.txt
 Date: 30/11/2017
 Authors: Annabelle Backman, William Denniss, Morteza Ansari, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines the Security Event Token, which may be distributed via a protocol such as HTTP. The Security Event Token (SET) specification profiles the JSON Web Token (JWT), which can be optionally signed and/or encrypted. A SET describes a statement of fact from the perspective of an issuer that it intends to share with one or more receivers.
    
draft-balarajah-bmwg-ngfw-performance-03.txt
 Benchmarking Methodology for Network Security Device Performance
 
 draft-balarajah-bmwg-ngfw-performance-03.txt
 Date: 23/03/2018
 Authors: Balamuhunthan Balarajah, Carsten Rossenhoevel
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides benchmarking terminology and methodology for next-generation network security devices including next-generation firewalls (NGFW), intrusion detection and prevention solutions (IDS/ IPS) and unified threat management (UTM) implementations. The document aims to strongly improve the applicability, reproducibility and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 application use cases. The main areas covered in this document are test terminology, traffic profiles and benchmarking methodology for NGFWs to start with.
    
draft-banghart-mile-rolie-discovery-00.txt
 ROLIE Discovery Mechanism
 
 draft-banghart-mile-rolie-discovery-00.txt
 Date: 05/03/2018
 Authors: Stephen Banghart, David Waltermire
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a mechanism that allows consistent discovery of ROLIE repositories. This discovery is extremely important for automated tools that cannot use out-of-band Service Document discovery. Any human operators are also able to use this mechanism to avoid relying on inconsistent human to human communication. This document updates the ROLIE core specification.
    
draft-baraq-roll-drizzle-00.txt
 Drizzle Algorithm
 
 draft-baraq-roll-drizzle-00.txt
 Date: 23/03/2018
 Authors: Baraq Ghaleb, Ahmed Al-Dubai, Imed Romdhani, Mamoun Qasem
 Working Group: Individual Submissions (none)
 Formats: txt
Trickle algorithm used in RPL routing protocol suffers from some issues related to power, network convergence time and overhead and load-distribution. To optimize this algorithm for Low-power and Lossy Networks (LLNs), a new algorithm called Drizzle is introduced. Drizzle uses an adaptive suppression mechanism that permits the nodes to have different transmission probabilities, which are consistent with their transmission history. Compared to Trickle, Drizzle removes the listen-only period from Drizzle's intervals, thus, leading to faster convergence time. Furthermore, a new policy for setting the redundancy coefficient has been used to mitigate the negative effect of the short-listen problem presented when removing the listen-only period and to further boost the fairness in the network.
    
draft-barkai-lisp-nfv-11.txt
 LISP Based FlowMapping for Scaling NFV
 
 draft-barkai-lisp-nfv-11.txt
 Date: 18/12/2017
 Authors: Sharon Barkai, Dino Farinacci, David Meyer, Fabio Maino, Vina Ermagan, Alberto Rodriguez-Natal, Albert Cabellos-Aparicio
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes an RFC 6830 Locator ID Separation Protocol (LISP) based distributed flow-mapping-fabric for dynamic scaling of virtualized network functions (NFV). Network functions such as subscriber-management, content-optimization, security and quality of service, are typically delivered using proprietary hardware appliances embedded into the network as turn-key service-nodes or service-blades within routers. Next generation network functions are being implemented as pure software instances running on standard servers - unbundled virtualized components of capacity and functionality. LISP-SDN based flow-mapping, dynamically assembles these components to whole solutions by steering the right traffic in the right sequence to the right virtual function instance.
    
draft-barnes-acme-service-provider-code-00.txt
 ACME Identifiers and Challenges for VoIP Service Providers
 
 draft-barnes-acme-service-provider-code-00.txt
 Date: 30/10/2017
 Authors: Mary Barnes, Chris Wendt
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the use of the Entity Code Identifier and token challenge type to enable the Automated Certificate Management Environment (ACME) to issue certificates for VoIP service providers to support Secure Telephony Identity (STI).
    
draft-barnes-acme-token-challenge-02.txt
 ACME Token Identifier and Challenges
 
 draft-barnes-acme-token-challenge-02.txt
 Date: 05/03/2018
 Authors: Mary Barnes
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an identifier and challenge type required to enable the Automated Certificate Management Environment (ACME) to issue certificates using a token for the challenge response. This token is issued by a administrative authority with whom the Certification Authority (CA) has a trust relationship. The entity requesting a certificate also has a relationship with the administrative authority, such that the administrative authority assigns a unique code to the entity. This entity code is included as part of the token that the administrative authority issues.
    
draft-barnes-mls-protocol-00.txt
 The Messaging Layer Security (MLS) Protocol
 
 draft-barnes-mls-protocol-00.txt
 Date: 02/02/2018
 Authors: Richard Barnes, Jon Millican, Emad Omara, Katriel Cohn-Gordon, Raphael Robert
 Working Group: Individual Submissions (none)
 Formats: xml txt
Messaging applications are increasingly making use of end-to-end security mechanisms to ensure that messages are only accessible to the communicating endpoints, and not to any servers involved in delivering messages. Establishing keys to provide such protections is challenging for group chat settings, in which more than two participants need to agree on a key but may not be online at the same time. In this document, we specify a key establishment protocol that provides efficient asynchronous group key establishment with forward secrecy and post-compromise security for groups in size ranging from two to thousands.
    
draft-barnes-tls-pake-01.txt
 Usage of SPAKE with TLS 1.3
 
 draft-barnes-tls-pake-01.txt
 Date: 13/04/2018
 Authors: Richard Barnes, Owen Friel
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 how the SPAKE password-authenticated key exchange can be used with TLS 1.3.
    
draft-barre-mptcp-tfo-02.txt,.ps
 TFO support for Multipath TCP
 
 draft-barre-mptcp-tfo-02.txt,.ps
 Date: 27/11/2017
 Authors: Sebastien Barre, Gregory Detal, Olivier Bonaventure, Christoph Paasch
 Working Group: Individual Submissions (none)
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-association-bidir-04.txt
 PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs)
 
 draft-barth-pce-association-bidir-04.txt
 Date: 27/03/2018
 Authors: Colby Barth, Rakesh Gandhi, Bin Wen
 Working Group: Individual Submissions (none)
 Formats: txt
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The Stateful PCE extensions allow stateful control of Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. This document defines PCEP extensions for grouping two reverse unidirectional MPLS TE LSPs into an Associated Bidirectional LSP when using a Stateful PCE for both PCE-Initiated and PCC-Initiated LSPs as well as when using a Stateless PCE.
    
draft-barthel-icmpv6-schc-00.txt
 LPWAN Static Context Header Compression (SCHC) for ICMPv6
 
 draft-barthel-icmpv6-schc-00.txt
 Date: 28/10/2017
 Authors: Dominique Barthel, Laurent Toutain, Arunprabhu Kandasamy
 Working Group: Individual Submissions (none)
 Formats: txt
ICMPv6 is a companion protocol to IPv6. It defines messages that inform the source of IPv6 packets of errors during packet delivery. It also defines the Echo Request/Reply messages that are used for basic network troubleshooting (ping command). ICMPv6 messages are transported on IPv6. This document describes how to adapt ICMPv6 to Low Power Wide Area Networks (LPWANs) by compressing ICMPv6/IPv6 headers and by protecting the LPWAN network and the Device from undesirable ICMPv6 traffic.
    
draft-basavaraj-ospf-graceful-restart-enhancements-00.txt
 OSPF Graceful Restart Enhancements
 
 draft-basavaraj-ospf-graceful-restart-enhancements-00.txt
 Date: 25/10/2017
 Authors: Vijayalaxmi Basavaraj, Ankur Dubey, Sami Boutros, Acee Lindem
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes enhancements to the OSPF graceful restart procedures to improve routing convergence in some OSPF network deployments. This document updates RFC 3623 and RFC 5187.
    
draft-bashandy-isis-srv6-extensions-02.txt
 IS-IS Extensions to Support Routing over IPv6 Dataplane
 
 draft-bashandy-isis-srv6-extensions-02.txt
 Date: 19/03/2018
 Authors: Les Ginsberg, Ahmed Bashandy, Clarence Filsfils, Bruno Decraene, Zhibo Hu
 Working Group: Individual Submissions (none)
 Formats: txt xml
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane.
    
draft-bashandy-rtgwg-segment-routing-ti-lfa-04.txt
 Topology Independent Fast Reroute using Segment Routing
 
 draft-bashandy-rtgwg-segment-routing-ti-lfa-04.txt
 Date: 02/04/2018
 Authors: Ahmed Bashandy, Clarence Filsfils, Bruno Decraene, Stephane Litkowski, Pierre Francois, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any IGP network. A key aspect of TI-LFA is the FRR path selection approach establishing protection over post-convergence paths from the point of local repair, dramatically reducing the operational need to control the tie-breaks among various FRR options.
    
draft-bashandy-rtgwg-segment-routing-uloop-03.txt
 Loop avoidance using Segment Routing
 
 draft-bashandy-rtgwg-segment-routing-uloop-03.txt
 Date: 02/04/2018
 Authors: Ahmed Bashandy, Clarence Filsfils, Stephane Litkowski, Pierre Francois
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination.
    
draft-bellis-dnsext-multi-qtypes-05.txt
 DNS Multiple QTYPEs
 
 draft-bellis-dnsext-multi-qtypes-05.txt
 Date: 02/01/2018
 Authors: Ray Bellis
 Working Group: Domain Name System Operations (dnsop)
 Formats: txt xml
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query.
    
draft-bellis-dnsop-xpf-04.txt
 DNS X-Proxied-For
 
 draft-bellis-dnsop-xpf-04.txt
 Date: 05/03/2018
 Authors: Ray Bellis, Peter van Dijk, Remi Gacogne
 Working Group: Individual Submissions (none)
 Formats: txt xml
It is becoming more commonplace to install front end proxy devices in front of DNS servers to provide (for example) load balancing or to perform transport layer conversions. This document defines a meta resource record that allows a DNS server to receive information about the client's original transport protocol parameters when supplied by trusted proxies.
    
draft-belyavskiy-certificate-limitation-policy-05.txt
 Certificate Limitation Policy
 
 draft-belyavskiy-certificate-limitation-policy-05.txt
 Date: 26/11/2017
 Authors: Dmitry Belyavsky
 Working Group: Individual Submissions (none)
 Formats: txt xml
The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself.
    
draft-benhadjsaid-detnet-gptp-yang-00.txt
 YANG Model of IEEE 802.1AS
 
 draft-benhadjsaid-detnet-gptp-yang-00.txt
 Date: 29/03/2018
 Authors: Siwar Sad, Michael Boc
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a YANG data model for the management of IEEE 802.1AS module in network devices. This data model includes configuration data and state data (status information and counters for the collection of statistics).
    
draft-bernardos-nfvrg-multidomain-04.txt
 Multi-domain Network Virtualization
 
 draft-bernardos-nfvrg-multidomain-04.txt
 Date: 05/03/2018
 Authors: Carlos Bernardos, Luis Contreras, Ishan Vaishnavi, Robert Szabo, Xi Li, Francesco Paolucci, Andrea Sgambelluri, Barbara Martini, Luca Valcarenghi, Giada Landi, Dmitriy Andrushko, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the problem of multi-provider multi-domain orchestration, by first scoping the problem, then looking into potential architectural approaches, and finally describing the solutions being developed by the European 5GEx and 5G-TRANSFORMER projects.
    
draft-bernardos-nfvrg-vim-discovery-00.txt
 IPv6-based discovery and association of Virtualization Infrastructure Manager (VIM) and Network Function Virtualization Orchestrator (NFVO)
 
 draft-bernardos-nfvrg-vim-discovery-00.txt
 Date: 05/03/2018
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Virtualized resources do not need to be limited to those available in traditional data centers, where the infrastructure is stable, static, typically homogeneous and managed by a single admin entity. Computational capabilities are becoming more and more ubiquitous, with terminal devices getting extremely powerful, as well as other types of devices that are close to the end users at the edge (e.g., vehicular onboard devices for infotainment, micro data centers deployed at the edge, etc.). It is envisioned that these devices would be able to offer storage, computing and networking resources to nearby network infrastructure, devices and things (the fog paradigm). These resources can be used to host functions, for example to offload/complement other resources available at traditional data centers, but also to reduce the end-to-end latency or to provide access to specialized information (e.g., context available at the edge) or hardware. This document describes mechanisms allowing dynamic discovery of virtualization resources and orchestrators in IPv6-based networks. New IPv6 neighbor discovery options are defined.
    
draft-bernardos-sfc-discovery-00.txt
 Service Function discovery in fog environments
 
 draft-bernardos-sfc-discovery-00.txt
 Date: 05/03/2018
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. Service functions provide an specific treatment of received packets, therefore they need to be known so they can be used in a given service composition via SFC. This document discusses the need for service function discovery mechanisms and propose some solutions for sfc-aware nodes to discover available service functions in fog environments.
    
draft-bernardos-sfc-fog-ran-03.txt
 Service Function Chaining Use Cases in Fog RAN
 
 draft-bernardos-sfc-fog-ran-03.txt
 Date: 05/03/2018
 Authors: Carlos Bernardos, Akbar Rahman, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Fog Radio Access Networks (RAN) refers to the part of the RAN that is virtualized at the very edge of the network, even at the end-user device. Fog RAN support is considered critical for the 5G mobile network architectures currently being developed in various research, standardization and industry forums. Since fog RAN builds on top of virtualization and can involve several virtual functions running on different virtualized resources, Service function chaining (SFC) support for the fog RAN will be critical. This document describes the overall fog RAN approach and also gives some use cases. Finally it proposes some requirements to be considered in the development of the SFC architecture and related protocols.
    
draft-bertola-dns-openid-pidi-architecture-01.txt
 An Architecture for a Public Identity Infrastructure Based on DNS and OpenID Connect
 
 draft-bertola-dns-openid-pidi-architecture-01.txt
 Date: 14/03/2018
 Authors: Vittorio Bertola, Marcos Sanz
 Working Group: Individual Submissions (none)
 Formats: txt xml
The following document describes an architecture for an open, global, federated Public Identity Infrastructure (PIDI), based on the Domain Name System (DNS) and on the OpenID Connect framework built over the OAuth protocol.
    
draft-bertz-dime-diamimpr-01.txt
 Diameter Specification Recommendations
 
 draft-bertz-dime-diamimpr-01.txt
 Date: 30/12/2017
 Authors: Lyle Bertz
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document reports on formatting errors, uses cases, and inconsistencies found in various standards specifications related to the Diameter interface requirements. Recommendations are made to reduce errors, support common use cases and build specifications in such a way that programmatic verification of Diameter specifications can be done with minimal to no errors.
    
draft-bertz-dime-policygroups-05.txt
 Diameter Policy Groups and Sets
 
 draft-bertz-dime-policygroups-05.txt
 Date: 30/12/2017
 Authors: Lyle Bertz, Mark Bales
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines optional Diameter attributes for efficient policy provisioning.
    
draft-bertz-dime-predictunits-03.txt
 Diameter Predicted Units
 
 draft-bertz-dime-predictunits-03.txt
 Date: 30/12/2017
 Authors: Lyle Bertz
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the conveyance of predicted usage information for proper dimensioning of network services that use Diameter based authorization.
    
draft-bhattacharyya-dice-less-on-coap-01.txt
 Lightweight Establishment of Secure Session (LESS) on CoAP
 
 draft-bhattacharyya-dice-less-on-coap-01.txt
 Date: 04/03/2018
 Authors: Abhijan Bhattacharyya, Tulika Bose, Arijit Ukil, Soma Bandyopadhyay, Arpan Pal
 Working Group: Individual Submissions (none)
 Formats: txt
Secure yet lightweight protocol for communication over the Internet for constrained node networks (CNN) is a pertinent problem. Constrained Application Layer Protocol (CoAP) mandates the use of Datagram Transport Layer Security (DTLS) for a secure transaction over CoAP. But DTLS is not a candidate technology for CNNs by design. The DTLS handshake overhead to establish the credentials for a session between two end-points in a CNN may not be resource efficient. There are ongoing efforts to secure one-time exchanges by ensuring object security at the application layer. But a composite standardized mechanism for resource-efficient end-to-end security credential establishment is much needed to cater both one-time exchanges as well as exchanges over a session. DTLS is essentially a combination of two operations: (1) the session protocol to establish the credentials (and this is the resource heavy part), (2) the record protocol to protect the information (this is the cryptographic part). This draft proposes to distribute the security responsibilities such that the session establishment happens in the application layer, leveraging the lightweight semantics of CoAP, and the record layer encryption happens by reusing the existing DTLS record-layer protocol. This way the proposed mechanism enables a resource-efficient session establishment mechanism besides reusing the existing DTLS encryption. Assuming a Pre-Shared Key (PSK) environment, this draft proposes an embedding of handshake for resource efficient end-to-end session establishment into CoAP. The session establishment procedure produces the necessary and sufficient inputs for seamless operation of the DTLS record-layer to secure the channel. Also, this mechanism ensures a direct security association between the end-applications for systems using middleboxes like proxies and/or gateways which may not be always trusted. The proposed approach provides a mechanism to securely traverse through such middleboxes through an end-to-end trusted channel.
    
draft-bi-savi-wlan-14.txt
 A SAVI Solution for WLAN
 
 draft-bi-savi-wlan-14.txt
 Date: 26/03/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-01.txt
 pretty Easy privacy (pEp): Privacy by Default
 
 draft-birk-pep-01.txt
 Date: 09/01/2018
 Authors: Volker Birk, Hernani Marques, Shelburn, Sandro Koechli
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 introduces "Trustwords" (instead 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-00.txt
 pretty Easy privacy (pEp): Trustwords concept
 
 draft-birk-pep-trustwords-00.txt
 Date: 22/02/2018
 Authors: Volker Birk, Hernani Marques, Bernie Hoeneisen
 Working Group: Individual Submissions (none)
 Formats: txt xml
In public-key cryptography comparing the public keys' fingerprints of the communication partners involved is vital to ensure that there is no man-in-the-middle (MITM) attack on the communication channel. Fingerprints normally consist of a chain of hexadecimal chars. However, comparing hexadecimal strings is often impractical for regular users and prone to misunderstandings. To mitigate these challenges, this memo proposes the comparision of trustwords as opposed to hexadecimal strings. Trustwords are common words in a natural language (e.g., English) to which the hexidecimal strings are mapped to. This makes the verification process more natural.
    
draft-birkholz-attestation-terminology-01.txt
 Reference Terminology for Remote Attestation Procedures
 
 draft-birkholz-attestation-terminology-01.txt
 Date: 03/01/2018
 Authors: Henk Birkholz, Monty Wiseman, Hannes Tschofenig
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document is intended to illustrate and remediate the impedance mismatch of terms related to remote attestation procedures used in different domains today. New terms defined by this document provide a consolidated basis to support future work on attestation procedures in the IETF and beyond.
    
draft-birkholz-i2nsf-tuda-01.txt
 Time-Based Uni-Directional Attestation
 
 draft-birkholz-i2nsf-tuda-01.txt
 Date: 30/10/2017
 Authors: Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This memo documents the method and bindings used to conduct time- based uni-directional attestation between distinguishable endpoints over the network.
    
draft-birkholz-sacm-yang-content-01.txt
 YANG subscribed notifications via SACM Statements
 
 draft-birkholz-sacm-yang-content-01.txt
 Date: 18/01/2018
 Authors: Henk Birkholz, Nancy Cam-Winget
 Working Group: Individual Submissions (none)
 Formats: txt
This document summarizes a subset of the emerging generic SACM Data Model for inter-component distribution of SACM Content in and between SACM Domains. The subset defined in this document is covering every information element that can be acquired using YANG based protocols, i.e. NETCONF, RESTCONF, COMI or derived mechanisms that transfer YANG modeled data, such as MUD. As subscriptions to data origins in a SACM domain are one of the architectural corner-stones of the SACM architecture, this document recommends the use of YANG Push, YANG subscribed Notifications and corresponding Notification Headers and Bundles. Analogously, a mapping of Notification Header content to SACM Metadata is provided in this document.
    
draft-birkholz-yang-swid-00.txt
 YANG module for Software Identifiers
 
 draft-birkholz-yang-swid-00.txt
 Date: 30/10/2017
 Authors: Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides a YANG module definition that enables a system entity 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-01.txt
 AMA Application Data Model
 
 draft-birrane-dtn-adm-01.txt
 Date: 04/03/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a data model that captures the information necessary to manage applications in asynchronously managed networks. This model includes a set of common type definitions, data structures, and a template for publishing standardized representations of elements of the model.
    
draft-birrane-dtn-ama-06.txt
 Asynchronous Management Architecture
 
 draft-birrane-dtn-ama-06.txt
 Date: 30/10/2017
 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-bpsec-interop-cs-01.txt
 BPSec Interoperability Cipher Suites
 
 draft-birrane-dtn-bpsec-interop-cs-01.txt
 Date: 05/03/2018
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-priority-placeholder-01.txt
 Priority Placeholders in HTTP/2
 
 draft-bishop-httpbis-priority-placeholder-01.txt
 Date: 07/02/2018
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: txt xml
RFC7540 defines HTTP/2, including a method for communicating priorities. Some implementations have begun using closed streams as placeholders when constructing their priority tree, but this has unbounded state commitments and interacts poorly with HTTP/QUIC. This document proposes an extension to the HTTP/2 priority scheme for both protocols.
    
draft-bishop-httpbis-sni-altsvc-01.txt
 The "SNI" Alt-Svc Parameter
 
 draft-bishop-httpbis-sni-altsvc-01.txt
 Date: 09/01/2018
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: xml txt
HTTP Alternative Services provides a mechanism for an origin to declare that its content is accessible via some other combination of host, port, and protocol. In the process of using such an alternative, an observer can identify that the client is requesting resources from a particular hostname. This document extends HTTP Alternative Services, in combination with Secondary Certificate Authentication, to enable clients not to disclose the origin to which they intend to connect.
    
draft-bishop-quic-http-and-qpack-07.txt
 Header Compression for HTTP/QUIC
 
 draft-bishop-quic-http-and-qpack-07.txt
 Date: 15/12/2017
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: xml txt
HTTP/2 [RFC7540] uses HPACK [RFC7541] for header compression. However, HPACK relies on the in-order message-based semantics of the HTTP/2 framing layer in order to function. Messages can only be successfully decoded if processed by the decoder in the same order as generated by the encoder. This draft refines HPACK to loosen the ordering requirements for use over QUIC [I-D.ietf-quic-transport].
    
draft-bng-radext-virtual-nas-for-dnas-01.txt
 Virtual NAS (vNAS) Support for DNAS
 
 draft-bng-radext-virtual-nas-for-dnas-01.txt
 Date: 06/12/2017
 Authors: Raghunadha Pocha, Chandrashekhar Jamadarkhani, Satyanarayana Danda, Nishad M, Nagappa Chinnannavar
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This specification defines a framework for interacting North bound (AAA/Policy) servers of the Client resides in Cloud and/or Distributed Network environment with High-Availability to achieve fewer use-cases. First, NAS Client resides in Cloud or Virtualized or Distributed Network Access System to perform Authorization, Authentication and Accounting procedures with AAA Servers. Second, AAAA/Policy Servers provide dynamic policy information for subscribers of supporting in NAS Clients resides in Cloud or Virtualized or Distributed Network environment. Finally, Handling of Accounting related issues in better way for subscribers supported in Cloud or Virtualized or Distributed Network environment under High- Available conditions.
    
draft-bogineni-dmm-optimized-mobile-user-plane-00.txt
 Optimized Mobile User Plane Solutions for 5G
 
 draft-bogineni-dmm-optimized-mobile-user-plane-00.txt
 Date: 05/03/2018
 Authors: Kalyani Bogineni, A. Rodriguez-Natal
 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 [23501, 23502, 23503, 23203, 29244, 29281, 38300, 38401]. The requirements for the network functions and the relevant interfaces are provided. Reference scenarios and criteria for evaluation of various IETF protocols are provided. Several IETF protocols are considered for comparison: SRv6, LISP, ILA and several combinations of control plane and user plane protocols.
    
draft-bonica-intarea-frag-fragile-01.txt
 IP Fragmentation Considered Fragile
 
 draft-bonica-intarea-frag-fragile-01.txt
 Date: 04/03/2018
 Authors: Ron Bonica, Fred Baker, Geoff Huston, Robert Hinden, Ole Troan, Fernando Gont
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides an overview of IP fragmentation. It explains how IP fragmentation works and why it is required. As part of that explanation, this document also explains how IP fragmentation reduces the reliability of Internet communication. This document also proposes alternatives to IP fragmentation. Finally, it provides recommendations for application developers and network operators.
    
draft-bormann-cbor-cddl-freezer-00.txt
 A feature freezer for the Concise Data Definition Language (CDDL)
 
 draft-bormann-cbor-cddl-freezer-00.txt
 Date: 27/01/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document collects nice-to-have features that did not make it into the first RFC for CDDL.
    
draft-bormann-core-ace-aif-05.txt
 An Authorization Information Format (AIF) for ACE
 
 draft-bormann-core-ace-aif-05.txt
 Date: 18/01/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
Constrained Devices as they are used in the "Internet of Things" need security. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, need to ascertain that the authorization to request the operation does apply to the actual requester, and need to ascertain that other devices they place requests on are the ones they intended. On the ACE mailing list, an activity to create specifications for such authenticated authorization for constrained devices is contemplated, leading to protocol proposals such as [I-D.ietf-ace-dtls-authorize] or [I-D.seitz-ace-oscoap-profile]. One potential work item complementing this protocol work is an Authorization Information Format (AIF). This document provides a strawman for such a format that should enable further discussion of the objectives for its development.
    
draft-bormann-core-maybe-00.txt
 The application/maybe media type
 
 draft-bormann-core-maybe-00.txt
 Date: 18/03/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt xml
Many media types may be used in situations where it may beneficial to indicate that the object represented in this media type is not yet (or no longer) present. The Observe option introduced in Observing Resources in the Constrained Application Protocol (CoAP) (RFC7641) requires sequences of responses (notifications) to carry the same Content-Format. The application/maybe media type provides a way to use a single media type (and thus Content-Format) to express presence or absence of information in a specific media type.
    
draft-bormann-core-responses-00.txt
 CoAP: Non-traditional response forms
 
 draft-bormann-core-responses-00.txt
 Date: 12/11/2017
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
In CoAP as defined by RFC 7252, responses are always unicast back to a client that posed a request. The present memo describes two forms of responses that go beyond that model. These descriptions are not intended as advocacy for adopting these approaches immediately, they are provided to point out potential avenues for development that would have to be carefully evaluated.
    
draft-bormann-lpwan-cbor-template-02.txt
 Concise Binary Object Representation (CBOR) Tag for CBOR Templates
 
 draft-bormann-lpwan-cbor-template-02.txt
 Date: 16/01/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document makes use of this extensibility to define a CBOR tag for a variable within a CBOR data item, which then could be filled in by a separate process (e.g., from another CBOR data item).
    
draft-bormann-lwig-6lowpan-virtual-reassembly-00.txt
 Virtual reassembly buffers in 6LoWPAN
 
 draft-bormann-lwig-6lowpan-virtual-reassembly-00.txt
 Date: 25/01/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
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 RFC 4944. Apart from a brief mention of the way to do this in Section 2.5.2 of the 6LoWPAN book, this has not been extensively described in the literature. The present document attempts to fill that gap.
    
draft-bormann-lwig-7228bis-02.txt
 Terminology for Constrained-Node Networks
 
 draft-bormann-lwig-7228bis-02.txt
 Date: 30/10/2017
 Authors: Carsten Bormann, Mehmet Ersue, Ari Keranen, Carles Gomez
 Working Group: Individual Submissions (none)
 Formats: txt
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.
    
draft-bormann-t2trg-rel-impl-00.txt
 impl-info: A link relation type for disclosing implementation information
 
 draft-bormann-t2trg-rel-impl-00.txt
 Date: 28/01/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
When debugging an interoperability problem, it is often helpful to have information about the implementation version of a peer. To enable the disclosure of such information, HTTP defines header fields such as Server and User-Agent. In CoAP, it is rarely appropriate to send information of this kind in every request or response. Instead, the present specification defines a link relation type, impl-info, that can be used to convey this information via the self-description capabilities of the /.well- known/core resource and the CoRE resource directory.
    
draft-bormann-t2trg-slipmux-02.txt
 Slipmux: Using an UART interface for diagnostics,configuration,and packet transfer
 
 draft-bormann-t2trg-slipmux-02.txt
 Date: 17/01/2018
 Authors: Carsten Bormann, Tobias Kaupat
 Working Group: Individual Submissions (none)
 Formats: txt
Many research and maker platforms for Internet of Things experimentation offer a serial interface. This is often used for programming, diagnostic output, as well as a crude command interface ("AT interface"). Alternatively, it is often used with SLIP (RFC1055) to transfer IP packets only. The present report describes how to use a single serial interface for diagnostics, configuration commands and state readback, as well as packet transfer.
    
draft-bormann-t2trg-stp-00.txt
 The Series Transfer Pattern (STP)
 
 draft-bormann-t2trg-stp-00.txt
 Date: 18/03/2018
 Authors: Carsten Bormann
 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-01.txt
 SWORN: Secure Wake on Radio Nudging
 
 draft-bormann-t2trg-sworn-01.txt
 Date: 30/10/2017
 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-dname-root-05.txt
 Using DNAME in the DNS root zone for sinking of special-use TLDs
 
 draft-bortzmeyer-dname-root-05.txt
 Date: 17/01/2018
 Authors: Stephane Bortzmeyer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This documents asks IANA to add DNAME records in the DNS root zone for TLDs which are in the Special-Use Domain Names registry, in order to ensure they receive an appropriate reply (NXDOMAIN) and that the root nameservers are not too bothered by them. REMOVE BEFORE PUBLICATION: there is no obvious place to discuss this document. May be the IETF DNSOP (DNS Operations) group, through its mailing list (the author reads it). Or may AS112 operators mailing lists? The source of the document, as well as a list of open issues, is currently kept at Github [1].
    
draft-bortzmeyer-dprive-resolver-to-auth-01.txt
 Encryption and authentication of the DNS resolver-to-authoritative communication
 
 draft-bortzmeyer-dprive-resolver-to-auth-01.txt
 Date: 20/03/2018
 Authors: Stephane Bortzmeyer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a mechanism for securing (privacy-wise) the communication between the DNS resolver and the authoritative name server. REMOVE BEFORE PUBLICATION: this document should be discussed in the IETF DPRIVE group, through its mailing list. The source of the document, as well as a list of open issues, is currently kept at Github [1].
    
draft-bortzmeyer-regext-epp-dname-02.txt
 EPP Mapping for DNAME delegation of domain names
 
 draft-bortzmeyer-regext-epp-dname-02.txt
 Date: 19/03/2018
 Authors: Stephane Bortzmeyer
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an Extensible Provisioning Protocol (EPP) extension mapping for the provisioning and management of Domain Name System for domain names stored in a shared central repository. Specified in XML, this mapping extends the EPP domain name mapping to provide the ability to delegate a domain names through DNAME resource records, thus making the new domain an alias of a previous domain. REMOVE BEFORE PUBLICATION This document should be discussed on the Registration Protocols Extensions (regext) mailing list. The source of this document is kept on a Gitlab at Framagit [1]. A list of open issues is there as well [2].
    
draft-boucadair-connectivity-provisioning-protocol-15.txt
 Connectivity Provisioning Negotiation Protocol (CPNP)
 
 draft-boucadair-connectivity-provisioning-protocol-15.txt
 Date: 15/12/2017
 Authors: Mohamed Boucadair, Christian Jacquenet, Dacheng Zhang, Panos Georgatsos
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the Connectivity Provisioning Negotiation Protocol (CPNP) which is used for dynamic negotiation of service parameters. CPNP is a generic protocol that can be used for various negotiation purposes that include (but are not necessarily limited to) connectivity provisioning services, storage facilities, Content Delivery Networks footprint, etc. The protocol can be extended with new Information Elements.
    
draft-boucadair-dots-multihoming-03.txt
 Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)
 
 draft-boucadair-dots-multihoming-03.txt
 Date: 09/04/2018
 Authors: Mohamed Boucadair, Tirumaleswar Reddy
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses multi-homing considerations for Distributed- Denial-of-Service Open Threat Signaling (DOTS). The goal is to provide a set of guidance for DOTS clients/gateways when multihomed.
    
draft-boucadair-dots-server-discovery-04.txt
 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server Discovery
 
 draft-boucadair-dots-server-discovery-04.txt
 Date: 09/04/2018
 Authors: Mohamed Boucadair, Tirumaleswar Reddy, Prashanth Patil
 Working Group: Individual Submissions (none)
 Formats: txt xml
It may not be possible for a network to determine the cause for an attack, but instead just realize that some resources seem to be under attack. To fill that gap, Distributed-Denial-of-Service Open Threat Signaling (DOTS) allows a network to inform a DOTS server that it is under a potential attack so that appropriate mitigation actions are undertaken. This document specifies mechanisms to configure nodes with DOTS servers.
    
draft-boucadair-ipsecme-ipv6-ipv4-codes-01.txt
 IKEv2 Notification Codes for IPv4/IPv6 Coexistence
 
 draft-boucadair-ipsecme-ipv6-ipv4-codes-01.txt
 Date: 13/11/2017
 Authors: Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies new IKEv2 notification codes to better manage IPv4 and IPv6 co-existence.
    
draft-boucadair-lisp-bulk-07.txt
 LISP Mapping Bulk Retrieval
 
 draft-boucadair-lisp-bulk-07.txt
 Date: 03/04/2018
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document extends Locator/ID Separation Protocol (LISP) with a capability for bulk mapping retrieval. It does so by defining new LISP messages that are meant to facilitate state recovery of mapping tables and improve Ingress Tunnel Routers (ITR) recovery times, in particular. Unlike base LISP, these new messages are transported over TCP. In addition, this document allows to request mappings that match destination IP prefixes, names, or AS numbers.
    
draft-boucadair-radext-tcpm-converter-00.txt
 RADIUS Extensions for 0-RTT TCP Converters
 
 draft-boucadair-radext-tcpm-converter-00.txt
 Date: 03/04/2018
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: xml txt
Because of the lack of Multipath TCP (MPTCP) support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called Converters. Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attributes that carry the IP addresses that will be returned to authorized users to reach one or multiple Converters.
    
draft-boucadair-tcpm-dhc-converter-00.txt
 DHCP Options for 0-RTT TCP Converters
 
 draft-boucadair-tcpm-dhc-converter-00.txt
 Date: 03/04/2018
 Authors: Mohamed Boucadair, Christian Jacquenet, Tirumaleswar Reddy
 Working Group: Individual Submissions (none)
 Formats: txt xml
Because of the lack of Multipath TCP (MPTCP) support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called Converters. Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document focuses on the explicit deployment scheme where the identity of the Converters is explicitly configured on connected hosts. This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Converters parameters.
    
draft-bourbaki-6man-classless-ipv6-03.txt
 IPv6 is Classless
 
 draft-bourbaki-6man-classless-ipv6-03.txt
 Date: 17/03/2018
 Authors: Nicolas Bourbaki
 Working Group: Individual Submissions (none)
 Formats: txt
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing.
    
draft-boutros-bess-evpn-geneve-02.txt
 EVPN control plane for Geneve
 
 draft-boutros-bess-evpn-geneve-02.txt
 Date: 01/03/2018
 Authors: Sami Boutros, Ali Sajassi, John Drake, Jorge Rabadan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how Ethernet VPN (EVPN) control plane can be used with Network Virtualization Overlay over Layer 3 (NVO3) Generic Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 solutions. EVPN control plane can also be used by a Network Virtualization Endpoints (NVEs) to express Geneve tunnel option TLV(s)supported in transmission and/or reception of Geneve encapsulated data packets.
    
draft-boutros-nvo3-geneve-applicability-for-sfc-01.txt
 Geneve applicability for service function chaining
 
 draft-boutros-nvo3-geneve-applicability-for-sfc-01.txt
 Date: 01/03/2018
 Authors: Sami Boutros, Dharma Rajan, Philip Kippen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of using Generic Network Virtualization Encapsulation (Geneve), to carry the service function path (SFP) information, and the network service header (NSH) encapsulation. The SFP information will be carried in Geneve option TLV(s).
    
draft-boutros-nvo3-ipsec-over-geneve-01.txt
 IPsec over Geneve Encapsulation
 
 draft-boutros-nvo3-ipsec-over-geneve-01.txt
 Date: 10/01/2018
 Authors: Sami Boutros, Calvin Qian, Dan Wing
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies how Generic Network Virtualization Encapsulation (Geneve) can be used to carry IP Encapsulating Security Payload (ESP) and IP Authentication Header (AH) to provide secure transport over IP networks. Using IPSec ESP the Geneve payload is encrypted and integrity protected, and using IPSec AH the Geneve headers and payload are integrity protected.
    
draft-boutros-nvo3-mac-move-over-geneve-00.txt
 MAC move/flush over Geneve encapsulation
 
 draft-boutros-nvo3-mac-move-over-geneve-00.txt
 Date: 27/10/2017
 Authors: Sami Boutros, Jerome Catrouillet, Ankur Sharma
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a mechanism to signal Media Access Control (MAC) addresses move or flush over a Network Virtualization Overlays over Layer 3 (NVO3) virtual tunnel. Such notification is useful in redundancy scenarios when a Layer 2 service that was active on a Network Virtualization Edge (NVE) fails over to a standby NVE. This notification can be used only when data plane mac learning is enabled over the NVO3 tunnels.
    
draft-bradley-oauth-jwt-encoded-state-08.txt
 Encoding claims in the OAuth 2 state parameter using a JWT
 
 draft-bradley-oauth-jwt-encoded-state-08.txt
 Date: 07/01/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-05.txt
 Stateless Client Identifier for OAuth 2
 
 draft-bradley-oauth-stateless-client-id-05.txt
 Date: 07/01/2018
 Authors: John Bradley, Justin Richer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation.
    
draft-briscoe-tsvwg-l4s-diffserv-00.txt
 Interactions between Low Latency,Low Loss,Scalable Throughput (L4S) and Differentiated Services
 
 draft-briscoe-tsvwg-l4s-diffserv-00.txt
 Date: 05/03/2018
 Authors: Bob Briscoe
 Working Group: Individual Submissions (none)
 Formats: txt xml
L4S and Diffserv offer somewhat overlapping services (low latency and low loss), but bandwidth allocation is out of scope for L4S. Therefore there is scope for the two approaches to complement each other, but also to conflict. This informational document explains how the two approaches interact, how they can be arranged to complement each other and in which cases one can stand alone without needing the other.
    
draft-brissette-bess-evpn-l2gw-proto-01.txt
 EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols
 
 draft-brissette-bess-evpn-l2gw-proto-01.txt
 Date: 26/02/2018
 Authors: Patrice Brissette, Ali Sajassi, Luc Burdet, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
Existing EVPN multi-homing load-balancing modes are limited to Single-Active and All-Active. Neither of these multi-homing mechanisms are sufficient to support access networks with Layer-2 Gateway protocols such as MST-AG, REP-AG, and G.8032. These Layer-2 Gateway protocols require a new multi-homing mechanism defined in this draft.
    
draft-brissette-bess-evpn-mh-pa-01.txt
 EVPN multi-homing port-active load-balancing
 
 draft-brissette-bess-evpn-mh-pa-01.txt
 Date: 28/02/2018
 Authors: Patrice Brissette, Samir Thoria, Ali Sajassi
 Working Group: Individual Submissions (none)
 Formats: txt
The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables the establishment of a logical port-channel connection with a redundant group of independent nodes. The purpose of multi-chassis LAG is to provide a solution to achieve higher network availability, while providing different modes of sharing/balancing of traffic. EVPN standard defines EVPN based MC-LAG with single-active and all-active multi-homing load-balancing mode. The current draft expands on existing redundancy mechanisms supported by EVPN and introduces support of port-active load-balancing mode. In the current draft, port-active load-balancing mode is also referred to as per interface active/standby.
    
draft-brockners-ioam-vxlan-gpe-00.txt
 VXLAN-GPE Encapsulation for In-situ OAM Data
 
 draft-brockners-ioam-vxlan-gpe-00.txt
 Date: 30/10/2017
 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 VXLAN-GPE.
    
draft-brockners-ippm-ioam-geneve-00.txt
 Geneve encapsulation for In-situ OAM Data
 
 draft-brockners-ippm-ioam-geneve-00.txt
 Date: 05/03/2018
 Authors: Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Petr Lapukhov, Barak Gafni, Aviv Kfir, Mickey Spiegel
 Working Group: Individual Submissions (none)
 Formats: 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-00.txt
 VXLAN-GPE Encapsulation for In-situ OAM Data
 
 draft-brockners-ippm-ioam-vxlan-gpe-00.txt
 Date: 05/03/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-brockners-nvo3-ioam-geneve-00.txt
 Geneve encapsulation for In-situ OAM Data
 
 draft-brockners-nvo3-ioam-geneve-00.txt
 Date: 30/10/2017
 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: txt xml
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in Geneve.
    
draft-brockners-proof-of-transit-04.txt
 Proof of Transit
 
 draft-brockners-proof-of-transit-04.txt
 Date: 30/10/2017
 Authors: Frank Brockners, Shwetha Bhandari, Sashank Dara, Carlos Pignataro, John Leddy, Stephen Youell, David Mozes, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: xml txt
Several technologies such as Traffic Engineering (TE), Service Function Chaining (SFC), and policy based routing are used to steer traffic through a specific, user-defined path. This document defines mechanisms to securely prove that traffic transited said defined path. These mechanisms allow to securely verify whether, within a given path, all packets traversed all the nodes that they are supposed to visit.
    
draft-brockners-sfc-ioam-nsh-01.txt
 NSH Encapsulation for In-situ OAM Data
 
 draft-brockners-sfc-ioam-nsh-01.txt
 Date: 05/03/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: txt xml
In-situ Operations, Administration, and Maintenance (OAM) 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 the Network Service Header (NSH).
    
draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-01.txt
 Elliptic curve 2y^2=x^3+x over field size 8^91+5
 
 draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-01.txt
 Date: 13/04/2018
 Authors: Dan Brown
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a special elliptic curve with complex multiplication (by i) and a compact description (see title). This curve is recommended for cryptographic use in a strongest-link combination with dissimilar elliptic curves (e.g. NIST P-256, Curve25519, extension-field curves, etc.) as a defense in depth against an unlikely, unforeseen attack on otherwise preferred elliptic curves. The curve equation 2y^2=x^3+x is the Montgomery form of a curve y^2=x^3-x in a class of curves y^2=x^3-ax suggested by Miller in the first published paper elliptic curve cryptography, and an endomorphism usable for efficiency, an idea of Koblitz. The field size 8^91+5 is prime, and is relatively efficient and compactly described for its bit-size (273 bits). The document specifies some practical details such as: encoding a point (on the curve) into 34 bytes, public key validation, encoding a private key into 34 bytes, and encoding 34 bytes into a point. The document also provides pseudocode, motivation, and security considerations.
    
draft-brown-whoami-01.txt
 A Method For Identifying a Domain Operator's Point of Contact (WHOAMI)
 
 draft-brown-whoami-01.txt
 Date: 22/02/2018
 Authors: Gavin Brown
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a decentralised alternative to traditional WHOIS directories.
    
draft-browne-sfc-nsh-kpi-stamp-03.txt
 Network Service Header KPI Stamping
 
 draft-browne-sfc-nsh-kpi-stamp-03.txt
 Date: 05/03/2018
 Authors: Rory Browne, Andrey Chilikin, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a method of inserting Key Performance Indicators (KPIs) into Network Service Header (NSH) encapsulated packets or frames on service chains. This method may be used to monitor latency and QoS configuration to identify problems with virtual links (vlinks), Virtual Network Functions (VNFs) or Physical Network Functions (PNFs) on the Rendered Service Path (RSP).
    
draft-brunstrom-taps-impl-00.txt
 Implementing Interfaces to Transport Services
 
 draft-brunstrom-taps-impl-00.txt
 Date: 05/03/2018
 Authors: Anna Brunstrom, Tommy Pauly, Theresa Enghardt, Karl-Johan Grinnemo, Tom Jones, Philipp Tiesel, Colin Perkins, Michael Welzl
 Working Group: Individual Submissions (none)
 Formats: txt
The Transport Services architecture [I-D.pauly-taps-arch] defines a system that allows applications to use transport networking protocols flexibly. This document serves as a guide to implementation on how to build such a system.
    
draft-bryant-detnet-mpls-dp-00.txt
 Operation of Deterministic Networks over MPLS
 
 draft-bryant-detnet-mpls-dp-00.txt
 Date: 05/03/2018
 Authors: Stewart Bryant, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies Deterministic Networking data plane operation over an MPLS Packet Switched Networks. This document is a derivative work from draft-ietf-detnet-dp-sol-01. Whether this is published as a stand-alone text, or serves as a focal point to refine the MPLS design and the key point are subsequently re-merged with draft-ietf-detnet-dp-sol-01 is a matter for the DETNET WG, as is the editorship of any WG text.
    
draft-bryant-mpls-sfl-control-02.txt
 MPLS Flow Identification Considerations
 
 draft-bryant-mpls-sfl-control-02.txt
 Date: 28/10/2017
 Authors: Stewart Bryant, George Swallow, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: txt
In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow labels (SFL) was introduced. This document describes a control protocol that runs over an associated control header to request, withdrawn and extend the lifetime of such labels.
    
draft-bryant-rtgwg-enhanced-vpn-02.txt
 Enhanced Virtual Private Networks (VPN+)
 
 draft-bryant-rtgwg-enhanced-vpn-02.txt
 Date: 05/03/2018
 Authors: Stewart Bryant, Jie Dong, Zhenqiang Li, Takuya Miyasaka
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a number of enhancements that need to be made to virtual private networks (VPNs) to support the needs of new applications, particularly applications that are associated with 5G services. A network enhanced with these properties may form the underpin of network slicing, but will also be of use in its own right.
    
draft-bryskin-netconf-automation-yang-01.txt
 Generalized Network Control Automation YANG Model
 
 draft-bryskin-netconf-automation-yang-01.txt
 Date: 28/02/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-sf-aware-topo-model-01.txt
 SF Aware TE Topology YANG Model
 
 draft-bryskin-teas-sf-aware-topo-model-01.txt
 Date: 01/03/2018
 Authors: Igor Bryskin, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG data model for TE network topologies that are network service and function aware.
    
draft-bryskin-teas-te-topo-and-tunnel-modeling-01.txt
 TE Topology and Tunnel Modeling for Transport Networks
 
 draft-bryskin-teas-te-topo-and-tunnel-modeling-01.txt
 Date: 24/10/2017
 Authors: Igor Bryskin, Vishnu Beeram, Tarek Saad, Xufeng Liu
 Working Group: Traffic Engineering Architecture and Signaling (teas)
 Formats: txt pdf
This document describes how to model TE topologies and tunnels for transport networks, by using the TE topology YANG model [I-D.ietf- teas-yang-te-topo] and the TE tunnel YANG model [I-D.ietf-teas-yang- te].
    
draft-bryskin-teas-use-cases-sf-aware-topo-model-03.txt
 Use Cases for SF Aware Topology Models
 
 draft-bryskin-teas-use-cases-sf-aware-topo-model-03.txt
 Date: 18/03/2018
 Authors: Igor Bryskin, Xufeng Liu, Jim Guichard, Young Lee, Luis Contreras, Daniele Ceccarelli, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This document describes some use cases that benefit from the network topology models that are service and network function aware.
    
draft-bryskin-teas-yang-ietf-vs-onf-01.txt
 ONF/T-API Services vs. IETF/YANG Models and Interfaces
 
 draft-bryskin-teas-yang-ietf-vs-onf-01.txt
 Date: 27/10/2017
 Authors: Igor Bryskin, Xufeng Liu, Vishnu Beeram, Tarek Saad
 Working Group: Individual Submissions (none)
 Formats: txt
This document compares IETF YANG TE (Traffic Engineering) data model and ONF/T-API model.
    
draft-burger-stir-iana-cert-00.txt
 Registry for Country-Specific Secure Telephone Identity (STIR) Root Certificates
 
 draft-burger-stir-iana-cert-00.txt
 Date: 05/03/2018
 Authors: Eric Burger
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document defines an IANA registry that maps country codes to secure telephone identity (STIR) root certificates authorized to create signing certificates for telephone numbers under the authority of a given country. Some countries allow carriers to block unsolicited, automatically generated nuisance calls commonly known as 'robocalls.' The use of signed STIR tokens in the Session Initiation Protocol (SIP) may be useful in such scenarios to provide positive attestations as to call origin. Legacy telephone numbering resources are administrated by national policy. Unlike the market-driven use case of Web commerce, some nations may restrict the list of STIR root certificate authorities acceptable for issuing signing certificates for STIR tokens that provide attestations for their local legacy telephone numbering resources. The registry described in this document enables call recipients in a first country to validate that signaling it receives from a caller with a telephone number claiming to be in a second country conforms to the second country's policy of (1) having a limited list of STIR root certificate authorities (or not) and (2) the certificate that produced the signature over the signaling is signed by one of those authorized STIR root certificate authorities.
    
draft-burleigh-dtnwg-dtka-01.txt
 Architecture for Delay-Tolerant Key Administration
 
 draft-burleigh-dtnwg-dtka-01.txt
 Date: 02/03/2018
 Authors: Scott Burleigh, David Horres, Kapali Viswanathan, michael.w.benson@boeing.com, Fred Templin
 Working Group: Individual Submissions (none)
 Formats: txt xml
Delay-Tolerant Key Administration (DTKA) is a system of public-key management protocols intended for use in Delay Tolerant Networking (DTN). This document outlines a DTKA proposal for space-based communications, which are characterized by long communication delays and planned communication contacts.
    
draft-bvtm-dhc-mac-assign-00.txt
 Link-Layer Addresses Assignment Mechanism for DHCPv6
 
 draft-bvtm-dhc-mac-assign-00.txt
 Date: 05/03/2018
 Authors: Bernie Volz, Tomek Mrugalski
 Working Group: Individual Submissions (none)
 Formats: txt xml
In certain environments, e.g. large scale virtualization deployments, new devices are created in an automated manner. Such devices typically have their link-layer (MAC) addresses randomized. With sufficient scale, the likelihood of collision is not acceptable. Therefore an allocation mechanism is required. This draft proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments.
    
draft-bz-v4goawayflag-00.txt
 IPv6 Router Advertisement IPv4 GoAway Flag
 
 draft-bz-v4goawayflag-00.txt
 Date: 31/03/2018
 Authors: Bjoern Zeeb
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a Router Advertisement Flag to indicate to end nodes that IPv4 support must be disabled on this link. In addition this document presents a policy and a timeline on how to deal with this flag and the going-away of IPv4. This document updates RFC5175.
    
draft-calconnect-vobject-integrity-01.txt
 Integrity Protection for vObject,vCard and iCalendar
 
 draft-calconnect-vobject-integrity-01.txt
 Date: 19/04/2018
 Authors: Ronald Tse, Peter Tam
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an integrity checking mechanism and related properties for: o vObject (I-D.calconnect-vobject-vformat) o vCard version 4 (vCard v4) (RFC 6350); and o iCalendar (Internet Calendaring and Scheduling Core Object Specification) (RFC 5545) This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.
    
draft-calconnect-vobject-vformat-01.txt
 The vObject Model and vFormat Syntax
 
 draft-calconnect-vobject-vformat-01.txt
 Date: 19/04/2018
 Authors: Ronald Tse, Peter Tam, Cyrus Daboo, Ken Murchison
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the vObject data model and its corresponding syntax vFormat. vObject represents the generalized data model, and vFormat the generalized data format, of the following specifications and fully covers them: o RFC 6350, vCard version 4.0: the VCARD component; o RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar): the VCALENDAR, VEVENT, VJOURNAL, VFREEBUSY, VTIMEZONE, VALARM, VTODO, STANDARD and DAYLIGHT components; o RFC 7953, Calendar Availability Extensions: the VAVAILABILITY and AVAILABLE components; o I-Ddaboo-icalendar-vpatch, iCalendar Patching: the VPATCH component; and o alternative formats for iCalendar and vCard, including RFC 6321, xCal; RFC 7265, jCal; RFC 6351, xCard; and RFC 7095, jCard. This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.
    
draft-camelot-holy-grenade-01.txt
 The Holy Hand Grenade of Antioch
 
 draft-camelot-holy-grenade-01.txt
 Date: 15/04/2018
 Authors: Arthur Pendragon
 Working Group: Individual Submissions (none)
 Formats: xml txt
The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635.
    
draft-campbell-sip-messaging-smime-02.txt
 Securing Session Initiation Protocol (SIP) based Messaging with S/MIME
 
 draft-campbell-sip-messaging-smime-02.txt
 Date: 26/12/2017
 Authors: Ben Campbell, Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFC 3261, RFC 3428, and RFC 4975.
    
draft-camwinget-tls-use-cases-01.txt
 TLS 1.3 Impact on Network-Based Security
 
 draft-camwinget-tls-use-cases-01.txt
 Date: 05/03/2018
 Authors: Flemming Andreasen, Nancy Cam-Winget, Eric Wang
 Working Group: Individual Submissions (none)
 Formats: txt
Network-based security solutions are used by enterprises, public sector, and cloud service providers today in order to both complement and augment host-based security solutions. TLS 1.3 introduces several changes to TLS 1.2 with a goal to improve the overall security and privacy provided by TLS. However some of these changes have a negative impact on network-based security solutions. While this may be viewed as a feature, there are several real-life use case scenarios that are not easily solved without such network-based security solutions. In this document, we identify the TLS 1.3 changes that may impact network-based security solutions and provide a set of use case scenarios that are not easily solved without such solutions.
    
draft-carney-regext-domainconnect-03.txt
 Domain Connect API - Communications between DNS Provider and Services
 
 draft-carney-regext-domainconnect-03.txt
 Date: 18/01/2018
 Authors: Arnold Blinn, rcarney@godaddy.com
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides information related to the Domain Connect API that was built to support communications between DNS Providers and Service Providers (hosting, social, email, hardware, etc.).
    
draft-carpenter-anima-asa-guidelines-04.txt
 Guidelines for Autonomic Service Agents
 
 draft-carpenter-anima-asa-guidelines-04.txt
 Date: 03/03/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-01.txt
 Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP)
 
 draft-carpenter-anima-grasp-bulk-01.txt
 Date: 03/03/2018
 Authors: Brian Carpenter, Sheng Jiang, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes how bulk data may be transferred between Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol (GRASP).
    
draft-cavage-http-signatures-09.txt
 Signing HTTP Messages
 
 draft-cavage-http-signatures-09.txt
 Date: 16/11/2017
 Authors: Mark Cavage, Manu Sporny
 Working Group: Individual Submissions (none)
 Formats: txt xml
When communicating over the Internet using the HTTP protocol, it can be desirable for a server or client to authenticate the sender of a particular message. It can also be desirable to ensure that the message was not tampered with during transit. This document describes a way for servers and clients to simultaneously add authentication and message integrity to HTTP messages by using a digital signature.
    
draft-cc-isis-flooding-reduction-00.txt
 ISIS Flooding Reduction
 
 draft-cc-isis-flooding-reduction-00.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an approach to flood ISIS link state protocol data units on a topology that is a subgraph of the complete ISIS topology per underline physical network, so that the amount of flooding traffic in the network is greatly reduced, and it would reduce convergence time with a more stable and optimized routing environment. The approach can be applied to any network topology in a single ISIS area.
    
draft-cc-ospf-flooding-reduction-01.txt
 OSPF Flooding Reduction
 
 draft-cc-ospf-flooding-reduction-01.txt
 Date: 20/04/2018
 Authors: Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an approach to flood OSPF link state advertisements on a topology that is a subgraph of the complete OSPF topology per underline physical network, so that the amount of flooding traffic in the network is greatly reduced, and it would reduce convergence time with a more stable and optimized routing environment. The approach can be applied to any network topology in a single OSPF area, and can be used in both OSPFv2 ([RFC2328]) network and OSPFv3 ([RFC5340]) network.
    
draft-cds-functional-architecture-00.txt
 Cloud-based data provision service requirements and functional architecture
 
 draft-cds-functional-architecture-00.txt
 Date: 18/12/2017
 Authors: Eui-Nam Huh, gawon@khu.ac.kr, Yunkon Kim, Jintaek Kim
 Working Group: Individual Submissions (none)
 Formats: txt
The draft describes concept and characteristics of cloud-based data providing service. To derive functional architecture, requirements are described on the perspective of providing and using data.
    
draft-cds-overviews-00.txt
 Cloud-based data providing service definition,concept,and use-cases
 
 draft-cds-overviews-00.txt
 Date: 18/12/2017
 Authors: Eui-Nam Huh, gawon@khu.ac.kr, Yunkon Kim, Jintaek Kim
 Working Group: Individual Submissions (none)
 Formats: txt
The standard defines terminologies and describes ecosystem for cloud- based data providing service. In order to build unified data environment from the dispersed data, data providing service is necessary for big data service. Therefore, this standard contributes to form common data providing ecosystem.
    
draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
 Linux-related Extensions to NFS version 4.2 Security Labels
 
 draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
 Date: 10/04/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: xml txt
NFS version 4.2 introduces an optional feature known as NFSv4 Security Labels. This document extends NFSv4 Security Labels to support Linux file capabilities and the Linux Integrity Measurement Architecture.
    
draft-cel-nfsv4-mv0-trunking-update-00.txt
 NFS version 4.0 Trunking Update
 
 draft-cel-nfsv4-mv0-trunking-update-00.txt
 Date: 13/11/2017
 Authors: Chuck Lever, David Noveck
 Working Group: Individual Submissions (none)
 Formats: xml txt
Location-related attributes in NFS version 4.0 are used to support the migration and replication of server file systems. In this document, we describe an additional use for these attributes as a mechanism to enable client discovery of an NFS version 4.0 server's trunking capabilities. The interaction of trunking with migration and replication is also clarified. This document updates RFC 7530.
    
draft-cel-nfsv4-reminv-design-07.txt
 Using Remote Invalidation With RPC-Over-RDMA Transports
 
 draft-cel-nfsv4-reminv-design-07.txt
 Date: 09/01/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
Remote Invalidation relieves RDMA responders of some of the burden of preparing memory to be accessed remotely, thus reducing the latency of RDMA Read and Write operations. This document considers how to introduce generic support for Remote Invalidation to RPC-over-RDMA transport protocols.
    
draft-cel-nfsv4-rpcrdma-cm-pvt-msg-03.txt
 RDMA Connection Manager Private Data For RPC-Over-RDMA Version 1
 
 draft-cel-nfsv4-rpcrdma-cm-pvt-msg-03.txt
 Date: 19/03/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the format of RDMA-CM Private Data exchanged between RPC-over-RDMA version 1 peers as a transport connection is established. Such messages indicate peer support for Remote Invalidation and larger-than-default inline thresholds. The message format is extensible.
    
draft-cel-nfsv4-rpcrdma-reliable-reply-02.txt
 Improving the Performance and Reliability of RPC Replies on RPC-over-RDMA Transports
 
 draft-cel-nfsv4-rpcrdma-reliable-reply-02.txt
 Date: 09/01/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
RPC transports such as RPC-over-RDMA Version One require reply buffers to be in place before an RPC Call is sent. However, Upper Layer Protocols sometimes have difficulty estimating the expected maximum size of RPC replies. 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-06.txt
 RPC-over-RDMA Version 2 Protocol
 
 draft-cel-nfsv4-rpcrdma-version-two-06.txt
 Date: 09/01/2018
 Authors: Chuck Lever, David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies an improved protocol for conveying Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA), based on RPC-over-RDMA version 1.
    
draft-cfrg-khera-lpr-ring-lwe-kex-00.txt
 Post-Quantum Key Exchange From Learning With Errors Over Rings
 
 draft-cfrg-khera-lpr-ring-lwe-kex-00.txt
 Date: 24/10/2017
 Authors: Rohit Khera
 Working Group: Individual Submissions (none)
 Formats: txt
This note describes a key exchange method based on the ring-LWE (RLWE) assumption. It builds upon several results, including Regev's landmark quantum reduction from certain worst case lattice problems (approx. GapSVP and SIVP) to random instances of the search variant of a particular learning problem (LWE). It also builds on the follow on work of Lyubashevsky, Peikert and Regev on the average case hardness of the RLWE search variant for polynomially bounded numbers of RLWE samples, along with novel applications of automorphism groups in number fields for a RLWE search to decision reduction (thereby demonstrating pseudorandomness of RLWE in these number fields). Subsequently, these results were adopted for the construction of Diffie-Hellman like key exchange methods by Peikert, and then by Lindner and Peikert followed by Ding and then by Ding, Xie and Lin who proposed efficient variants of such protocols. Subsequent work by Peikert proposed another efficient variant, phrased as a key encapsulation method, incorporating a low bandwidth "reconciliation" technique allowing two parties to exactly agree on a uniformly distributed secret value from noisy RLWE instances. This was followed by a concrete instantiation with parameter sets by Bos, Costello, Naehrig, Stebila, followed by another instantiation by Alkim, Ducas, Poppelmann and Schwabe with the same ring polynomial but a smaller modulus and a different reconciliation method. Unlike most other public key cryptography based key exchange methods, it is believed that RLWE based key exchange would remain secure in the event that an adversary is able to build a quantum computer. This document is a product of the Crypto Forum Research Group (CFRG).
    
draft-chang-6tisch-msf-01.txt
 6TiSCH Minimal Scheduling Function (MSF)
 
 draft-chang-6tisch-msf-01.txt
 Date: 02/03/2018
 Authors: Tengfei Chang, Malisa Vucinic, Xavier Vilajosana
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
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 6top Protocol (6P) and the Minimal Security Framework for 6TiSCH.
    
draft-chen-ati-adaptive-ipv4-address-space-02.txt
 Adaptive IPv4 Address Space
 
 draft-chen-ati-adaptive-ipv4-address-space-02.txt
 Date: 10/12/2017
 Authors: Abraham Chen, Ramamurthy Ati, Abhay Karandikar
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. The EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, nor the current private networks. The EzIP is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivities, but also their interoperability. The EzIP deployment may coexist with the current Internet traffic and the IoT (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to choose either. If the IPv4 public pool allocations were allowed to be reorganized, the assignable pool could be multiplied by 512M times or even more. The EzIP may be implemented as a software / firmware enhancement to the Internet edge routers or private network routing gateways wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed herein establishes a complete layer of routers for interfacing between the Internet core fabic and the end user premises. Incorporating the caching proxy technology in the gateway, a fairly large geographical area may deploy an EzIP based sub- Internet operating from as few as one ordinary IPv4 public address. This will immediately resolve the IPv4 address shortage anywhere, while transparent to the current Internet operation. Under the Dual- Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording the IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.
    
draft-chen-bess-evpn-df-algorithm-selection-00.txt
 EVPN DF Election Algorithm Selection
 
 draft-chen-bess-evpn-df-algorithm-selection-00.txt
 Date: 28/11/2017
 Authors: Jian Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a new EVPN Designated Forwarder Election (DF) method which can be used to select a proper DF Election algorithm.
    
draft-chen-bfd-unsolicited-02.txt
 Unsolicited BFD for Sessionless Applications
 
 draft-chen-bfd-unsolicited-02.txt
 Date: 30/01/2018
 Authors: Enke Chen, Naiming Shen, Robert Raszuk
 Working Group: Individual Submissions (none)
 Formats: txt
For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies).
    
draft-chen-bier-pce-bier-04.txt
 PCEP Extensions for BIER
 
 draft-chen-bier-pce-bier-04.txt
 Date: 06/02/2018
 Authors: Ran Chen, Zheng Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [I-D.ietf-bier-architecture]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies.BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) to handle requests and responses for the computation of paths for BIER-TE.
    
draft-chen-bier-rpcs-yang-00.txt
 YANG Data Model for BIER RPCs
 
 draft-chen-bier-rpcs-yang-00.txt
 Date: 11/02/2018
 Authors: Ran Chen, Min Gu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for BIER RPCs.
    
draft-chen-bier-te-ping-03.txt
 BIER-TE Ping and Trace
 
 draft-chen-bier-te-ping-03.txt
 Date: 11/12/2017
 Authors: Ran Chen, Shaofu Peng
 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. This document describes the mechanism and basic BIER-TE OAM packet format that can be used to perform Ping and Traceroute on BIER-TE network.
    
draft-chen-ds-description-00.txt
 Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.
 
 draft-chen-ds-description-00.txt
 Date: 28/11/2017
 Authors: YP Chen, H Xia, ZM Wang, P Yang, CW Tang
 Working Group: Individual Submissions (none)
 Formats: txt
The rapid development of Internet has driven more and more enterprises or individuals encapsulate operations on key data entities we call data service (DS). Due to the different fields between enterprise or individual, resulting in the description of data services appear semantic heterogeneity. In this paper, we propose a more principled approach to the problems of heterogeneous data service on the Web. We start with a data service description document pre-processing. Finally, we propose a unified description language model for data service, the Unified Description Language for Data Service (UDL4DS).
    
draft-chen-iot-energy-electricity-00.txt
 Overview of Internet of Things with Energy and Electricity Industries
 
 draft-chen-iot-energy-electricity-00.txt
 Date: 23/12/2017
 Authors: Lihao Chen, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces general problems of energy and electricity industries and discusses how these industries could benefit from Internet of Things (IoT). Use cases are provided and potential technical gaps and protocol needs in IETF are evaluated.
    
draft-chen-isis-black-hole-avoid-02.txt
 Avoiding Traffic Black-Holes for Route Aggregation in IS-IS
 
 draft-chen-isis-black-hole-avoid-02.txt
 Date: 05/03/2018
 Authors: Zhe Chen, Xiaohu Xu, Dean Cheng
 Working Group: Individual Submissions (none)
 Formats: xml txt
When the Intermediate System to Intermediate System (IS-IS) routing protocol is adopted by a highly symmetric network such as the Leaf- Spine or Fat-Tree network, the Leaf nodes (e.g., Top of Rack switches in datacenters) are recommended to be prevented from receiving other nodes' explicit routes in order to achieve scalability. However, such a setup would cause traffic black-holes or suboptimal routing if link failure happens in the network. This document introduces INFINITE cost to IS-IS LSPs to solve this problem.
    
draft-chen-isis-ias-lk-02.txt
 ISIS Extensions for Broadcast Inter-AS TE Link
 
 draft-chen-isis-ias-lk-02.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the ISIS protocol for advertising broadcast inter-AS Traffic Engineering (TE) links.
    
draft-chen-isis-sl-overheads-reduction-03.txt
 Overheads Reduction for IS-IS Enabled Spine-Leaf Networks
 
 draft-chen-isis-sl-overheads-reduction-03.txt
 Date: 05/03/2018
 Authors: Zhe Chen, Xiaohu Xu, Dean Cheng
 Working Group: Individual Submissions (none)
 Formats: txt xml
When a Spine-Leaf topology adopts the Intermediate System to Intermediate System (IS-IS) routing protocol, the Leaf node receives Link State Packets (LSPs) from all the other nodes thus having the entire routing information of the topology. This is usually considered unnecessary and costly. This document describes a solution to this problem by utilizing IS-IS's inherent multi-level and area partition features, which requires that an IS-IS router SHOULD check a level-1 LSP's area addresses before advertising it to a neighbor.
    
draft-chen-isis-ttz-05.txt
 IS-IS Topology-Transparent Zone
 
 draft-chen-isis-ttz-05.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Renwei Li, Alvaro Retana, Ning So, Vic liu, Mehmet Toy, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a topology-transparent zone in a domain. A zone comprises a group of routers and a number of circuits connecting them. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a circuit down inside the zone is not seen by any router outside of the zone.
    
draft-chen-nvo3-vxlan-yang-06.txt
 YANG Data Model for VxLAN Protocol
 
 draft-chen-nvo3-vxlan-yang-06.txt
 Date: 03/01/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-ospf-abnormal-state-info-02.txt
 OSPF Abnormal State Information
 
 draft-chen-ospf-abnormal-state-info-02.txt
 Date: 05/03/2018
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain.
    
draft-chen-ospf-ias-lk-02.txt
 OSPF Extensions for Broadcast Inter-AS TE Link
 
 draft-chen-ospf-ias-lk-02.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Open Shortest Path First (OSPF) for advertising broadcast inter-AS Traffic Engineering (TE) links.
    
draft-chen-pals-pw-yang-03.txt
 YANG Data Model for PW Protocol
 
 draft-chen-pals-pw-yang-03.txt
 Date: 11/12/2017
 Authors: Ran Chen, fangwei hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for PW configuration and operation.
    
draft-chen-pce-bier-03.txt
 PCEP Extensions for BIER
 
 draft-chen-pce-bier-03.txt
 Date: 06/02/2018
 Authors: Ran Chen, Zheng Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [I-D.ietf-bier-architecture]. BIER-TE forwards and replicates packets based on a BitString in the packet header, but every BitPosition of the BitString of a BIER-TE packet indicates one or more adjacencies.BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) to handle requests and responses for the computation of paths for BIER-TE.
    
draft-chen-pce-compute-backup-egress-12.txt
 Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path
 
 draft-chen-pce-compute-backup-egress-12.txt
 Date: 30/10/2017
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress.
    
draft-chen-pce-compute-backup-ingress-12.txt
 Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path
 
 draft-chen-pce-compute-backup-ingress-12.txt
 Date: 30/10/2017
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress.
    
draft-chen-pce-forward-search-p2mp-path-13.txt
 A Forward-Search P2MP TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2mp-path-13.txt
 Date: 30/10/2017
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described.
    
draft-chen-pce-forward-search-p2p-path-computation-14.txt
 A Forward-Search P2P TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2p-path-computation-14.txt
 Date: 30/10/2017
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described.
    
draft-chen-pce-h-connect-access-04.txt
 PCEP Link State Abstraction
 
 draft-chen-pce-h-connect-access-04.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a child PCE to abstract its domain information to its parent for supporting a hierarchical PCE system.
    
draft-chen-pce-h-discovery-04.txt
 Hierarchical PCE Determination
 
 draft-chen-pce-h-discovery-04.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for determining parent child relations and exchanging the information between a parent and a child PCE in a hierarchical PCE system.
    
draft-chen-pce-h-sdns-03.txt
 PCE Hierarchical SDNs
 
 draft-chen-pce-h-sdns-03.txt
 Date: 30/10/2017
 Authors: Huaimo Chen, Mehmet Toy, Lei Liu, Vic liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for supporting a hierarchical SDN control system, which comprises multiple SDN controllers controlling a network with a number of domains.
    
draft-chen-pce-label-x-domains-07.txt
 Extensions to PCEP for Distributing Label Cross Domains
 
 draft-chen-pce-label-x-domains-07.txt
 Date: 30/10/2017
 Authors: Huaimo Chen, Autumn Liu, Fengman Xu, Mehmet Toy, Vic liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP).
    
draft-chen-pce-pcc-ted-04.txt
 Static PCEP Link State
 
 draft-chen-pce-pcc-ted-04.txt
 Date: 05/03/2018
 Authors: Huaimo Chen, Mehmet Toy, Xufeng Liu, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to advertise the information about the links without running IGP and for a PCE to build a TED based on the information received.
    
draft-chen-pce-protection-applicability-11.txt
 The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks.
 
 draft-chen-pce-protection-applicability-11.txt
 Date: 30/10/2017
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE.
    
draft-chen-spring-segemt-routing-anycast-frr-00.txt
 Anycast-SID FRR for Segment Routing Network
 
 draft-chen-spring-segemt-routing-anycast-frr-00.txt
 Date: 07/12/2017
 Authors: Ran Chen, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the fast redundancy protection mechanism, aimed at providing protection of the domain boundary nodes in Cross domain scenario.
    
draft-cheng-pals-p2p-pw-multicast-00.txt
 Efficient Layer 2 Multicast with Point-to-Point Pseudowires
 
 draft-cheng-pals-p2p-pw-multicast-00.txt
 Date: 30/11/2017
 Authors: Weiqiang Cheng, Jie Dong
 Working Group: Individual Submissions (none)
 Formats: txt
Multicast services such as Evolved Multimedia Broadcast/Multicast Service (eMBMS) become more and more popular in mobile networks. In mobile transport network, it is important for the operators to provide efficient transport of multicast services with existing network devices. This document describes a mechanism of using point- to-point Pseudowires (PW) [RFC 3985] to achieve efficient layer 2 multicast transportation in mobile transport networks.
    
draft-cheng-spring-mpls-path-segment-01.txt
 Path Segment in MPLS Based Sement Routing Network
 
 draft-cheng-spring-mpls-path-segment-01.txt
 Date: 05/03/2018
 Authors: Weiqiang Cheng, Lei Wang, Han Li, Mach Chen, Royi Zigler, Shuangping Zhan
 Working Group: Individual Submissions (none)
 Formats: txt
An SR path is identified by an SR segment list, one or partial segments of the list cannot uniquely identify the SR path. This document introduces the concept of Path Segment that is used to identify an SR path. When used, it is inserted at the ingress node of the SR path and immediately follows the last segment of the SR path. The Path Segment will not be popped off until it reaches the egress of the SR path, it can be used by the egress node to implement end-2-end SR path protection or performance measurement (PM) (especially for measuring packet loss of real traffic) of an SR path.
    
draft-cheshire-dnssd-privacy-considerations-01.txt
 Private Discovery Threat Considerations
 
 draft-cheshire-dnssd-privacy-considerations-01.txt
 Date: 13/11/2017
 Authors: Stuart Cheshire
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides a framework for evaluating and comparing solutions for privacy-respecting discovery mechanisms.
    
draft-cheshire-dnssd-roadmap-01.txt
 Service Discovery Road Map
 
 draft-cheshire-dnssd-roadmap-01.txt
 Date: 21/03/2018
 Authors: Stuart Cheshire
 Working Group: Extensions for Scalable DNS Service Discovery (dnssd)
 Formats: txt
Over the course of several years, a rich collection of technologies has developed around DNS-Based Service Discovery, described across multiple documents. This "Road Map" document gives an overview of how these related but separate technologies (and their documents) fit together, to facilitate service discovery in various environments.
    
draft-cheshire-sudn-ipv4only-dot-arpa-08.txt
 Special Use Domain Name 'ipv4only.arpa'
 
 draft-cheshire-sudn-ipv4only-dot-arpa-08.txt
 Date: 30/10/2017
 Authors: Stuart Cheshire, David Schinazi
 Working Group: Individual Submissions (none)
 Formats: txt xml
The specification for how a client discovers its network's NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but declares it to be a non-special name in that specification's Domain Name Reservation Considerations section. Consequently, despite the well articulated special purpose of the name, (at the time of writing) 'ipv4only.arpa' still does not appear as one of the names with special properties recorded in the Special- Use Domain Names registry. 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 is no clear mandate authorizing software authors to implement that special treatment. Software implementers are left with the choice between not implementing the special behavior necessary for the name queries to work correctly, or implementing the special behavior and being accused of being noncompliant with some RFC. This document formally declares the actual special properties of the name, and adds similar declarations for the corresponding reverse mapping names.
    
draft-chin-nfvrg-cloud-5g-core-structure-yang-00.txt
 Yang Data Model for Cloud Native 5G Core structure
 
 draft-chin-nfvrg-cloud-5g-core-structure-yang-00.txt
 Date: 28/12/2017
 Authors: Chin Chen, Ziquan Pan
 Working Group: Individual Submissions (none)
 Formats: txt
In 5G core network, all network functions are componentized, virtualized and grouped into VNF. Network management system will manage the functions based on VNF. This document presents YANG model proposal on overall structure of cloud native 5G core network. The structure is itself represented as an example YANG model, with all of the related component models logically organized in a way that is operationally intuitive, but this model is not expected to be implemented. The identified component modules are expected to be defined and implemented.
    
draft-chodorek-traffic-flow-option-08.txt
 An IP option for describing the traffic flow
 
 draft-chodorek-traffic-flow-option-08.txt
 Date: 28/12/2017
 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-chunduri-idr-bgp-ls-nspfid-00.txt
 BGP Link-State extensions for NSPF ID
 
 draft-chunduri-idr-bgp-ls-nspfid-00.txt
 Date: 02/04/2018
 Authors: Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: txt
Non Shortest Paths (NSPs) used in routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. NSPs help to reduce the data plane path overhead, mitigate from MTU issues as well as performance related issues in certain data planes and allows granular traffic accounting in the network. NSPs are created locally by operator or can be provisioned through PCE or Yang from outside. This document describes a mechanism by which NSP information currently active in the network using the BGP routing protocol by defining extensions to BGP Link- state address-family.
    
draft-chunduri-lsr-isis-mt-deployment-cons-00.txt
 IS-IS Multi Topology Deployment Considerations
 
 draft-chunduri-lsr-isis-mt-deployment-cons-00.txt
 Date: 24/04/2018
 Authors: Uma Chunduri, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes IS-IS Multi Topology (MT) considerations in various deployments (Core/Mobile Backhaul/Data Center underlay). This document explores nuances around various IS-IS address families, topologies and considerations while choosing the right combination for a specific DC/mobile backhaul deployment.
    
draft-chunduri-lsr-isis-prefix-multi-algo-00.txt
 Multiple Algorithm support for IS-IS Prefixes
 
 draft-chunduri-lsr-isis-prefix-multi-algo-00.txt
 Date: 17/04/2018
 Authors: Uma Chunduri, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an extension to Intermediate System to Intermediate System (IS-IS) protocol by adding an Algorithm support for prefixes advertised. This allows multiple independent algorithm usage for computing the reachability of nodes and prefixes as opposed to only one algorithm.
    
draft-chung-dtn-extension-prophet-icn-01.txt
 Extension of Probabilistic Routing Protocol using History of Encounters and Transitivity for Information Centric Network
 
 draft-chung-dtn-extension-prophet-icn-01.txt
 Date: 17/03/2018
 Authors: Yun Chung, Min Kang, Young-Han Kim
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes extension of probabilistic routing protocol using history of encounters and transitivity (PRoPHET) for information centric network.
    
draft-clacla-netmod-model-catalog-03.txt
 YANG module for yangcatalog.org
 
 draft-clacla-netmod-model-catalog-03.txt
 Date: 03/04/2018
 Authors: Joe Clarke, Benoit Claise
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a YANG module that contains metadata related to YANG modules and vendor implementations of those YANG modules.
    
draft-clacla-netmod-yang-model-update-03.txt
 New YANG Module Update Procedure
 
 draft-clacla-netmod-yang-model-update-03.txt
 Date: 15/12/2017
 Authors: Benoit Claise, Joe Clarke, Balazs Lengyel, Kevin D'Souza
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a new YANG module update procedure in case of backward-incompatible changes, as an alternative proposal to the YANG 1.1 specifications. This document updates RFC 7950.
    
draft-claise-semver-02.txt
 Semantic Versioning and Structure for IETF Specifications
 
 draft-claise-semver-02.txt
 Date: 17/01/2018
 Authors: Benoit Claise, Richard Barnes, Joe Clarke
 Working Group: Individual Submissions (none)
 Formats: txt
In the Internet engineering ecosystem, there is increasingly a need for specifications that evolve over time, and which are encoded directly in structured formats (e.g., YANG models). Internet-Drafts are a poor fit for working groups that want to produce structured specifications, and publishing versions of an evolving specification as RFC makes it difficult to track the specification over time. This document outlines recommendations for how working groups can provide consistent, meaningful versions for specifications over time and work directly on structured documents while still fitting within established IETF processes.
    
draft-clausen-lln-rpl-experiences-11.txt
 Observations on RPL: IPv6 Routing Protocol for Low power and Lossy Networks
 
 draft-clausen-lln-rpl-experiences-11.txt
 Date: 27/03/2018
 Authors: Thomas Clausen, Axel Verdiere, Jiazi Yi, Ulrich Herberg, Yuichi Igarashi
 Working Group: Individual Submissions (none)
 Formats: txt
With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - published as a Proposed Standard after a ~2-year development cycle, this document presents an observation of the resulting protocol, of its applicability, and of its limits. The documents presents a selection of observations on the protocol characteristics, exposes experiences acquired when producing various prototype implementations of RPL, and presents results obtained from testing this protocol - by way of network simulations, in network testbeds and in deployments. The document aims at providing a better understanding of possible limits of RPL, notably the possible directions that further protocol developments should explore, in order to address these.
    
draft-clausen-manet-olsrv2-mgmt-snapshot-00.txt
 Snapshot of OLSRv2-Routed MANET Management
 
 draft-clausen-manet-olsrv2-mgmt-snapshot-00.txt
 Date: 14/01/2018
 Authors: Thomas Clausen, Ulrich Herberg
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how Mobile Ad Hoc Networks (MANETs) are typically managed, in terms of pre-deployment management, as well as rationale and means of monitoring and management of MANET routers running the Optimized Link State Routing protocol version 2 (OLSRv2) and its constituent MANET Neighborhood Discovery Protocol (NHDP). Apart from pre-deployment management for setting up IP addresses and security related credentials, OLSRv2 only needs routers to agree one single configuration parameter (called "C"). Other parameters for tweaking network performance may be determined during operation of the network, and need not be the same in all routers. This, using MIB modules and related management protocols such as SNMP (or possibly other, less "chatty", protocols). In addition, for debugging purposes, monitoring data and performance related counters, as well as notifications ("traps") can be sent to the Network Management System (NMS) via standardized management protocols.
    
draft-clemm-netconf-nmda-diff-03.txt
 Comparison of NMDA datastores
 
 draft-clemm-netconf-nmda-diff-03.txt
 Date: 19/03/2018
 Authors: Alexander Clemm, Yingzhen Qu, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an RPC operation to compare management datastores that comply with the NMDA architecture.
    
draft-clemm-nmrg-dist-intent-00.txt
 Distinguishing Intent,Policy,and Service Models
 
 draft-clemm-nmrg-dist-intent-00.txt
 Date: 30/10/2017
 Authors: Alexander Clemm, Laurent Ciavaglia, Lisandro Granville
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents existing definitions of the Intent, Policy, and Service Models concepts, analyses their differences and commonalities, and how the concepts relate to one another. The document is intended to clarify the different concepts and converge towards a common and shared understanding, and then use this foundation to guide further definition of valid research and engineering problems and their solutions.
    
draft-coene-rserpool-applic-ipfix-19.txt
 Reliable Server Pooling Applicability for IP Flow Information Exchange
 
 draft-coene-rserpool-applic-ipfix-19.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Lode Coene, Phillip Conrad
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of the Reliable Server Pooling architecture to the IP Flow Information Exchange using the Aggregate Server Access Protocol (ASAP) functionality of RSerPool only. Data exchange in IPFIX between the router and the data collector can be provided by a limited retransmission protocol.
    
draft-contreras-layered-sdn-01.txt
 Cooperating Layered Architecture for SDN
 
 draft-contreras-layered-sdn-01.txt
 Date: 30/10/2017
 Authors: Luis Contreras, Carlos Bernardos, Diego Lopez, Mohamed Boucadair, Paola Iovanna
 Working Group: Individual Submissions (none)
 Formats: txt
Software Defined Networking proposes the separation of the control plane from the data plane in the network nodes and its logical centralization on a control entity. Most of the network intelligence is moved to this functional entity. Typically, such entity is seen as a compendium of interacting control functions in a vertical, tight integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that relies upon transport capabilities. This document describes a proposal named Cooperating Layered Architecture for SDN. The idea behind that is to differentiate the control functions associated to transport from those related to services, in such a way that they can be provided and maintained independently, and can follow their own evolution path.
    
draft-cremers-cfrg-randomness-improvements-00.txt
 Randomness Improvements for Security Protocols
 
 draft-cremers-cfrg-randomness-improvements-00.txt
 Date: 01/03/2018
 Authors: Cas Cremers, Luke Garratt, Stanislav Smyshlyaev, Nick Sullivan, Christopher Wood
 Working Group: Individual Submissions (none)
 Formats: txt
Randomness is a crucial ingredient for TLS and related security protocols. Weak or predictable "cryptographically-strong" pseudorandom number generators (CSPRNGs) can be abused or exploited for malicious purposes. The Dual EC random number backdoor and Debian bugs are relevant examples of this problem. This document describes a way for security protocol participants to mix their long- term private key into the entropy pool(s) from which random values are derived. This augments and improves randomness from broken or otherwise subverted CSPRNGs.
    
draft-cridland-kitten-clientkey-00.txt
 Client Key SASL mechanism
 
 draft-cridland-kitten-clientkey-00.txt
 Date: 08/01/2018
 Authors: Dave Cridland
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a SASL mechanism which might be used to authenticate specific clients on devices owned by a user.
    
draft-ct-isis-nspfid-for-sr-paths-01.txt
 Usage of Non Shortest Path Forwarding (NSPF) IDs in IS-IS
 
 draft-ct-isis-nspfid-for-sr-paths-01.txt
 Date: 23/03/2018
 Authors: Uma Chunduri, Jeff Tantsura, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the advertisement of Non Shortest Path Forwarding IDentifier (NSPF ID) TLV and the computation procedures for the same in IS-IS protocol. NSPF ID allows to simplify the data plane path description of data traffic in SR deployments. This helps mitigate the MTU issues that are caused by additional SR overhead of the packet and allows traffic statistics.
    
draft-ct-mt-considerations-dc-fabrics-00.txt
 Multi Topology Considerations for DC Fabrics
 
 draft-ct-mt-considerations-dc-fabrics-00.txt
 Date: 30/10/2017
 Authors: Uma Chunduri, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes IS-IS Multi Topology (MT) considerations in general and specific to layer-3 Data Center (DC) proposals based on IS-IS protocol. This document explores various IS-IS address families, topologies and considerations while choosing the right combination for a specific DC deployment.
    
draft-ct-ospf-nspfid-for-sr-paths-00.txt
 Usage of Non Shortest Path Forwarding (NSPF) IDs in OSPF
 
 draft-ct-ospf-nspfid-for-sr-paths-00.txt
 Date: 24/03/2018
 Authors: Uma Chunduri, Yingzhen Qu, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the advertisement of Non Shortest Path Forwarding IDentifier (NSPF ID) TLV and the computation procedures for the same in OSPFv2 and OSPFv3 protocols. NSPF ID allows to simplify the data plane path description of data traffic in SR deployments. This helps to mitigate the MTU issues that are caused by additional SR overhead of the packet and allows traffic statistics.
    
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-06.txt
 Privacy-Enhanced-Tokens (PAT) profile for ACE
 
 draft-cuellar-ace-pat-priv-enhanced-authz-tokens-06.txt
 Date: 02/01/2018
 Authors: Jorge Cuellar, prabhakaran1989@gmail.com, Daniel Calvo
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines PAT, "Privacy-Enhanced-Authorization- Tokens", an efficient protocol and an unlinkable-token construction procedure for client authorization in a constrained environment. This memo also specifies a profile for ACE framework for Authentication and Authorization. The PAT draft uses symmetric cryptography, proof-of-possession (PoP) for a key owned by the client that is bound to an OAuth 2.0 access-token.
    
draft-cuspdt-rtgwg-cu-separation-bng-deployment-01.txt
 Deployment Model of Control Plane and User Plane Separated BNG
 
 draft-cuspdt-rtgwg-cu-separation-bng-deployment-01.txt
 Date: 26/02/2018
 Authors: Rong Gu, Sujun Hu, Zitao Wang, fangwei hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces deployment model of BNG device with Control Plane and User Plane separation in order to give guidance of the deployment of CP and UP separated BNG devices in operators' network.
    
draft-cuspdt-rtgwg-cu-separation-infor-model-00.txt
 Information Model of Control-Plane and User-Plane separation BNG
 
 draft-cuspdt-rtgwg-cu-separation-infor-model-00.txt
 Date: 26/02/2018
 Authors: Zitao Wang, Rong Gu, Victor Lopezalvarez, Sujun Hu
 Working Group: Individual Submissions (none)
 Formats: txt
To improve network resource utilization and reduce the operation expense, the Control-Plane and User-Plane separation conception is raised [TR-384]. This document describes the information model for the interface between Control-Plane and User-Plane separation BNG. This information model may involve both control channel interface and configuration channel interface. The interface for control channel allows the Control-Plane to send several flow tables to the User- Plane, such as user's information table, user's interface table, and user's QoS table, etc. And it also allows the User-Plane to report the resources and statistics information to the Control-Plane. The interface for configuration channel is in charge of the version negotiation of protocols between the Control-Plane and User-Plane, the configuration for devices of Control-Plane and User-Plane, and the reports of User-Plane's capabilities, etc. The information model defined in this document enables defining a standardized data model. Such a data model can be used to define an interface to the CU separation BNG.
    
draft-cuspdt-rtgwg-cusp-requirements-01.txt
 Requirements for Control Plane and User Plane Separated BNG Protocol
 
 draft-cuspdt-rtgwg-cusp-requirements-01.txt
 Date: 26/02/2018
 Authors: Sujun Hu, Rong Gu, Victor Lopezalvarez, Jun Song, Zitao Wang
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces the Control Plane and User Plane separated BNG architecture and defines a set of associated terminology. What's more, this document focuses on defining a set of protocol requirements for the BNG-CP and BNG-UPs communication in the Control Plane and User Plane Separated BNG.
    
draft-da-ipwave-advanced-features-01.txt
 Advanced Features for Vehicular Networks: Grouping and Socialization
 
 draft-da-ipwave-advanced-features-01.txt
 Date: 28/10/2017
 Authors: Bin Da, Antonio Iera, Claudia Campolo
 Working Group: Individual Submissions (none)
 Formats: txt
For future vehicular networks, some advanced features might be needed to facilitate use cases as platooning, proximity service awareness, autonomous driving and so forth. Thus, this draft intends to present two functions, known as vehicular grouping and socialization, for enabling some future-oriented use cases. These two functions could be built upon cross-layer identifiers, such as MAC, IP, and ID, which also have potential to formulate more value-added services for future vehicular networks.
    
draft-daveor-cgn-logging-04.txt
 Approaches to Address the Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
 
 draft-daveor-cgn-logging-04.txt
 Date: 12/04/2018
 Authors: David O'Reilly
 Working Group: Individual Submissions (none)
 Formats: xml txt
The use of large-scale IP address sharing technologies (commonly known as "Carrier-Grade NAT" and "A+P") presents a challenge for law enforcement agencies due to the fact that incoming source port information is not routinely logged by Internet-facing servers. The absence of this information means that it is becoming increasingly difficult for law enforcement agencies to identify suspects in criminal activity online. This document considers the reasons why source port information is not routinely logged by Internet-facing servers and makes recommendations to help improve the situation. A deployment maturity model has been developed and a study of the support for logging incoming source port information in common server software is also presented.
    
draft-dawes-sipcore-mediasec-parameter-07.txt
 Security Mechanism Names for Media
 
 draft-dawes-sipcore-mediasec-parameter-07.txt
 Date: 13/11/2017
 Authors: Peter Dawes
 Working Group: Individual Submissions (none)
 Formats: txt
Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is described in [2]. This document adds the capability to distinguish security mechanisms that apply to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label such security mechanisms.
    
draft-dawkins-panrg-what-not-to-do-00.txt
 Path Aware Networking: A Bestiary of Roads Not Taken
 
 draft-dawkins-panrg-what-not-to-do-00.txt
 Date: 19/03/2018
 Authors: Spencer Dawkins
 Working Group: Individual Submissions (none)
 Formats: txt
At the first meeting of the proposed Path Aware Networking Research Group, Oliver Bonaventure led a discussion of our mostly-unsuccessful attempts to exploit Path Awareness to achieve a variety of goals, over the past decade. At the end of that discussion, the research group agreed to catalog and analyze these ideas, to extract lessons for network researchers. This document contains that catalog and analysis.
    
draft-dawra-idr-bgp-sr-service-chaining-02.txt
 BGP Control Plane Extensions for Segment Routing based Service Chaining
 
 draft-dawra-idr-bgp-sr-service-chaining-02.txt
 Date: 04/01/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
The BGP Control Plane for the SR service-chaining solution is consistent with the BGP Control Plane for the topological Segment Routing Traffic Engineering (SR-TE) solution. o BGP Link-State(BGP-LS) address-family/sub-address-family[RFC7752] is used to discover service and topological characteristics from the network. o SR-TE policies[I-D.ietf-idr-segment-routing-te-policy] instantiate source-routed policies that may mix service and topological segments.
    
draft-dawra-idr-bgpls-srv6-ext-03.txt
 BGP Link State extensions for IPv6 Segment Routing(SRv6)
 
 draft-dawra-idr-bgpls-srv6-ext-03.txt
 Date: 05/03/2018
 Authors: Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Mach Chen, daniel.bernier@bell.ca, Jim Uttaro, Bruno Decraene, Hani Elmalky
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing IPv6 (SRv6) allows for a flexible definition of end- to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by the various protocols such as BGP, ISIS and OSPFv3. BGP Link-state (BGP-LS) address-family solution for SRv6 is similar to BGP-LS for SR for MPLS dataplane. This draft defines extensions to the BGP-LS to advertise SRv6 Segments along with there functions and other attributes via BGP.
    
draft-dawra-idr-srv6-vpn-03.txt
 BGP Signaling of IPv6-Segment-Routing-based VPN Networks
 
 draft-dawra-idr-srv6-vpn-03.txt
 Date: 26/12/2017
 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
 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-00.txt
 Multipath Extension for QUIC
 
 draft-deconinck-quic-multipath-00.txt
 Date: 05/03/2018
 Authors: Quentin Coninck, Olivier Bonaventure
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes extensions to the QUIC protocol to enable the usage of multiple paths over a single connection. Those changes remain compliant with the current single-path QUIC design. They allow devices to benefit from multiple network paths while preserving the privacy features of QUIC.
    
draft-defoy-coms-subnet-interconnection-03.txt
 Interconnecting (or Stitching) Network Slice Subnets
 
 draft-defoy-coms-subnet-interconnection-03.txt
 Date: 04/03/2018
 Authors: Xavier de Foy, Akbar Rahman, A. Galis, kiran.makhijani@huawei.com, Li Qiang, Shunsuke Homma, Pedro Martinez-Julia
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the network slice (NS) subnet as a general management plane concept that augments a baseline network slice model with management attributes and operations enabling interconnections (or stitching) between network slices. The description of NS subnet interconnections is technology agnostic following the approach of the COMS information model. Some interconnections may be implemented using the interplay between management plane and gateways in the data plane.
    
draft-defoy-mptcp-considerations-for-5g-00.txt
 Considerations for MPTCP operation in 5G
 
 draft-defoy-mptcp-considerations-for-5g-00.txt
 Date: 02/03/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 systems, and may benefit from some form of adaptation of MPTCP implementations and/or the 5G system.
    
draft-dejong-remotestorage-10.txt
 remoteStorage
 
 draft-dejong-remotestorage-10.txt
 Date: 04/12/2017
 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-dekok-radext-request-authenticator-03.txt
 Correlating requests and replies in the Remote Authentication Dial In User Service (RADIUS) Protocol via the Request Authenticator.
 
 draft-dekok-radext-request-authenticator-03.txt
 Date: 04/12/2017
 Authors: Alan DeKok
 Working Group: Individual Submissions (none)
 Formats: txt
RADIUS uses a one-octet Identifier field to correlate requests and responses, which limits clients to 256 "in flight" packets per connection. This document removes that limitation by allowing Request Authenticator to be used as an additional field for identifying packets. The capability is negotiated on a per- connection basis, and requires no changes to the RADIUS packet format, attribute encoding, or data types.
    
draft-deshmukh-teas-rsvp-rmr-extension-00.txt
 RSVP Extensions for RMR
 
 draft-deshmukh-teas-rsvp-rmr-extension-00.txt
 Date: 13/02/2018
 Authors: Abhishek Deshmukh, Kireeti Kompella
 Working Group: Individual Submissions (none)
 Formats: txt xml
Rings are the most common topology in access and aggregation networks. However, the use of MPLS as the transport protocol for rings is very limited today. draft-ietf-mpls-rmr-02 describes a mechanism to handle rings efficiently using MPLS. This document describes the extensions to the RSVP protocol for signaling MPLS label switched paths in rings.
    
draft-detchart-nwcrg-tetrys-04.txt
 Tetrys,an On-the-Fly Network Coding protocol
 
 draft-detchart-nwcrg-tetrys-04.txt
 Date: 05/03/2018
 Authors: jonathan.detchart@isae.fr, Emmanuel Lochin, Jerome Lacan, Vincent Roca
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes Tetrys, an On-The-Fly Network Coding (NC) protocol that can be used to transport delay and loss sensitive data over a lossy network. Tetrys can recover from erasures within a RTT- independent delay, thanks to the transmission of coded packets. It can be used for both unicast, multicast and anycast communications.
    
draft-dharini-ccamp-dwdm-if-param-yang-04.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-04.txt
 Date: 01/03/2018
 Authors: Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or by in phase of specification by) ITU-T G.698.2 [ITU.G698.2] or any other ITU-T recommendation. More context about the state of the Coherent transceivers is described in draft-many- coherent-DWDM-if-control. Use cases are described in RFC7698 The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of a multi-vendor IaDI optical link.
    
draft-dharinigert-ccamp-dwdm-if-lmp-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-dharinigert-ccamp-dwdm-if-lmp-06.txt
 Date: 01/03/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-dhody-pce-stateful-pce-interdomain-06.txt
 Stateful Path Computation Element (PCE) Inter-domain Considerations
 
 draft-dhody-pce-stateful-pce-interdomain-06.txt
 Date: 02/03/2018
 Authors: Dhruv Dhody, Xian Zhang
 Working Group: Individual Submissions (none)
 Formats: xml txt
A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering path calculations for its associated Path Computation Clients (PCCs). Furthermore, PCEs are used to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains. This document describes general considerations for the deployment of stateful PCE(s) in inter-domain scenarios including inter-area and inter-AS. The inter-layer considerations will be described in a separate document. This document does not specify any extensions to PCEP.
    
draft-dhody-pce-stateful-pce-optional-00.txt
 Extension for Stateful PCE to allow Optional Processing of PCEP Objects.
 
 draft-dhody-pce-stateful-pce-optional-00.txt
 Date: 01/03/2018
 Authors: Dhruv Dhody, Stephane Litkowski
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a mechanism to mark some Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints.
    
draft-dhody-pce-stateful-pce-vendor-04.txt
 Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for stateful PCE.
 
 draft-dhody-pce-stateful-pce-vendor-04.txt
 Date: 02/03/2018
 Authors: Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). RFC 7470 defines a facility to carry vendor-specific information in PCEP. This document extends this capability for the stateful PCE model.
    
draft-dhodylee-pce-pcep-ls-10.txt
 PCEP Extension for Distribution of Link-State and TE Information.
 
 draft-dhodylee-pce-pcep-ls-10.txt
 Date: 04/03/2018
 Authors: Dhruv Dhody, Young Lee, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: txt xml
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state (LS) routing protocol supporting traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information.
    
draft-dickinson-bcp-op-00.txt
 Recommendations for DNS Privacy Service Operators
 
 draft-dickinson-bcp-op-00.txt
 Date: 05/03/2018
 Authors: Sara Dickinson, Roland van Rijswijk-Deij, Allison Mankin
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents operational, policy and security considerations for DNS operators who choose to offer DNS Privacy services including, but not limited to, DNS-over-TLS [RFC7858]. This document also presents a framework to assist writers of DNS Privacy Policy and Practices Statements (analogous to DNS Security Extensions (DNSSEC) Policies and DNSSEC Practice Statements described in [RFC6841]).
    
draft-ding-opsawg-wavelength-use-case-00.txt
 Network Data Use Case for Wavelength Division Service
 
 draft-ding-opsawg-wavelength-use-case-00.txt
 Date: 30/10/2017
 Authors: ding xiaojian, Will LIU, Chen Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes use cases that demonstrate the applicability of network data to evaluate the performance of wavelength division service. The objective of this draft is not to cover the wavelength division service in detail. Rather, the intention is to illustrate the requirements of network data used to evaluate the performance of wavelength division service. General characteristics of network data and two typical use cases are presented in this document to demonstrate the different application scenarios of network data in wavelength division service.
    
draft-ding-rtgwg-arp-yang-model-01.txt
 YANG Data Model for ARP
 
 draft-ding-rtgwg-arp-yang-model-01.txt
 Date: 28/02/2018
 Authors: ding xiaojian, Feng Zheng, Robert Wilton
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a specification of one YANG module and one submodule. Together they form the Address Resolution Protocol (ARP) data model that performs as a guideline for configuring ARP capabilities on a system. It is intended these modules be used by service providers who manipulate devices from different vendors in a standard way.
    
draft-divination-cfapi-00.txt
 An API For Calendar-Based Fortune Heuristics Services
 
 draft-divination-cfapi-00.txt
 Date: 22/03/2018
 Authors: Gabriel Destiny, Charise Luck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a JSON HTTP API for online services that provide calendar-based fortune heuristics.
    
draft-dm-net2cloud-problem-statement-01.txt
 Seamless Interconnect Underlay to Cloud Overlay Problem Statement
 
 draft-dm-net2cloud-problem-statement-01.txt
 Date: 05/03/2018
 Authors: Linda Dunbar, Andrew Malis, Christian Jacquenet, Mehmet Toy
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes common approaches deployed by enterprises for interconnection of workloads & applications hosted in Cloud DCs with 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-dm-vpn-ext-to-cloud-dc-gap-analysis-00.txt
 Gap Analysis of VPN Extension to Dynamic Cloud Data Center
 
 draft-dm-vpn-ext-to-cloud-dc-gap-analysis-00.txt
 Date: 30/10/2017
 Authors: Linda Dunbar, Andrew Malis
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the technological gaps necessary to enable existing VPN to securely connect to dynamic workloads hosted in cloud data centers when the cloud DC doesn't have the VPN PEs co- located [dynamic-cloudDC].
    
draft-dnoveck-nfsv4-rpcrdma-rtissues-05.txt
 Issues Related to RPC-over-RDMA Internode Round Trips
 
 draft-dnoveck-nfsv4-rpcrdma-rtissues-05.txt
 Date: 22/02/2018
 Authors: David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
As currently designed and implemented, the RPC-over-RDMA protocol requires use of multiple internode round trips to process some common operations. For example, NFS WRITE operations require use of three internode round trips. This document looks at this issue and discusses what can and what should be done to address it, both within the context of an extensible version of RPC-over-RDMA and potentially outside that framework.
    
draft-dnoveck-nfsv4-rpcrdma-rtrext-03.txt
 RPC-over-RDMA Extensions to Reduce Internode Round-trips
 
 draft-dnoveck-nfsv4-rpcrdma-rtrext-03.txt
 Date: 05/12/2017
 Authors: David Noveck
 Working Group: Individual Submissions (none)
 Formats: xml txt
It is expected that a future version of the RPC-over-RDMA transport will allow protocol extensions to be defined. This would provide for the specification of OPTIONAL features allowing participants who implement such features to cooperate as specified by that extension, while still interoperating with participants who do not support that extension. A particular extension is described herein, whose motivation is to reduce the latency due to inter-node round-trips needed to effect operations which involve direct data placement or which transfer RPC messages longer than the fixed inline buffer size limit.
    
draft-dold-payto-01.txt
 The 'payto' URI scheme for payments
 
 draft-dold-payto-01.txt
 Date: 07/04/2018
 Authors: Florian Dold, Christian Grothoff
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the 'payto' Uniform Resource Identifier (URI) scheme for specifying payments.
    
draft-dolson-transport-middlebox-02.txt
 An Inventory of Transport-centric Functions Provided by Middleboxes
 
 draft-dolson-transport-middlebox-02.txt
 Date: 02/03/2018
 Authors: David Dolson, Juho Snellman, Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document summarizes benefits that operators perceive to be provided by intermediary devices that provide functions apart from normal IP forwarding. Such intermediary devices are often called "middleboxes". RFC3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application-layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets. A primary goal of this document is to provide information to working groups developing new transport protocols, to aid understanding of what might be gained or lost by design decisions that may affect (or be affected by) middlebox operation.
    
draft-dong-idr-node-target-ext-comm-00.txt
 BGP Extended Community for Identifying the Target Node
 
 draft-dong-idr-node-target-ext-comm-00.txt
 Date: 05/03/2018
 Authors: Jie Dong, Shunwan Zhuang, Gunter Van de Velde
 Working Group: Individual Submissions (none)
 Formats: txt
BGP has been used to distribute different types of routing and policy information in the network. In some cases, the information distributed may be only intended for one or several particular receiving BGP nodes in the network. BGP does not have a general mechanism for designating the receiving node of the routing information. This document defines a new type of BGP extended community called "Node Target". The mechanism and of using the Node Target extended community to steer BGP route distribution to particular BGP nodes is specified.
    
draft-dong-rtgwg-enhanced-vpn-protocol-00.txt
 Protocol Considerations for Enhanced VPN
 
 draft-dong-rtgwg-enhanced-vpn-protocol-00.txt
 Date: 30/10/2017
 Authors: Jie Dong, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the candidate protocol mechanisms which may be used to meet the requirements of enhanced virtual private networks (VPN+). The gaps and limitations of existing mechanisms are analyzed, then a proposed mechanism is briefly described. The proposed mechanism can be used to achieve network slicing to meet the stringent requirement of emerging 5G services, but it can also be useful in other general network scenarios.
    
draft-dong-sacm-nid-infra-security-baseline-00.txt
 The Data Model of Network Infrastructure Device Infrastructure Layer Security Baseline
 
 draft-dong-sacm-nid-infra-security-baseline-00.txt
 Date: 15/01/2018
 Authors: Yue Dong, Liang Xia
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is one of the companion documents which describes the infrastructure layer security baseline YANG output for network infrastructure devices. The infrastructure layer security baseline includes all the fundamental security capabilities/functions about the device itself, which may also be provided by the device to the upper layer applications as a secure environment. In this particular document, the integrity measurement, cryptography security, secure key management, and secure certificate management are summarized to generate the data model.
    
draft-dong-spring-sr-for-enhanced-vpn-00.txt
 Segment Routing for Enhanced VPN Service
 
 draft-dong-spring-sr-for-enhanced-vpn-00.txt
 Date: 05/03/2018
 Authors: Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka
 Working Group: Individual Submissions (none)
 Formats: txt
Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it to support the needs of new applications, particularly applications that are associated with 5G services. These applications require better isolation and have more stringent performance requirements than can be provided with overlay VPNs. The characteristics of an enhanced VPN as perceived by its tenant needs to be comparable to those of a dedicated private network. This requires tight integration between the overlay VPN and the underlay network resources in a scalable manner. An enhanced VPN may form the underpin of 5G network slicing, but will also be of use in its own right. This document describes the use of segment routing based mechanisms to provide the enhanced VPN service with dedicated underlay network resources.
    
draft-dorfner-core-simplemetadata-00.txt
 SimpleMetadata: An interoperable format for sharing metadata
 
 draft-dorfner-core-simplemetadata-00.txt
 Date: 16/04/2018
 Authors: Ralf Dorfner
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a container format for storing serializable metadata. It shall provide the possibility to store and share any kind of metadata, including encryption support. The idea is to create an open, universal and interoperable standard for storing and distributing every kind of metadata independent from media type or file format.
    
draft-dreibholz-ipv4-flowlabel-27.txt
 An IPv4 Flowlabel Option
 
 draft-dreibholz-ipv4-flowlabel-27.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6.
    
draft-dreibholz-mptcp-nornet-experience-04.txt
 MPTCP Experiences in the NorNet Testbed
 
 draft-dreibholz-mptcp-nornet-experience-04.txt
 Date: 29/10/2017
 Authors: Thomas Dreibholz, Simone Ferlin, ozgu@simula.no, Ahmed Elmokashfi, Ioana Livadariu, Xing Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document collects some experiences of Multi-Path TCP (MPTCP) evaluations in the NorNet testbed.
    
draft-dreibholz-rserpool-applic-distcomp-24.txt
 Applicability of Reliable Server Pooling for Real-Time Distributed Computing
 
 draft-dreibholz-rserpool-applic-distcomp-24.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools.
    
draft-dreibholz-rserpool-applic-mobility-23.txt
 Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility
 
 draft-dreibholz-rserpool-applic-mobility-23.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Jobin Pulinthanath
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool).
    
draft-dreibholz-rserpool-asap-hropt-22.txt
 Handle Resolution Option for ASAP
 
 draft-dreibholz-rserpool-asap-hropt-22.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Handle Resolution option for the ASAP protocol.
    
draft-dreibholz-rserpool-delay-21.txt
 Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling
 
 draft-dreibholz-rserpool-delay-21.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Xing Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling.
    
draft-dreibholz-rserpool-enrp-takeover-19.txt
 Takeover Suggestion Flag for the ENRP Handle Update Message
 
 draft-dreibholz-rserpool-enrp-takeover-19.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Xing Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol.
    
draft-dreibholz-rserpool-nextgen-ideas-09.txt
 Ideas for a Next Generation of the Reliable Server Pooling Framework
 
 draft-dreibholz-rserpool-nextgen-ideas-09.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document collects some idea for a next generation of the Reliable Server Pooling framework.
    
draft-dreibholz-rserpool-score-22.txt
 Reliable Server Pooling (RSerPool) Bakeoff Scoring
 
 draft-dreibholz-rserpool-score-22.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Michael Tuexen
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.
    
draft-dreibholz-taps-neat-socketapi-02.txt
 NEAT Sockets API
 
 draft-dreibholz-taps-neat-socketapi-02.txt
 Date: 29/10/2017
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality.
    
draft-dreibholz-tsvwg-sctp-nextgen-ideas-07.txt
 Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)
 
 draft-dreibholz-tsvwg-sctp-nextgen-ideas-07.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment.
    
draft-dreibholz-tsvwg-sctpsocket-multipath-16.txt
 SCTP Socket API Extensions for Concurrent Multipath Transfer
 
 draft-dreibholz-tsvwg-sctpsocket-multipath-16.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Martin Becke, Hakim Adhari
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions.
    
draft-dreibholz-tsvwg-sctpsocket-sqinfo-16.txt
 Sender Queue Info Option for the SCTP Socket API
 
 draft-dreibholz-tsvwg-sctpsocket-sqinfo-16.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Robin Seggelmann, Martin Becke
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an extension to the SCTP sockets API for querying information about the sender queue.
    
draft-dreibholz-vnfpool-rserpool-applic-07.txt
 The Applicability of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL)
 
 draft-dreibholz-vnfpool-rserpool-applic-07.txt
 Date: 04/03/2018
 Authors: Thomas Dreibholz, Michael Tuexen, Melinda Shore, Ning Zong
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes the application of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL).
    
draft-dschinazi-ipsecme-sa-init-privacy-addition-00.txt
 Privacy Addition to the Internet Key Exchange Protocol Version 2 (IKEv2) IKE_SA_INIT Exchange
 
 draft-dschinazi-ipsecme-sa-init-privacy-addition-00.txt
 Date: 05/03/2018
 Authors: David Schinazi
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Internet Key Exchange Protocol version 2 (IKEv2) provides strong security and privacy properties to both endpoints once they have authenticated each other. However, before an endpoint has validated the peer's AUTH payload, it could be divulging information to an untrusted host. An example of such information is the Identification payload of the initiator. Another example is the fact that a host is running an IKEv2 responder. This document introduces a new "Initialization Authentication Code" notify payload that can be included in IKE_SA_INIT messages to increase their trustworthiness. This new protection is meant to be used in addition to current IKEv2 mechanisms and is not meant to replace the AUTH payload in any way.
    
draft-dt-iasa20-proposal-00.txt
 Proposed Structure of the IETF Administrative Organization
 
 draft-dt-iasa20-proposal-00.txt
 Date: 05/04/2018
 Authors: Joseph Hall, Brian Haberman, Jari Arkko, Leslie Daigle, Jason Livingood, Eric Rescorla
 Working Group: Individual Submissions (none)
 Formats: txt xml
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the intervening years, the needs of the IETF have evolved in ways that require changes to its administrative structure. The IETF Chair started an effort in November of 2016 to begin the process of changing the IETF administrative structure, starting with a set of virtual workshops to get input from the IETF community, and then encompassing a series of BOF sessions at IETF meetings to define the problem, develop requirements, explore potential options for changes, and a Design Team - the authors of this document - that would make recommendations. The purpose of this document is to collect all of the various materials that have lead up to the Design Team recommendation that IETF be a Disregarded Limited Liability Company (LLC) of the Internet Society.
    
draft-dt-rtgwg-dcrouting-requirements-00.txt
 Requirements for the DataCenter Routing
 
 draft-dt-rtgwg-dcrouting-requirements-00.txt
 Date: 30/10/2017
 Authors: Jeff Tantsura, Dmitry Afanasiev, Keyur Patel, Petr Lapukhov, Tony Przygienda, Russ White, Yingzhen Qu, Jim Uttaro
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes list of functional requirments towards a Routing Protocol for Data Center Networks.
    
draft-duchene-spring-srv6-socket-00.txt
 A socket API to control IPv6 Segment Routing
 
 draft-duchene-spring-srv6-socket-00.txt
 Date: 05/03/2018
 Authors: Fabien Duchene, Olivier Bonaventure
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a socket API to allow applications to control the utilisation of IPv6 Segment Routing (SRv6).
    
draft-dugeon-pce-stateful-interdomain-00.txt
 PCEP Extension for Stateful Inter-Domain Tunnels
 
 draft-dugeon-pce-stateful-interdomain-00.txt
 Date: 27/10/2017
 Authors: Olivier Dugeon, Julien Meuric
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) working group (WG) has produced a set of RFCs to standardize the behavior of the Path Computation Element as a tool to help MPLS-TE, GMPLS LSP tunnels and Segment Routing paths placement. This also include the ability to compute inter-domain LSPs or Segment Routing path following a distributed or hierarchical approach. In complement to the original stateless mode, a stateful mode has been added. In particular, the new PCInitiate message allows a PCE to directly ask a PCC to setup an MPLS-TE, GMPLS LSP tunnel or a Segment Routing path. However, once computed, the inter-domain LSPs or Segment Routing path are hard to setup in the underlying network. Especially, in operational network, RSVP-TE signaling is not enable between AS border routers. But, such RSVP-TE signaling is mandatory to setup contiguous LSP tunnels or to stitch or nest independent LSP tunnels to form the end-to-end inter-domain paths. This document proposes to combine a Backward Recursive or Hierarchical method with PCInitiate message to setup independent paths per domain, and combine these different paths together in order to operated 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-00.txt
 QUIC-LB: Using Load Balancers to Generate QUIC Connection IDs
 
 draft-duke-quic-load-balancers-00.txt
 Date: 12/02/2018
 Authors: Martin Duke
 Working Group: Individual Submissions (none)
 Formats: txt
QUIC connection IDs allow continuation of connections across address/port 5-tuple changes, and can store routing information for stateless or low-state layer 4 load balancers. They are also meant to prevent linkability of connections across deliberate address migration through the use of protected communications between client and server. This creates issues for load-balancing intermediaries. This specification standardizes the communication between load balancers and servers to overcome these issues in a protocol called QUIC-LB.
    
draft-dukes-lisp-colored-engineered-underlays-01.txt
 LISP Colored Engineered Underlays
 
 draft-dukes-lisp-colored-engineered-underlays-01.txt
 Date: 18/12/2017
 Authors: Darren Dukes, Jesus Arango
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a LISP control plane extension that associates a locator record with a color value that can be used to select an engineered underlay path to the corresponding RLOC.
    
draft-dukes-spring-mtu-overhead-analysis-00.txt
 Comparative Analysis of MTU overhead in the context of SPRING
 
 draft-dukes-spring-mtu-overhead-analysis-00.txt
 Date: 18/03/2018
 Authors: Darren Dukes, Clarence Filsfils, Pablo Camarillo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides an apples-to-apples comparative analysis of MTU overhead in the context of SPRING.
    
draft-dukes-sr-for-sdwan-00.txt
 SR For SDWAN: VPN with Underlay SLA
 
 draft-dukes-sr-for-sdwan-00.txt
 Date: 27/10/2017
 Authors: Darren Dukes, Clarence Filsfils, Gaurav Dawra, Pablo Camarillo, Francois Clad, Stefano Salsano
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
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-misp-core-format-04.txt
 MISP core format
 
 draft-dulaunoy-misp-core-format-04.txt
 Date: 10/04/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP core format used to exchange indicators and threat information between MISP (Malware Information and threat Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms.
    
draft-dulaunoy-misp-galaxy-format-01.txt
 MISP galaxy format
 
 draft-dulaunoy-misp-galaxy-format-01.txt
 Date: 01/03/2018
 Authors: Alexandre Dulaunoy, Andras Iklody, Deborah Servili
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository [MISP-G] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
    
draft-dulaunoy-misp-object-template-format-01.txt
 MISP object template format
 
 draft-dulaunoy-misp-object-template-format-01.txt
 Date: 10/04/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates [MISP-O] is available and relies on the MISP object reference format.
    
draft-dulaunoy-misp-taxonomy-format-04.txt
 MISP taxonomy format
 
 draft-dulaunoy-misp-taxonomy-format-04.txt
 Date: 28/11/2017
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP taxonomy format which describes a simple JSON format to represent machine tags (also called triple tags) vocabularies. A public directory of common vocabularies MISP taxonomies is available and relies on the MISP taxonomy format. MISP taxonomies are used to classify cyber security events, threats or indicators.
    
draft-dupont-dnsop-rfc2845bis-01.txt
 Secret Key Transaction Authentication for DNS (TSIG)
 
 draft-dupont-dnsop-rfc2845bis-01.txt
 Date: 05/03/2018
 Authors: Francis Dupont, Stephen Morris
 Working Group: Domain Name System Operations (dnsop)
 Formats: txt xml
This protocol allows for transaction level authentication using shared secrets and one way hashing. It can be used to authenticate dynamic updates as coming from an approved client, or to authenticate responses as coming from an approved name server. No provision has been made here for distributing the shared secrets: it is expected that a network administrator will statically configure name servers and clients using some out of band mechanism. This document includes revised original TSIG specifications (RFC2845) and its extension for HMAC-SHA (RFC4635).
    
draft-duquennoy-6tisch-asf-01.txt
 6TiSCH Autonomous Scheduling Function (ASF)
 
 draft-duquennoy-6tisch-asf-01.txt
 Date: 02/03/2018
 Authors: Simon Duquennoy, Xavier Vilajosana, Thomas Watteyne
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a Scheduling Function called "ASF": the 6TiSCH Autonomous Scheduling Function. With ASF, nodes maintain their TSCH schedule based on local neighborhood knowledge, without any signaling after association. Hashes of the nodes' MAC address are used to deterministically derive the [slotOffset,channelOffset] location of cells in the TSCH schedule. Different traffic types (e.g. TSCH EB, RPL DIO, UDP etc.) are assigned to distinct slotframes, for isolation and flexible dimensioning. This approach provides over-provisioned schedules with low maintenance, in pursuit for simplicity rather than optimality.
    
draft-durand-object-exchange-00.txt
 DNS Object Exchange
 
 draft-durand-object-exchange-00.txt
 Date: 19/12/2017
 Authors: Alain Durand, Ray Bellis
 Working Group: Individual Submissions (none)
 Formats: txt xml
Abstract This document defines an RR type to implement an architecture for the exchange of digitial objects using identifiers stored within the DNS.
    
draft-eastlake-bess-enhance-evpn-all-active-00.txt
 EVPN All Active Usage Enhancement
 
 draft-eastlake-bess-enhance-evpn-all-active-00.txt
 Date: 05/03/2018
 Authors: Donald Eastlake, Zhenbin Li, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: txt
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links.
    
draft-eastlake-bess-evpn-vxlan-bypass-vtep-00.txt
 EVPN All Active Usage Enhancements
 
 draft-eastlake-bess-evpn-vxlan-bypass-vtep-00.txt
 Date: 05/03/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-14.txt
 The FNV Non-Cryptographic Hash Algorithm
 
 draft-eastlake-fnv-14.txt
 Date: 08/12/2017
 Authors: Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen
 Working Group: Individual Submissions (none)
 Formats: txt
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community.
    
draft-eastlake-rfc6931bis-xmlsec-uris-07.txt
 Additional XML Security Uniform Resource Identifiers (URIs)
 
 draft-eastlake-rfc6931bis-xmlsec-uris-07.txt
 Date: 04/04/2018
 Authors: Donald Eastlake
 Working Group: Individual Submissions (none)
 Formats: txt
This document updates and corrects the IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document corrrects three errata against and obsoletes RFC 6931. The intent is to keep this draft alive while it accumulates updates until it seems reasonable to publish the next version.
    
draft-eastlake-sfc-nsh-ecn-support-00.txt
 Network Service Header (NSH) Explicit Congestion Notification (ECN) Support
 
 draft-eastlake-sfc-nsh-ecn-support-00.txt
 Date: 05/03/2018
 Authors: Donald Eastlake, Bob Briscoe
 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. This can improve network efficiency through better congestion control without packet drops. This document specifies ECN support within Service Function Chaining (SFC) domains through use of the Network Service Header (NSH).
    
draft-eckert-anima-grasp-dnssd-00.txt
 DNS-SD compatible service discovery in GRASP
 
 draft-eckert-anima-grasp-dnssd-00.txt
 Date: 30/10/2017
 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-bier-te-frr-03.txt
 Protection Methods for BIER-TE
 
 draft-eckert-bier-te-frr-03.txt
 Date: 05/03/2018
 Authors: Toerless Eckert, Gregory Cauchie, Wolfgang Braun, Michael Menth
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes protection methods for the BIER-TE architecture [I-D.ietf-bier-te-arch]. These include 1+1 (live-live) path/tree [RFC7431] redundancy, 1:1 path/tree protection, as well as fast reroute (FRR) methods. The latter may protect against link and/ or node failures and leverage infrastructure tunnels, BIER-in-BIER encapsulation, or header modification for implementation. In particular, this memo describes FRR for BIER-TE in detail. FRR for BIER-TE requires support from the BIER-TE controller and the BFRs that are attached to a link/adjacency for which FRR protection is desired. FRR relies on the BIER header described in [RFC8279] which is also used by BIER-TE. It does not require extensions or modifications to existing BIER-TE tables. However, the presented FRR procedures need some additional forwarding plane logic on the BFR. An additional table is needed that carries information about pre- computed backup paths. When a failure is detected, the information from this table is used to modify the bitstring in the BIER header before forwarding a packet over a backup path. To prevent undesired packet duplication, packets should be tunneled on the backup paths.
    
draft-eckert-teas-bier-te-framework-00.txt
 Framework for Traffic Engineering with BIER-TE forwarding (Bit Index Explicit Replication with Traffic Engineering)
 
 draft-eckert-teas-bier-te-framework-00.txt
 Date: 05/03/2018
 Authors: Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt xml
BIER-TE is an application-state free, (loose) source routed multicast forwarding method where every hop and destination is identified via bits in a bitstring of the data packets. It is described in [I-D.ietf-bier-te-arch]. BIER-TE is a variant of [RFC8279] in support of such explicit path engineering. This document described the traffic engineering control framework for use with the BIER-TE forwarding plane: How to enable the ability to calculate paths and integrate this forwarding plane into an overall TE solution.
    
draft-eddy-tsvwg-saratoga-tfrc-12.txt
 TFRC-based Congestion Control for Saratoga
 
 draft-eddy-tsvwg-saratoga-tfrc-12.txt
 Date: 17/12/2017
 Authors: Wesley Eddy, Lloyd Wood, Will Ivancic
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the use of TCP-Friendly Rate Control (TFRC) with the Saratoga data transfer protocol. The necessary conventions that a Saratoga sender and receiver implementation must follow if they wish to enable the use of TFRC are described.
    
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-egge-netvc-cfl-01.txt
 Chroma From Luma Intra Prediction for NETVC
 
 draft-egge-netvc-cfl-01.txt
 Date: 14/11/2017
 Authors: Nathan Egge, Luc Trudeau, David Barr
 Working Group: Individual Submissions (none)
 Formats: xml txt
Chroma from luma (CfL) prediction is a new and promising chroma-only intra predictor that models chroma pixels as a linear function of the coincident reconstructed luma pixels. In this document, we propose the CfL predictor adopted in Alliance Video 1 (AV1) to the NETVC working group. The proposed CfL distinguishes itself from prior art not only by reducing decoder complexity, but also by producing more accurate predictions. On average, CfL reduces the BD-rate, when measured with CIEDE2000, by 5% for still images and 2% for video sequences.
    
draft-elkins-brickmortar-architecture-00.txt
 Common Network Architecture for Brick and Mortar Enterprises
 
 draft-elkins-brickmortar-architecture-00.txt
 Date: 23/10/2017
 Authors: Nalini Elkins, mackermann@bcbsm.com
 Working Group: Individual Submissions (none)
 Formats: txt
The network architecture and topology for "brick and mortar" enterprises differ in significant aspects from those of Internet- based companies. This has implications for protocol implementations.
    
draft-epc-architecture-00.txt
 An Equipment Parameter Control Architecture
 
 draft-epc-architecture-00.txt
 Date: 03/01/2018
 Authors: Boyuan Yan, Yongli Zhao, weiw@bupt.edu.cn, Xiaosong Yu, Jie Zhang
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This memo specifies an equipment parameter control architecture based on Software Defined Networking (SDN). This architecture can be used to adjust equipment parameter to improve equipment performance in various types of networks, for example, optical network, wireless network and so on.
    
draft-erdtman-jose-cleartext-jwe-00.txt
 Cleartext JSON Web Encryption (JWE)
 
 draft-erdtman-jose-cleartext-jwe-00.txt
 Date: 05/03/2018
 Authors: Samuel Erdtman, Anders Rundgren, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: xml txt
Cleartext JSON Web Encryption (JWE) is a means of representing encrypted content as a JSON object without representing JSON values to be integrity protected in a non-JSON representation, such as base64url-encoded JSON. The integrity protection calculation for the authenticated encryption performed uses the predictable JSON serialization defined in ECMAScript version 6. Cleartext JWE builds on the JWE, JWA, and JWK specifications, reusing data structures and semantics from these specifications, where applicable.
    
draft-erdtman-jose-cleartext-jws-00.txt
 Cleartext JSON Web Signature (JWS)
 
 draft-erdtman-jose-cleartext-jws-00.txt
 Date: 05/03/2018
 Authors: Samuel Erdtman, Anders Rundgren, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: txt xml
Cleartext JSON Web Signature (JWS) is a means of signing JSON objects directly without representing the JSON to be signed in a non-JSON representation, such as base64url-encoded JSON. The signature and information about the signature is added to the JSON object when it is signed. The signature calculation for signing the JSON object uses the predictable JSON serialization defined in ECMAScript version 6. Cleartext JWS builds on the JWS, JWA, and JWK specifications, reusing data structures and semantics from these specifications, where applicable.
    
draft-erdtman-oauth-rpcc-00.txt
 Raw-Public-Key and Pre-Shared-Key as OAuth client credentials
 
 draft-erdtman-oauth-rpcc-00.txt
 Date: 21/11/2017
 Authors: Ludwig Seitz, Samuel Erdtman, Marco Tiloca
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes Transport Layer Security (TLS) authentication using Raw-Public-Key and Pre-Shared-Key as new mechanisms for OAuth client authentication. Although defined for TLS the mechanisms are equally applicable for DTLS.
    
draft-ermagan-lisp-nat-traversal-14.txt
 NAT traversal for LISP
 
 draft-ermagan-lisp-nat-traversal-14.txt
 Date: 16/04/2018
 Authors: Vina Ermagan, Dino Farinacci, Darrel Lewis, Jesper Skriver, Fabio Maino, Chris White
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) network element, which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT.
    
draft-ermagan-lisp-nsh-05.txt
 LISP Control Plane integration with NSH
 
 draft-ermagan-lisp-nsh-05.txt
 Date: 29/03/2018
 Authors: Vina Ermagan, Paul Quinn, Darrel Lewis, Fabio Maino, Florin Coras
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines extensions to the LISP control plane protocol to enable support for Network Service Header(NSH) based Service Function Chaining (SFC).
    
draft-even-avtcore-priority-markings-01.txt
 Frame Priority Marking RTP Header Extension
 
 draft-even-avtcore-priority-markings-01.txt
 Date: 26/02/2018
 Authors: Roni Even, Ofer Idan
 Working Group: Individual Submissions (none)
 Formats: txt pdf
This document updates the Frame Marking RTP header extension in draft-ietf-avtext-framemarking-06 used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middle-boxes or network nodes. The flags for frame marking for non-scalable streams include the D bit to mark a frame that can be discarded, and still provide a decodable media stream. There is also the I bit for frames that can be decoded independent of prior frames, e.g. intra-frame. This memo adds priority values for the non-scalable streams discardable frames
    
draft-fairhurst-taps-neat-01.txt
 The NEAT Interface to Transport Services
 
 draft-fairhurst-taps-neat-01.txt
 Date: 12/11/2017
 Authors: Gorry Fairhurst, Tom Jones, Anna Brunstrom, David Ros
 Working Group: Individual Submissions (none)
 Formats: xml txt
The NEAT System provides an example of a system designed to implement the TAPS Transport Services. This document presents the transport services that the NEAT User API provides to an application or upper- layer protocol. It also describes primitives needed to interface to the NEAT Policy Manager and how policies can be adjusted to match the API behaviour to the properties required by an application or upper- layer protocol using the NEAT User API.
    
draft-fairhurst-tsvwg-transport-encrypt-07.txt
 The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet
 
 draft-fairhurst-tsvwg-transport-encrypt-07.txt
 Date: 10/04/2018
 Authors: Gorry Fairhurst, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes implications of applying end-to-end encryption at the transport layer. It identifies in-network uses of transport layer header information. It then reviews the implications of developing end-to-end transport protocols that use encryption to provide confidentiality of the transport protocol header and expected implications of transport protocol design and network operation. Since transport measurement and analysis of the impact of network characteristics have been important to the design of current transport protocols, it also considers the impact on transport and application evolution.
    
draft-farinacci-lisp-decent-00.txt
 A Decent LISP Mapping System (LISP-Decent)
 
 draft-farinacci-lisp-decent-00.txt
 Date: 10/01/2018
 Authors: Dino Farinacci, Colin Cantrell
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust.
    
draft-farinacci-lisp-ecdsa-auth-02.txt
 LISP Control-Plane ECDSA Authentication and Authorization
 
 draft-farinacci-lisp-ecdsa-auth-02.txt
 Date: 19/04/2018
 Authors: Dino Farinacci, Erik Nordmark
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required.
    
draft-farinacci-lisp-geo-05.txt
 LISP Geo-Coordinate Use-Cases
 
 draft-farinacci-lisp-geo-05.txt
 Date: 16/04/2018
 Authors: Dino Farinacci
 Working Group: Locator/ID Separation Protocol (lisp)
 Formats: txt
This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols.
    
draft-farinacci-lisp-mobile-network-03.txt
 LISP for the Mobile Network
 
 draft-farinacci-lisp-mobile-network-03.txt
 Date: 18/03/2018
 Authors: Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: txt
This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network.
    
draft-farinacci-lisp-name-encoding-05.txt
 LISP Distinguished Name Encoding
 
 draft-farinacci-lisp-name-encoding-05.txt
 Date: 18/03/2018
 Authors: Dino Farinacci
 Working Group: Locator/ID Separation Protocol (lisp)
 Formats: txt
This draft defines how to use the AFI=17 Distinguished Names in LISP.
    
draft-farrel-sfc-convent-06.txt
 Operating the Network Service Header (NSH) with Next Protocol "None"
 
 draft-farrel-sfc-convent-06.txt
 Date: 16/02/2018
 Authors: Adrian Farrel, John Drake
 Working Group: Service Function Chaining (sfc)
 Formats: xml txt
This document describes the use of the Network Service Header (NSH) in a Service Function Chaining (SFC) enabled network with no payload data and carrying only metadata. This is achieved by defining a new NSH "Next Protocol" type value of "None". This document illustrates some of the functions that may be achieved or enhanced by this mechanism, but it does not provide an exhaustive list of use cases, nor is it intended to be definitive about the functions it describes. It is expected that other documents will describe specific use cases in more detail and will define the protocol mechanics for each use case.
    
draft-farrel-spring-sr-domain-interconnect-03.txt
 Interconnection of Segment Routing Domains - Problem Statement and Solution Landscape
 
 draft-farrel-spring-sr-domain-interconnect-03.txt
 Date: 06/01/2018
 Authors: Adrian Farrel, John Drake
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) is a popular forwarding paradigm for use in MPLS and IPv6 networks. It is typically 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-feeney-t2trg-inter-network-01.txt
 Inter-network Coexistence in the Internet of Things
 
 draft-feeney-t2trg-inter-network-01.txt
 Date: 30/10/2017
 Authors: Laura Feeney, Viktoria Fodor
 Working Group: Individual Submissions (none)
 Formats: txt xml
The breadth of IoT applications implies that there will be many diverse, administratively independent networks operating in the same physical location. In many cases, these networks will use unlicensed spectrum, due to its low cost and ease of deployment. However, this spectrum is becoming increasingly crowded. IoT networks will therefore be subject to wireless interference, both from similar networks and from networks that use the wireless channel in very different ways. High-density, heterogeneous wireless environments present formidable challenges for network coexistence. The PHY and MAC layers are primarily responsible for defining how radios use the channel. But higher layer protocols are also a party to adverse interactions between networks. To date, there have been few performance studies that fully reflect this aspect of the future IoT operating environment, particularly with respect to protocol behavior and network-scale interactions. This document describes key challenges for coexistence and highlights some recent research results showing the impact of protocol level interactions on network performance. It identifies two opportunities for the IRTF T2TRG community. The first is to define best practices for performance evaluation and protocol design in the context of network coexistence. The second is to investigate the use of higher layer protocols to actively participate in managing network coexistence.
    
draft-feng-dmm-ra-prefixtype-02.txt
 Router Advertisement Extensions for On-Demand Mobility
 
 draft-feng-dmm-ra-prefixtype-02.txt
 Date: 17/03/2018
 Authors: Wu-chi Feng, Danny Moses
 Working Group: Individual Submissions (none)
 Formats: xml txt
Router Advertisement / Router Solicitation is one of the ways for hosts to establish network IPv6 connectivity configuration. This document describes two approches to allowing a router to specify service continuity type availability to mobile hosts. Mobile hosts can then configure their IP address to the preferred service continuity type. Two possibilities are considered: (i) creating an extension to the router advertisement prefix information option to allow the router to specify service connectivity types, and (ii) specifying a new RA options that allows the router to specify the service connectivity types.
    
draft-fenter-tls-decryption-00.txt
 Why Enterprises Need Out-of-Band TLS Decryption
 
 draft-fenter-tls-decryption-00.txt
 Date: 05/03/2018
 Authors: Steve Fenter
 Working Group: Individual Submissions (none)
 Formats: txt
Some enterprises are heavily TLS encrypted within their own enterprise network boundaries. Many of these enterprises are also utilizing out-of-band TLS decryption in order to inspect their own traffic for purposes of troubleshooting, network security monitoring, and for other kinds of monitoring. These monitoring functions are mission critical, and cannot just be done without when TLS 1.3 (draft-ietf-tls-tls13-26) is released or when the RSA key exchange is someday deprecated from TLS 1.2 (RFC5246). This draft will outline the use cases for out-of-band TLS decryption, as well as alternative suggestions for monitoring and troubleshooting and the limitations of those alternatives.
    
draft-fgont-6man-rfc4941bis-01.txt
 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
 
 draft-fgont-6man-rfc4941bis-01.txt
 Date: 25/03/2018
 Authors: Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves
 Working Group: Individual Submissions (none)
 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-fieau-cdni-interfaces-https-delegation-03.txt
 CDNI extensions for HTTPS delegation
 
 draft-fieau-cdni-interfaces-https-delegation-03.txt
 Date: 09/01/2018
 Authors: Frederic Fieau, Stephan Emile, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: xml txt
The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document proposes extensions in CDNI Control and Metadata interfaces to setup HTTPS delegation from a uCDN to a dCDN.
    
draft-fielding-httpbis-http-auth-00.txt
 Hypertext Transfer Protocol (HTTP): Authentication
 
 draft-fielding-httpbis-http-auth-00.txt
 Date: 05/03/2018
 Authors: Roy Fielding, Julian Reschke
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypermedia information systems. This document defines the HTTP Authentication framework. This document obsoletes RFC 7235.
    
draft-fielding-httpbis-http-cache-00.txt
 Hypertext Transfer Protocol (HTTP): Caching
 
 draft-fielding-httpbis-http-cache-00.txt
 Date: 05/03/2018
 Authors: Roy Fielding, Mark Nottingham, Julian Reschke
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP caches and the associated header fields that control cache behavior or indicate cacheable response messages. This document obsoletes RFC 7234.
    
draft-fielding-httpbis-http-conditional-00.txt
 Hypertext Transfer Protocol (HTTP): Conditional Requests
 
 draft-fielding-httpbis-http-conditional-00.txt
 Date: 05/03/2018
 Authors: Roy Fielding, Julian Reschke
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines HTTP/1.1 conditional requests, including metadata header fields for indicating state changes, request header fields for making preconditions on such state, and rules for constructing the responses to a conditional request when one or more preconditions evaluate to false. This document obsoletes RFC 7232.
    
draft-fielding-httpbis-http-messaging-00.txt
 Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing
 
 draft-fielding-httpbis-http-messaging-00.txt
 Date: 05/03/2018
 Authors: Roy Fielding, Julian Reschke
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document provides an overview of HTTP architecture and its associated terminology, defines the "http" and "https" Uniform Resource Identifier (URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and describes related security concerns for implementations. This document obsoletes RFC 7230.
    
draft-fielding-httpbis-http-range-00.txt
 Hypertext Transfer Protocol (HTTP): Range Requests
 
 draft-fielding-httpbis-http-range-00.txt
 Date: 05/03/2018
 Authors: Roy Fielding, Yves Lafon, Julian Reschke
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines range requests and the rules for constructing and combining responses to those requests. This document obsoletes RFC 7233.
    
draft-fielding-httpbis-http-semantics-00.txt
 Hypertext Transfer Protocol: Semantics and Content
 
 draft-fielding-httpbis-http-semantics-00.txt
 Date: 05/03/2018
 Authors: Roy Fielding, Julian Reschke
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Hypertext Transfer Protocol (HTTP) is a stateless application- level protocol for distributed, collaborative, hypertext information systems. This document defines the semantics of HTTP/1.1 messages, as expressed by request methods, request header fields, response status codes, and response header fields, along with the payload of messages (metadata and body content) and mechanisms for content negotiation. This document obsoletes RFC 7231.
    
draft-filsfils-spring-large-scale-interconnect-09.txt
 Interconnecting Millions Of Endpoints With Segment Routing
 
 draft-filsfils-spring-large-scale-interconnect-09.txt
 Date: 29/03/2018
 Authors: Clarence Filsfils, Stefano Previdi, Gaurav Dawra, Wim Henderickx, Dave Cooper
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use-case can be applied to the interconnection of massive-scale DC's and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries.
    
draft-filsfils-spring-segment-routing-policy-05.txt
 Segment Routing Policy for Traffic Engineering
 
 draft-filsfils-spring-segment-routing-policy-05.txt
 Date: 28/02/2018
 Authors: Clarence Filsfils, Siva Sivabalan, Kamran Raza, Jose Liste, Francois Clad, Ketan Talaulikar, Zafar Ali, Shraddha Hegde, daniel.voyer@bell.ca, Steven Lin, bogdanov@google.com, Przemyslaw Krol, Martin Horneffer, Dirk Steinberg, Bruno Decraene, Stephane Litkowski, Paul Mattes
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. The headend node steers a flow into an SR Policy. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. This document details the concepts of SR Policy and steering into an SR Policy.
    
draft-filsfils-spring-srv6-interop-00.txt
 SRv6 interoperability report
 
 draft-filsfils-spring-srv6-interop-00.txt
 Date: 17/03/2018
 Authors: Clarence Filsfils, Francois Clad, Pablo Camarillo, Ahmed Abdelsalam, Stefano Salsano, Olivier Bonaventure, Jakub Horn, Jose Liste
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) can be applied to the IPv6 data plane by leveraging a new type of routing extension header, called Segment Routing Header (SRH). An SRH contains an ordered list, or sequence, of segments representing topological or service-based instructions, or any combination of those. This draft provides an overview of IPv6 Segment Routing (SRv6) implementations and interoperability. It makes an inventory of the various pieces of hardware and software that have been demonstrated to support the processing of an SRH, and details some interoperability scenarios that have been showcased at a public event.
    
draft-filsfils-spring-srv6-network-programming-04.txt
 SRv6 Network Programming
 
 draft-filsfils-spring-srv6-network-programming-04.txt
 Date: 05/03/2018
 Authors: Clarence Filsfils, Zhenbin Li, John Leddy, daniel.voyer@bell.ca, daniel.bernier@bell.ca, Dirk Steinberg, Robert Raszuk, Satoru Matsushima, David Lebrun, Bruno Decraene, Bart Peirens, Stefano Salsano, Gaurav Naik, Hani Elmalky, Prem Jonnalagadda, Milad Sharif
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the SRv6 network programming concept and its most basic functions.
    
draft-filyurin-lisp-elp-probing-00.txt
 LISP Explicit Locator Path (ELP) Probing
 
 draft-filyurin-lisp-elp-probing-00.txt
 Date: 14/11/2017
 Authors: Yan Filyurin, Robert Raszuk, Truman Boyes, Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a LISP-TE mechanism to probe an Explicit Locator Path (ELP) for reachability and telemetry data. The mechanism is called ELP-Probing.
    
draft-finkelman-cdni-rr-sva-extensions-00.txt
 CDNI SVA Request Routing Extensions
 
 draft-finkelman-cdni-rr-sva-extensions-00.txt
 Date: 12/02/2018
 Authors: Ori Finkelman, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery requests from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).
    
draft-finkelman-cdni-sva-extensions-00.txt
 CDNI SVA Extensions
 
 draft-finkelman-cdni-sva-extensions-00.txt
 Date: 30/10/2017
 Authors: Ori Finkelman, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery request from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).
    
draft-finn-bounded-latency-00.txt
 DetNet Bounded Latency
 
 draft-finn-bounded-latency-00.txt
 Date: 30/10/2017
 Authors: Norman Finn, Balazs Varga, Janos Farkas
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document a model for DetNet to achieve bounded latency and zero congestion loss using existing and in-progress standards from IEEE 802 and RFCs from IETF.
    
draft-finn-detnet-bounded-latency-00.txt
 DetNet Bounded Latency
 
 draft-finn-detnet-bounded-latency-00.txt
 Date: 07/03/2018
 Authors: Norman Finn, Jean-Yves Le Boudec, Balazs Varga, Janos Farkas
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document presents a parameterized timing model for Deterministic Networking so that existing and future standards can achieve bounded latency and zero congestion loss.
    
draft-finzi-priority-switching-scheduler-01.txt
 Priority Switching Scheduler
 
 draft-finzi-priority-switching-scheduler-01.txt
 Date: 05/03/2018
 Authors: Fred Baker, Anais Finzi, Fabrice Frances, Emmanuel Lochin, Ahlem Mifdaoui
 Working Group: Individual Submissions (none)
 Formats: xml txt
We detail the implementation of a network scheduler that switches the priority of one or several queues. This scheduler aims at carrying and isolating time constrained and elastic traffic flows from best- effort traffic. We claim that the usual implementations with rate schedulers (such as WRR, DRR,...) do not allow to efficiently quantify the reserved capacity of the different classes. By using this credit based scheduler mechanism called Priority Switching Scheduler, we provide a more predictable available capacity.
    
draft-fioccola-ippm-multipoint-alt-mark-02.txt
 Multipoint Alternate Marking method for passive and hybrid performance monitoring
 
 draft-fioccola-ippm-multipoint-alt-mark-02.txt
 Date: 01/03/2018
 Authors: Giuseppe Fioccola, Mauro Cociglio, Amedeo Sapio, Riccardo Sisto
 Working Group: Individual Submissions (none)
 Formats: txt
The Alternate Marking method, as presented in RFC 8321 [RFC8321], can be applied only to point-to-point flows because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document aims to generalize and expand this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here described is called Multipoint Alternate Marking. Some definitions here introduced extend the scope of RFC 5644 [RFC5644] in the context of alternate marking schema.
    
draft-fioccola-spring-flow-label-alt-mark-01.txt
 Using the IPv6 Flow Label for Performance Measurement with Alternate Marking Method in Segment Routing
 
 draft-fioccola-spring-flow-label-alt-mark-01.txt
 Date: 26/10/2017
 Authors: Giuseppe Fioccola, Gunter Van de Velde, Mauro Cociglio, Praveen Muley
 Working Group: Individual Submissions (none)
 Formats: txt
[RFC6294] makes a survey of Proposed Use Cases for the IPv6 Flow Label. The IPv6 protocol includes a flow label in every packet header, but this field is, according to [RFC6294], not used in practice. This document describes how the alternate marking method can be used as the passive performance measurement method in a IPv6 domain.
    
draft-fioccola-v6ops-ipv6-alt-mark-00.txt
 IPv6 Performance Measurement with Alternate Marking Method
 
 draft-fioccola-v6ops-ipv6-alt-mark-00.txt
 Date: 26/02/2018
 Authors: Giuseppe Fioccola, Gunter Van de Velde, Mauro Cociglio, Praveen Muley
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how the alternate marking method can be used as the passive performance measurement method in an IPv6 domain, and will discuss the strengths and the weaknesses of the implementation options available to network operations.
    
draft-flanagan-7322bis-03.txt
 RFC Style Guide
 
 draft-flanagan-7322bis-03.txt
 Date: 03/04/2018
 Authors: Heather Flanagan, RFC Editor
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 7322, "RFC Style Guide".
    
draft-fmm-nvo3-pm-alt-mark-01.txt
 Performance Measurement (PM) with Alternate Marking in Network Virtualization Overlays (NVO3)
 
 draft-fmm-nvo3-pm-alt-mark-01.txt
 Date: 02/03/2018
 Authors: Giuseppe Fioccola, Gregory Mirsky, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how the alternate marking method can be used for performance measurement method in a Network Virtualization Overlays (NVO3) Domain. The description aims to be general for NVO3 encapsulations, but is focused to Geneve, recommended by the NVO3 design team [I-D.ietf-nvo3-encap].
    
draft-foglar-ipv6-ull-routing-02.txt
 IPv6 Source Routing for ultralow Latency
 
 draft-foglar-ipv6-ull-routing-02.txt
 Date: 02/03/2018
 Authors: Andreas Foglar, Mike Parker, Theodoros Rokkas
 Working Group: Individual Submissions (none)
 Formats: txt
This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for very fast source routing experimentation using simple forwarding nodes. Research groups evaluate achievable latency reduction for special applications such as radio access networks, industrial networks or other networks requiring very low latency.
    
draft-fossati-tls-ext-header-01.txt
 Record Header Extensions for DTLS
 
 draft-fossati-tls-ext-header-01.txt
 Date: 03/03/2018
 Authors: Thomas Fossati, Nikos Mavrogiannopoulos
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes a mechanism to extend the record header in DTLS. To that aim, the DTLS header is modified as follows: the length field is trimmed to 15 bits, and the length's top bit is given the "record header extension indicator" semantics, allowing a sender to signal that one or more record header extensions have been added to this record. We define the generic format of a record header extension and the general rules associated with its handling. Any details regarding syntax, semantics and negotiation of a specific record header extension, are left to future documents.
    
draft-foudil-securitytxt-03.txt
 A Method for Web Security Policies
 
 draft-foudil-securitytxt-03.txt
 Date: 09/02/2018
 Authors: Edwin Foudil, Yakov Shafranovich
 Working Group: Individual Submissions (none)
 Formats: txt
When security risks in web services are discovered by independent security researchers who understand the severity of the risk, they often lack the channels to disclose them properly. As a result, security issues may be left unreported. security.txt defines a standard to help organizations describe the process for security researchers to disclose security vulnerabilities securely.
    
draft-foudil-spss-00.txt
 The Security Policy Specification Standard
 
 draft-foudil-spss-00.txt
 Date: 29/01/2018
 Authors: Edwin Foudil
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a way of standardising the structure, language, and grammar used in security policies. The goal is to reduce ambiguity and confusion that stems from poorly-worded security policies. Organisations and individuals can refer back to this document if their security policy uses definitions found in this document.
    
draft-fregly-regext-rdap-search-regex-03.txt
 Registration Data Access Protocol (RDAP) Search Using POSIX Regular Expressions
 
 draft-fregly-regext-rdap-search-regex-03.txt
 Date: 04/12/2017
 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-friel-brski-over-802dot11-00.txt
 BRSKI over IEEE 802.11
 
 draft-friel-brski-over-802dot11-00.txt
 Date: 02/03/2018
 Authors: Owen Friel, Eliot Lear, Max Pritikin, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document outlines the challenges associated with implementing Bootstrapping Remote Secure Key Infrastructures over IEEE 802.11 and IEEE 802.1x networks. Multiple options are presented for discovering and authenticating to the correct IEEE 802.11 SSID. This initial draft is a discussion document and no final recommendations are made on the recommended approaches to take.
    
draft-friel-pki-for-devices-00.txt
 PKI Certificate Identifier Format for Devices
 
 draft-friel-pki-for-devices-00.txt
 Date: 30/10/2017
 Authors: Owen Friel, Richard Barnes
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a standard Subject field identifier format for certificates issued to Internet of Things (IoT) devices. This will allow applications to easily and uniquely identify certificates issued to devices as opposed to certificates issue to services or users. The certificates will adhere to standard Web PKI specifications thus ensuring interoperability with existing Certificate Authorities processes and workflows, and standard client and service libraries and applications.
    
draft-friel-tls-atls-00.txt
 Application-Layer TLS (ATLS)
 
 draft-friel-tls-atls-00.txt
 Date: 31/01/2018
 Authors: Owen Friel, Richard Barnes, Max Pritikin, Hannes Tschofenig, Mark Baugher
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies how TLS sessions can be established at the application layer over untrusted transport between clients and services for the purposes of establishing secure end-to-end encrypted communications channels. Transport layer encodings for application layer TLS records are specified for HTTP and CoAP transport. Explicit identification of application layer TLS packets enables middleboxes to provide transport services and enforce suitable transport policies for these payloads, without requiring access to the unencrypted payload content. Multiple scenarios are presented identifying the need for end-to-end application layer encryption between clients and services, and the benefits of reusing the well- defined TLS protocol, and a standard TLS stack, to accomplish this are described. Application software architectures for building, and network architectures for deploying application layer TLS are outlined.
    
draft-fujimoto-urn-onem2m-01.txt
 A Uniform Resource Name (URN) Namespace for the oneM2M Partnership Project (oneM2M)
 
 draft-fujimoto-urn-onem2m-01.txt
 Date: 13/03/2018
 Authors: Shingo Fujimoto, Peter Niblett, Miguel Ortega
 Working Group: Applications and Real-Time Area (art)
 Formats: txt xml
This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources published by the oneM2M Partnership Project (oneM2M). oneM2M defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the oneM2M Secretariat.
    
draft-fujiwara-dnsop-additional-answers-01.txt
 Returning additional answers in DNS responses
 
 draft-fujiwara-dnsop-additional-answers-01.txt
 Date: 10/01/2018
 Authors: Kazunori Fujiwara
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes to document the ability to provide multiple answers in single DNS response. For example, authoritative servers may add a NSEC resource record or A/AAAA resource records of the query name. This is especially useful as, in many cases, the entity making the request has no a priori knowledge of what other questions it will need to ask. It is already possible (an authoritative server MAY already sends what it wants in the additional section). This document does not propose any protocol changes, just explanations of an already acceptable practice.
    
draft-galimbe-ccamp-iv-yang-05.txt
 A YANG model to manage the optical parameters for in a WDM network
 
 draft-galimbe-ccamp-iv-yang-05.txt
 Date: 01/03/2018
 Authors: Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a Yang model that translate the information model to support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functionality. The information model is defined in draft-ietf- ccamp-wson-iv-info and draft-martinelli-ccamp-wson-iv-encode. This document defines proper encoding and extend to the models defined in draft-lee-ccamp-wson-yang tu support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functions The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the multivendor Endpoints and ROADMs
    
draft-galis-anima-autonomic-slice-networking-04.txt
 Autonomic Slice Networking
 
 draft-galis-anima-autonomic-slice-networking-04.txt
 Date: 05/03/2018
 Authors: A. Galis, kiran.makhijani@huawei.com, Delei Yu, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the technical requirements and the related reference model for the intercommunication and coordination among devices in Autonomic Slicing Networking. The goal is to define how the various elements in a network slicing context work and orchestrate together, to describe their interfaces and relations. While the document is written as generally as possible, the initial solutions are limited to the chartered scope of the WG.
    
draft-gandhi-spring-sr-mpls-pm-00.txt
 Performance Measurement in Segment Routing Networks with MPLS Data Plane
 
 draft-gandhi-spring-sr-mpls-pm-00.txt
 Date: 14/02/2018
 Authors: Rakesh Gandhi, Clarence Filsfils, Sagar Soni, Patrick Khordoc, Zafar Ali, daniel.voyer@bell.ca, daniel.bernier@bell.ca, Stefano Salsano, Pier Ventre
 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 and channel throughput in MPLS networks. This document reviews how these mechanisms can be used for Performance Measurements in Segment Routing with MPLS data plane (SR-MPLS) networks.
    
draft-gandhi-spring-udp-pm-00.txt
 UDP Path for In-band Performance Measurement for Segment Routing Networks
 
 draft-gandhi-spring-udp-pm-00.txt
 Date: 19/03/2018
 Authors: Rakesh Gandhi, Clarence Filsfils, Sagar Soni, Patrick Khordoc, Zafar Ali, daniel.voyer@bell.ca, daniel.bernier@bell.ca, Stefano Salsano, Pier Ventre, Dirk Steinberg
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) is applicable to both MPLS (SR-MPLS) and IPv6 (SRv6) data planes. This document specifies a procedure for using UDP path for sending and processing in-band Performance Measurement (PM) Probe query and response messages. The procedure uses RFC 6374 defined mechanisms for Delay and Loss performance measurement. The procedure defined is applicable to IPv4, IPv6, SR-MPLS and SRv6 data planes. This document also defines Return Path Segment List TLV for bidirectional performance measurement.
    
draft-gao-alto-fcs-05.txt
 ALTO Extension: Flow-based Cost Query
 
 draft-gao-alto-fcs-05.txt
 Date: 04/03/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. To address these two 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 a more expressive address space which allows ALTO clients to make queries beyond the limited IP addresses.
    
draft-gao-alto-routing-state-abstraction-08.txt
 Compressing ALTO Path Vectors
 
 draft-gao-alto-routing-state-abstraction-08.txt
 Date: 01/03/2018
 Authors: Kai Gao, xinwang2014@hotmail.com, Qiao Xiang, Chen Gu, Yang Yang, G.Robert Chen
 Working Group: Individual Submissions (none)
 Formats: txt
The path vector extension [I-D.ietf-alto-path-vector] has extended the base ALTO protocol [RFC7285] with the ability to represent a more detailed view of the network which contains not only end-to-end costs but also information about shared bottlenecks. However, the view computed by straw man algorithms can contain redundant information and result in unnecessary communication overhead. The situation gets even worse when certain ALTO extensions are enabled, for example, the incremental update extension [I-D.ietf-alto-incr-update-sse] which continuously pushes data changes to ALTO clients. Redundant information can trigger unnecessary updates. In this document, several algorithms are described which can effectively reduce the redundancy in the network view while still providing the same information as in the original path vectors.
    
draft-gao-flexible-protocol-00.txt
 Flexible Session Protocol
 
 draft-gao-flexible-protocol-00.txt
 Date: 03/01/2018
 Authors: Jason Gao
 Working Group: Individual Submissions (none)
 Formats: txt
FSP is a connection-oriented transport layer protocol that provides mobility, multihoming and multipath load balancing support by introducing the concept of 'upper layer thread ID', which was firstly suggested in [Gao2002]. It provides additional transport layer features such as ubiquitous message authentication with optional encryption, zero round-trip connection cloning, transmit transaction and quad-party shared secret installation facility.
    
draft-gavrichenkov-dnsop-dnssapi-00.txt
 Domain Name System Service Application Programming Interface
 
 draft-gavrichenkov-dnsop-dnssapi-00.txt
 Date: 05/03/2018
 Authors: Artyom Gavrichenkov
 Working Group: Individual Submissions (none)
 Formats: txt xml
Managed DNS services are widely used to maintain DNS zones. Virtually all of them have an API of some sort, in most cases an XML- RPC or JSON-RPC API, while most of them lack the support of zone transfers. The latter is unlikely to change any time soon due to the reasons outlined below. This document describes a protocol, a common denominator of existing API protocols, that both a service provider and its customer can use to exchange information about DNS zones and policies.
    
draft-geng-coms-architecture-02.txt
 COMS Architecture
 
 draft-geng-coms-architecture-02.txt
 Date: 05/03/2018
 Authors: Liang Geng, Li Qiang, Jose Lucena, Pablo Ameigeiras, Diego Lopez, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the overall architecture of a COMS based network slicing system. COMS works on the top level network slice orchestrator which directly communicates with the network slice provider and enables the technology-independent network slice management.
    
draft-geng-coms-problem-statement-04.txt
 Problem Statement of Common Operation and Management of Network Slicing
 
 draft-geng-coms-problem-statement-04.txt
 Date: 05/03/2018
 Authors: Liang Geng, Slawomir, Li Qiang, kiran.makhijani@huawei.com, A. Galis, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses the problem statement of Common Operation and Management of Network Slicing (COMS). The purpose of this document is to identify the problem space of COMS and discuss the approach COMS is using to match the top-down network slice management concern with the underlay technologies. Furthermore, the role of a common information model is introduced and corresponding design principles are also discussed.
    
draft-geng-detnet-conf-yang-01.txt
 DetNet Configuration YANG Model
 
 draft-geng-detnet-conf-yang-01.txt
 Date: 05/03/2018
 Authors: Xuesong Geng, Mach Chen, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG data Model for Deterministic Networking (DetNet), covering the device / link capabilities and resources. It can be used in network capability advertising, device configuration and status reporting.
    
draft-geng-detnet-info-distribution-02.txt
 IGP-TE Extensions for DetNet Information Distribution
 
 draft-geng-detnet-info-distribution-02.txt
 Date: 05/03/2018
 Authors: Xuesong Geng, Mach Chen, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
There are requirements in diverse industries to establish multi-hop paths for characterized flows with bounded end-to-end latency and extremely low packet loss rate. Deterministic Networking (DetNet) can provide service satisfying the requirements. This document describes extensions to IGP-TE, including OSPF-TE and ISIS-TE to distribute information of DetNet, which can be used for DetNet path computation/selection. This document only covers the mechanisms by which DetNet information is distributed. The mechanisms for measuring, calculating or configuring DetNet capabilities, resources and other relevant parameters are out of the scope.
    
draft-geng-iiot-edge-computing-problem-statement-01.txt
 Problem Statement of Edge Computing on Premises for Industrial IoT
 
 draft-geng-iiot-edge-computing-problem-statement-01.txt
 Date: 05/03/2018
 Authors: Liang Geng, Mingui Zhang, Mike McBride, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the concept of Beyond Edge Computing (BEC) which brings edge computing capabilities down to the level of customers' premises for industrial IoT use cases. The purpose of the document is to discuss the general problem statement of BEC including capabilities, and use cases. Potential technical gaps in IETF problem scope that are related to BEC are also evaluated.
    
draft-ggalimbe-ccamp-flex-if-lmp-04.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-04.txt
 Date: 01/03/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-03.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-03.txt
 Date: 01/03/2018
 Authors: Gabriele Galimberti, Domenico Fauci, Andrea Zanardi, Lorenzo Galvagni
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines the signaling extensions for managing Spectrum Switched Optical Network (SSON) parameters shared between the Client and the Network and inside the Network in accordance to the model described in RFC 7698. The extensions are in accordance and extending the parameters defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872].
    
draft-ginsberg-isis-rfc5306bis-00.txt
 Restart Signaling for IS-IS
 
 draft-ginsberg-isis-rfc5306bis-00.txt
 Date: 01/03/2018
 Authors: Les Ginsberg, Paul Wells
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additonally describes a mechansim for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding plane state. This allows the neighbors to maintain their adjacencies until the router has restarted, but also allows the neighbors to bring the adjacencies down in the event of other topology changes. This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 5306.
    
draft-ginsberg-lsr-isis-rfc7810bis-00.txt
 IS-IS Traffic Engineering (TE) Metric Extensions
 
 draft-ginsberg-lsr-isis-rfc7810bis-00.txt
 Date: 09/04/2018
 Authors: Les Ginsberg, Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Qin Wu
 Working Group: Individual Submissions (none)
 Formats: txt xml
In certain networks, such as, but not limited to, financial information networks (e.g., stock market data providers), network- performance criteria (e.g., latency) are becoming as critical to data-path selection as other metrics. This document describes extensions to IS-IS Traffic Engineering Extensions (RFC 5305) such that network-performance information can be distributed and collected in a scalable fashion. The information distributed using IS-IS TE Metric Extensions can then be used to make path-selection decisions based on network performance. Note that this document only covers the mechanisms with which network-performance information is distributed. The mechanisms for measuring network performance or acting on that information, once distributed, are outside the scope of this document. This document obsoletes RFC 7810.
    
draft-gondwana-jmap-imapdata-00.txt
 JMAP Extension for imap data
 
 draft-gondwana-jmap-imapdata-00.txt
 Date: 21/03/2018
 Authors: Bron Gondwana
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document adds additional properties to the JMAP Email and Mailbox objects so that servers which also support IMAP can expose metadata about the IMAP Mailstore via JMAP.
    
draft-gont-6man-address-usage-recommendations-04.txt
 Problem Statement Regarding IPv6 Address Usage
 
 draft-gont-6man-address-usage-recommendations-04.txt
 Date: 30/10/2017
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the security and privacy implications of IPv6 addresses based on a number of properties (such as address scope, stability, and usage type), and identifies gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses.
    
draft-gont-6man-non-stable-iids-04.txt
 Recommendation on Temporary IPv6 Interface Identifiers
 
 draft-gont-6man-non-stable-iids-04.txt
 Date: 24/03/2018
 Authors: Fernando Gont, Christian Huitema, Suresh Krishnan, Guillermo Gont, Madelen Corbo
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a set of requirements for generating temporary addresses, and clarifies the stability requirements for IPv6 addresses, allowing for the use of only temporary addresses.
    
draft-gont-numeric-ids-generation-02.txt
 On the Generation of Transient Numeric Identifiers
 
 draft-gont-numeric-ids-generation-02.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers and analyzes their security and privacy properties.
    
draft-gont-numeric-ids-history-03.txt
 Unfortunate History of Transient Numeric Identifiers
 
 draft-gont-numeric-ids-history-03.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. It describes a number of algorithms that have been employed in real implementations to meet such requirements and analyzes their security and privacy properties. Additionally, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it provides recommendations for future protocol specifications regarding the specification of the aforementioned numeric identifiers.
    
draft-gont-numeric-ids-sec-considerations-02.txt
 Security Considerations for Transient Numeric Identifiers Employed in Network Protocols
 
 draft-gont-numeric-ids-sec-considerations-02.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
For more than 30 years, a large number of implementations of the TCP/ IP protocol suite have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection, to information leakage that could be exploited for pervasive monitoring. The root of these issues has been, in many cases, the poor selection of transient identifiers in such protocols, usually as a result of an insufficient or misleading specifications. This document formally updates RFC3552, such that RFCs are required to perform a security and privacy analysis of the transient numeric identifiers they specify.
    
draft-gont-predictable-numeric-ids-02.txt
 Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols
 
 draft-gont-predictable-numeric-ids-02.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. It describes a number of algorithms that have been employed in real implementations to meet such requirements and analyzes their security and privacy properties. Additionally, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it provides recommendations for future protocol specifications regarding the specification of the aforementioned numeric identifiers.
    
draft-gont-taps-address-analysis-00.txt
 Problem Statement Regarding IPv6 Address Usage
 
 draft-gont-taps-address-analysis-00.txt
 Date: 21/03/2018
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the security, privacy, and interoperability implications of IPv6 addresses based on a number of properties (such as address scope, stability, and usage type).
    
draft-gont-taps-address-usage-problem-statement-00.txt
 Problem Statement Regarding IPv6 Address Usage
 
 draft-gont-taps-address-usage-problem-statement-00.txt
 Date: 28/02/2018
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the security and privacy implications of IPv6 addresses based on a number of properties (such as address scope, stability, and usage type), and identifies gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses.
    
draft-gont-taps-sockets-api-limitations-00.txt
 Problem Statement Regarding Limitations of the Sockets API for IPv6 Address Usage
 
 draft-gont-taps-sockets-api-limitations-00.txt
 Date: 21/03/2018
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This identifies gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses.
    
draft-gont-tcpm-tcp-seq-validation-03.txt
 On the Validation of TCP Sequence Numbers
 
 draft-gont-tcpm-tcp-seq-validation-03.txt
 Date: 05/03/2018
 Authors: Fernando Gont, David Borman
 Working Group: Individual Submissions (none)
 Formats: txt
When TCP receives packets that lie outside of the receive window, the corresponding packets are dropped and either an ACK, RST or no response is generated due to the out-of-window packet, with no further processing of the packet. Most of the time, this works just fine and TCP remains stable, especially when a TCP connection has unidirectional data flow. However, there are three scenarios in which packets that are outside of the receive window should still have their ACK field processed, or else a packet war will take place. The aforementioned issues have affected a number of popular TCP implementations, typically leading to connection failures, system crashes, or other undesirable behaviors. This document describes the three scenarios in which the aforementioned issues might arise, and formally updates RFC 793 such that these potential problems are mitigated.
    
draft-google-self-published-geofeeds-02.txt
 Self-published IP Geolocation Data
 
 draft-google-self-published-geofeeds-02.txt
 Date: 28/07/2013
 Authors: Erik Kline, Krzysztof Duleba, Zoltan Szamonek
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document records a format whereby a network operator can publish a mapping of IP address ranges to simplified geolocation information, colloquially termed a geolocation "feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. At least one consumer (Google) has incorporated these ad hoc feeds into a geolocation data pipeline.
    
draft-gould-idn-table-06.txt
 Extensible Provisioning Protocol (EPP) Internationalized Domain Name (IDN) Table Mapping
 
 draft-gould-idn-table-06.txt
 Date: 16/04/2018
 Authors: James Gould, Francisco Obispo
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an Extensible Provisioning Protocol (EPP) mapping for getting Internationalized Domain Name (IDN) Table information for the registration of IDNs, using the EPP domain name mapping, and optionally with the IDN mapping extension. An IDN Table defines the valid set of characters (code points) that can be used in a domain name. Code points may overlap across IDN Tables and the IDN Tables supported by the servers are up to server policy. The IDN Table information can be used to validate an IDN prior to registration, can be cached by the client for pre-validation, can be used to select the best IDN Table for the IDN, and can be used to know if and what IDN Table Identifier to pass in a domain create.
    
draft-guichard-sfc-nsh-sr-01.txt
 NSH and Segment Routing Integration for Service Function Chaining (SFC)
 
 draft-guichard-sfc-nsh-sr-01.txt
 Date: 06/04/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 of a given SFP while NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata. These application scenarios demonstrate that NSH and SR can work jointly and complement each other leaving the network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure, and still maintain an end-to-end service plane using NSH.
    
draft-gundavelli-dmm-mfa-00.txt
 Mobility-aware Floating Anchor (MFA)
 
 draft-gundavelli-dmm-mfa-00.txt
 Date: 24/02/2018
 Authors: Sri Gundavelli, Marco Liebsch, Satoru Matsushima
 Working Group: Individual Submissions (none)
 Formats: txt
IP mobility protocols are designed to allow a mobile node to remain reachable while moving around in the network. The currently deployed mobility management protocols are anchor-based approaches, where a mobile node's IP sessions are anchored on a central node. The mobile node's IP traffic enters and exits from this anchor node and it remains as the control point for all subscriber services. This architecture based on fixed IP anchors comes with some complexity and there is some interest from the mobile operators to eliminate the use of fixed anchors, and other residual elements such as the overlay tunneling that come with it. This document describes a new approach for realizing a mobile user- plane that does not require fixed IP anchors. The architectural- basis for this approach is the separation of control and user plane, and the use of programmability constructs of the user-plane for traffic steering. This approach is referred to as, Mobility-aware Floating Anchor (MFA).
    
draft-gundogan-icnrg-ccnlowpan-01.txt
 ICN Adaptation to LowPAN Networks (ICN LoWPAN)
 
 draft-gundogan-icnrg-ccnlowpan-01.txt
 Date: 05/03/2018
 Authors: Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch, Christopher Scherb, Claudio Marxer, Christian Tschudin
 Working Group: Individual Submissions (none)
 Formats: txt xml
In this document, a convergence layer for CCNx and NDN over IEEE 802.15.4 LowPan networks is defined. A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by 6LoWPAN is extended to include new dispatch types for CCNx and NDN. Additionally, the link fragmentation component of the 6LoWPAN dispatching framework is applied to ICN chunks. Basic improvements in efficiency are advised by stateless compression schemes.
    
draft-gundogan-icnrg-pub-iot-02.txt
 Publish-Subscribe Deployment Option for NDN in the Constrained Internet of Things
 
 draft-gundogan-icnrg-pub-iot-02.txt
 Date: 05/03/2018
 Authors: Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch
 Working Group: Individual Submissions (none)
 Formats: txt xml
Constrained IoT devices often operate more efficiently in a loosely coupled environment without maintaining end-to-end connectivity between nodes. Information Centric Networking naturally supports this demand by replicated data distribution and hop wise forwarding. This document outlines a deployment option for NDN in low-power and lossy networks (LLNs) that follows a publish-subscribe pattern. The proposed protocol scheme simplifies name-based routing significantly and facilitates even large off-duty cycles for constrained nodes.
    
draft-gutmann-scep-10.txt
 Simple Certificate Enrolment Protocol
 
 draft-gutmann-scep-10.txt
 Date: 01/03/2018
 Authors: Peter Gutmann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using CMS (formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.
    
draft-gutmann-tls-lts-10.txt
 TLS 1.2 Update for Long-term Support
 
 draft-gutmann-tls-lts-10.txt
 Date: 22/03/2018
 Authors: Peter Gutmann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an update of TLS 1.2 for long-term support on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis.
    
draft-haas-bfd-large-packets-00.txt
 BFD Encapsulated in Large Packets
 
 draft-haas-bfd-large-packets-00.txt
 Date: 19/03/2018
 Authors: Jeffrey Haas, Albert Fu
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode.
    
draft-haberman-iasa20dt-recs-02.txt
 IASA 2.0 Design Team Recommendations
 
 draft-haberman-iasa20dt-recs-02.txt
 Date: 18/04/2018
 Authors: Brian Haberman, Jari Arkko, Leslie Daigle, Jason Livingood, Joseph Hall, Eric Rescorla
 Working Group: Individual Submissions (none)
 Formats: txt
The arrangements relating to administrative support for the IETF were created more than ten years ago. Since then, there has been considerable change in the tasks and in our own expectations. The IETF community has discussed these changes and the problems they cause. The community has some sense of the properties they expect from future arrangements, including those related to structure, organization, personnel, and transparency. This document is a product of a design team, focused on providing additional information to the community about solution options, as well as supporting analysis of the implications of those options. To be clear, the community is responsible for adopting any recommendations or making any final decisions.
    
draft-haindl-lisp-gb-atn-00.txt
 Ground-Based LISP for the Aeronautical Telecommunications Network
 
 draft-haindl-lisp-gb-atn-00.txt
 Date: 06/12/2017
 Authors: Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras, Victor Moreno, Fabio Maino
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization. The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures.
    
draft-hakala-urn-nbn-rfc3188bis-00.txt
 Using National Bibliography Numbers as Uniform Resource Names
 
 draft-hakala-urn-nbn-rfc3188bis-00.txt
 Date: 15/04/2018
 Authors: Juna Hakala
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
National Bibliography Numbers, NBNs, are used by the national libraries and other organizations in order to identify resources in their collections. Generally, NBNs are applied to resources that are not catered for by established (standard) identifier systems such as ISBN. A URN (Uniform Resource Names) namespace for NBNs was established in 2001 in RFC 3188. Since then, several European national libraries have implemented URN:NBN-based systems. This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) compliant to RFC 8141 is included.
    
draft-hall-iasa2-struct-01.txt
 Proposed Structure of the IETF Administrative Support Activity (IASA),Version 2.0 (for Discussion)
 
 draft-hall-iasa2-struct-01.txt
 Date: 05/03/2018
 Authors: Brian Haberman, Joseph Hall, Jason Livingood
 Working Group: Individual Submissions (none)
 Formats: txt xml
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the intervening years, the needs of the IETF have evolved in ways that require changes to its administrative structure. The purpose of this document is to spur discussion by outlining some details of what an "IASA 2.0" arrangement could look like. The proposal is for the execution of the IETF's administrative and fundraising tasks to be conducted by a new administrative organization ("IETFAdminOrg"). The IAOC would be eliminated, and its oversight and advising functions transferred to the IETFAdminOrg board and a new IETF Administrative Advisory Council, respectively.
    
draft-hallambaker-jbcd-container-02.txt
 JBCD Container
 
 draft-hallambaker-jbcd-container-02.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jbcd-container.html [1] .
    
draft-hallambaker-json-key-exchange-03.txt
 JSON Key Exchange
 
 draft-hallambaker-json-key-exchange-03.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The JSON Key Exchange This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-json-key- exchange.html [1] .
    
draft-hallambaker-json-web-service-10.txt
 JSON Web Service Binding Version 1.0
 
 draft-hallambaker-json-web-service-10.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The JSON Web Binding (JWB) describes a standardized approach to implementing Web Services. Services are advertised using the DNS SRV and HTTP Well Known Service conventions. Messages may be authenticated or authenticated and encrypted at the message layer in addition to any transport and/or network layer security. Service messages are encoded in JSON using Internet time format for Date-Time fields and Base64urlencoding for binary objects. This document specifies Version 1.0 of JWB which uses HTTP/1.1 for transport. Use of the multiple stream capabilities of HTTP/2 or QUIC is outside the scope of this document. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-json-web-service.html [1] .
    
draft-hallambaker-jsonbcd-11.txt
 Binary Encodings for JavaScript Object Notation: JSON-B,JSON-C,JSON-D
 
 draft-hallambaker-jsonbcd-11.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
Three binary encodings for JavaScript Object Notation (JSON) are presented. JSON-B (Binary) is a strict superset of the JSON encoding that permits efficient binary encoding of intrinsic JavaScript data types. JSON-C (Compact) is a strict superset of JSON-B that supports compact representation of repeated data strings with short numeric codes. JSON-D (Data) supports additional binary data types for integer and floating-point representations for use in scientific applications where conversion between binary and decimal representations would cause a loss of precision. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html [1] .
    
draft-hallambaker-mesh-app-02.txt
 Mathematical Mesh: Application Profiles
 
 draft-hallambaker-mesh-app-02.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The use of the Mathematical Mesh to manage cryptographic keys for use with Mail and SSH is described. The format of the application profiles is described with examples. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-app.html [1] .
    
draft-hallambaker-mesh-developer-07.txt
 Mathematical Mesh: Reference Implementation
 
 draft-hallambaker-mesh-developer-07.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes the Mesh reference code and how to install, run and make use of it in applications. It does not form a part of the Mesh specifications and is not normative. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-developer.html [1] .
    
draft-hallambaker-mesh-platform-03.txt
 Mathematical Mesh: Platform Configuration
 
 draft-hallambaker-mesh-platform-03.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes how Mesh profiles are stored for application access on Windows, Linux and OSX platforms. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-platform.html [1] .
    
draft-hallambaker-mesh-reference-09.txt
 Mathematical Mesh: Reference
 
 draft-hallambaker-mesh-reference-09.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-reference.html [1] .
    
draft-hallambaker-sin-03.txt
 Strong Internet Names (SIN)
 
 draft-hallambaker-sin-03.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
A Strong Internet Name is a DNS name that contains a cryptographic binding to a security policy governing interpretation of the name. This document describes the use of Strong Internet Names formed using a Uniform Data Fingerprint of a PKIX trust root and outlines the additional capabilities that might be supported in a purpose written policy language. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-sin.html [1] .
    
draft-hallambaker-udf-10.txt
 Uniform Data Fingerprint (UDF)
 
 draft-hallambaker-udf-10.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Uses of UDF fingerprints include but are not limited to creating Strong Internet Names (SINs). Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-udf.html [1] .
    
draft-haluska-sipping-directory-assistance-11.txt
 Considerations for Information Services and Operator Services Using SIP
 
 draft-haluska-sipping-directory-assistance-11.txt
 Date: 15/08/2011
 Authors: John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell
 Working Group: Real-time Applications and Infrastructure Area (rai)
 Formats: txt
Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers.
    
draft-hamarsheh-behave-biav2-05.txt
 Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA)
 
 draft-hamarsheh-behave-biav2-05.txt
 Date: 19/01/2011
 Authors: Ala Hamarsheh
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a mechanism for hosts with any network connectivity (IPv4 only, IPv6 only, or dual IPv4/IPv6 connectivity) to run applications of any capability (IPv4 only, IPv6 only, or dual IPv4/IPv6) without any modification to those applications. It is a generalisation of a previous experimental protocol called "Bump-in-the-API" (BIA) [RFC3338]. New mechanism of BIA allows a changeover between the application layer and the IP communication layers from IPv4 to IPv6 and vice versa or IPv6 to IPv4 and vice versa, without requiring those applications to be converted in addressing capabilities, effectively shielding the application layer from IPv4 or IPv6 connectivity. This is considered by the authors to be one of the essential conditions for the transition to IPv6 in the Internet to be successful.
    
draft-han-tsvwg-cc-00.txt
 A New Congestion Control in Bandwidth Guaranteed Network
 
 draft-han-tsvwg-cc-00.txt
 Date: 03/03/2018
 Authors: Lin Han, Yingzhen Qu, Thomas Nadeau
 Working Group: Individual Submissions (none)
 Formats: xml txt
In bandwidth guaranteed networks, network resources are reserved before a TCP session starts transmitting data. This draft proposes a new TCP congestion control algorithm used in bandwidth guaranteed networks. It is an extension to the current TCP standards.
    
draft-handrews-json-schema-01.txt
 JSON Schema: A Media Type for Describing JSON Documents
 
 draft-handrews-json-schema-01.txt
 Date: 19/03/2018
 Authors: Austin Wright, Henry Andrews
 Working Group: Individual Submissions (none)
 Formats: txt xml
JSON Schema defines the media type "application/schema+json", a JSON- based format for describing the structure of JSON data. JSON Schema asserts what a JSON document must look like, ways to extract information from it, and how to interact with it. The "application/ schema-instance+json" media type provides additional feature-rich integration with "application/schema+json" beyond what can be offered for "application/json" documents.
    
draft-handrews-json-schema-hyperschema-01.txt
 JSON Hyper-Schema: A Vocabulary for Hypermedia Annotation of JSON
 
 draft-handrews-json-schema-hyperschema-01.txt
 Date: 19/01/2018
 Authors: Henry Andrews, Austin Wright
 Working Group: Individual Submissions (none)
 Formats: txt xml
JSON Schema is a JSON-based format for describing JSON data using various vocabularies. This document specifies a vocabulary for annotating JSON documents with hyperlinks. These hyperlinks include attributes describing how to manipulate and interact with remote resources through hypermedia environments such as HTTP, as well as determining whether the link is usable based on the instance value. The hyperlink serialization format described in this document is also usable independent of JSON Schema.
    
draft-handrews-json-schema-validation-01.txt
 JSON Schema Validation: A Vocabulary for Structural Validation of JSON
 
 draft-handrews-json-schema-validation-01.txt
 Date: 19/03/2018
 Authors: Austin Wright, Henry Andrews, Geraint Luff
 Working Group: Individual Submissions (none)
 Formats: txt xml
JSON Schema (application/schema+json) has several purposes, one of which is JSON instance validation. This document specifies a vocabulary for JSON Schema to describe the meaning of JSON documents, provide hints for user interfaces working with JSON data, and to make assertions about what a valid document must look like.
    
draft-handrews-relative-json-pointer-01.txt
 Relative JSON Pointers
 
 draft-handrews-relative-json-pointer-01.txt
 Date: 19/01/2018
 Authors: Geraint Luff, Henry Andrews
 Working Group: Individual Submissions (none)
 Formats: txt xml
JSON Pointer is a syntax for specifying locations in a JSON document, starting from the document root. This document defines an extension to the JSON Pointer syntax, allowing relative locations from within the document.
    
draft-hao-bess-evpn-centralized-df-01.txt
 Centralized EVPN DF Election
 
 draft-hao-bess-evpn-centralized-df-01.txt
 Date: 20/03/2018
 Authors: Donald Eastlake, Hao Weiguo, Lili Wang, Li Yizhou, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a centralized DF Designated Forwarder election mechanism to be used between an SDN (Software Defined Network) controller and each PE (Provider Edge) device in an EVPN network. Such a mechanism overcomes the issues of current standalone DF election defined in RFC 7432. A new BGP capability and an additional DF Election Result Route Type are specified to support this centralized DF mechanism.
    
draft-hardie-iris-arpa-00.txt
 Iris.arpa is Deprecated
 
 draft-hardie-iris-arpa-00.txt
 Date: 10/01/2018
 Authors: Ted Hardie
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
This document requests that iris.arpa and areg.iris.arpa be removed from the arpa zone.
    
draft-hardie-path-signals-03.txt
 Path Signals
 
 draft-hardie-path-signals-03.txt
 Date: 02/04/2018
 Authors: Ted Hardie
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the nature of signals seen by on-path elements, contrasting implicit and explicit signals. For example, TCP's state mechanics uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on- path network elements lack those signals. This document recommends that explict signals be used by transports which encrypt their state mechanics. It also recommends that a signal be exposed to the path only when the signal's originator intends that it be used by the network elements on the path.
    
draft-hardjono-oauth-decentralized-02.txt
 Decentralized Service Architecture for OAuth2.0
 
 draft-hardjono-oauth-decentralized-02.txt
 Date: 25/03/2018
 Authors: Thomas Hardjono
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an alternative service architecture for user- centric control of the sharing of resources following the UMA model, such as personal data, using the decentralized peer-to-peer computing paradigm. The term 'control' is used here to denote the full capacity of the user to freely select (i) the entities with whom to share resources (e.g. data), and (ii) the entities which provide services implementing user-controlled resource sharing. The peer-to- peer service architecture uses a set of computing nodes called OAuth2.0 Nodes (ON) that are part of a peer-to-peer network as the basis for the decentralized service architecture.
    
draft-hardt-oauth-distributed-00.txt
 Distributed OAuth
 
 draft-hardt-oauth-distributed-00.txt
 Date: 13/11/2017
 Authors: Dick Hardt
 Working Group: Individual Submissions (none)
 Formats: xml txt
The OAuth client credentials grant The Distributed OAuth profile enables an OAuth client using the client credentials grant to discover what authorization server to use for a given resource server, and what attribute values to provide in the access token request.
    
draft-hardt-oauth-mutual-02.txt
 Reciprocal OAuth
 
 draft-hardt-oauth-mutual-02.txt
 Date: 16/01/2018
 Authors: Dick Hardt
 Working Group: Individual Submissions (none)
 Formats: xml txt
There are times when a user has a pair of protected resources that would like to request access to each other. While OAuth flows typically enable the user to grant a client access to a protected resource, granting the inverse access requires an additional flow. Reciprocal OAuth enables a more seemless experience for the user to grant access to a pair of protected resources.
    
draft-hares-i2nsf-capability-data-model-07.txt
 I2NSF Capability YANG Data Model
 
 draft-hares-i2nsf-capability-data-model-07.txt
 Date: 23/03/2018
 Authors: Susan Hares, Jaehoon Jeong, Jinyong Kim, Robert Moskowitz, linqiushi@huawei.com
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG data model for capabilities that enables an I2NSF user to control various network security functions in network security devices.
    
draft-hares-i2rs-ephemeral-ds-00.txt
 I2RS Ephemeral Datastore
 
 draft-hares-i2rs-ephemeral-ds-00.txt
 Date: 12/11/2017
 Authors: Susan Hares, Alexander Clemm
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document the Yang module for the I2RS ephemeral datastore.
    
draft-haresh-sushrut-mib-classification-01.txt
 SNMPD to use cache and shared database based on MIB Classification
 
 draft-haresh-sushrut-mib-classification-01.txt
 Date: 29/03/2012
 Authors: Haresh Khandelwal
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device.
    
draft-harkins-pkex-05.txt
 Public Key Exchange
 
 draft-harkins-pkex-05.txt
 Date: 24/01/2018
 Authors: Dan Harkins
 Working Group: Crypto Forum (cfrg)
 Formats: txt
This memo describes a password-authenticated protocol to allow two devices to exchange "raw" (uncertified) public keys and establish trust that the keys belong to their respective identities.
    
draft-harkins-tls-dragonfly-02.txt
 Secure Password Ciphersuites for Transport Layer Security (TLS)
 
 draft-harkins-tls-dragonfly-02.txt
 Date: 28/08/2017
 Authors: Dan Harkins
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The exchange is called TLS-PWD. The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to off-line dictionary attack.
    
draft-hartke-core-pending-02.txt
 "Pending" Responses for the Constrained Application Protocol (CoAP)
 
 draft-hartke-core-pending-02.txt
 Date: 26/02/2018
 Authors: Peter Van der Stok, Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a new type of response for the Constrained Application Protocol (CoAP) called a "Pending" response. A CoAP server can use a Pending response to indicate that it has accepted a request but has not yet started processing it or that processing the request will take longer than a client is typically willing to wait for a response.
    
draft-hartke-t2trg-coral-04.txt
 The Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-04.txt
 Date: 30/10/2017
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as two specialized serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata.
    
draft-hartke-t2trg-data-hub-01.txt
 Thing-to-Thing Data Hub
 
 draft-hartke-t2trg-data-hub-01.txt
 Date: 02/03/2018
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The Thing-to-Thing Data Hub is a RESTful, hypermedia-driven Web application that can be used in Thing-to-Thing communication to share data items such as thing descriptions, configurations, resource descriptions, or firmware updates at a central location.
    
draft-haynes-nfsv4-delstid-00.txt
 Extending the Opening of Files in NFSv4.2
 
 draft-haynes-nfsv4-delstid-00.txt
 Date: 01/04/2018
 Authors: Thomas Haynes
 Working Group: Individual Submissions (none)
 Formats: txt
The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file. This grants the client the right to cache metadata on the file locally. This document presents serveral refinements to both the opeing and delegating of the file to the client.
    
draft-hegde-spring-node-protection-for-sr-te-paths-02.txt
 Node Protection for SR-TE Paths
 
 draft-hegde-spring-node-protection-for-sr-te-paths-02.txt
 Date: 30/10/2017
 Authors: Shraddha Hegde, Chris Bowers, Stephane Litkowski
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment routing supports the creation of explicit paths using adjacency-sids, node-sids, and binding-sids. It is important to provide fast reroute (FRR) mechanisms to respond to failures of links and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point of local repair (PLR) can provide FRR protection against the failure of a link in an SR-TE path by examining only the first (top) label in the SR label stack. In order to protect against the failure of a node, a PLR may need to examine the second label in the stack as well in order to determine SR-TE path beyond the failed node. This document specifies how a PLR can use the first and second label in the label stack describing an SR-TE path to provide protection against node failures.
    
draft-hegde-spring-traffic-accounting-for-sr-paths-01.txt
 Traffic Accounting for MPLS Segment Routing Paths
 
 draft-hegde-spring-traffic-accounting-for-sr-paths-01.txt
 Date: 30/10/2017
 Authors: Shraddha Hegde
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
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-hegdeppsenak-isis-sr-flex-algo-02.txt
 ISIS Segment Routing Flexible Algorithm
 
 draft-hegdeppsenak-isis-sr-flex-algo-02.txt
 Date: 16/02/2018
 Authors: Peter Psenak, Shraddha Hegde, Clarence Filsfils, Arkadiy Gulko
 Working Group: Individual Submissions (none)
 Formats: txt
IGP protocols traditionally compute best paths over the network based on the IGP metric assigned to the links. Many network deployments use RSVP-TE based or Segment Routing based Traffic Engineering to enforce traffic over a path that is computed using different metrics or constraints than the shortest IGP path. Various mechanisms are used to steer the traffic towards such traffic engineered paths. This document proposes a solution that allows IGPs themselves to compute constraint based paths over the network without the use of the above mentioned traffic engineering technologies.
    
draft-heide-nwcrg-rlnc-00.txt
 Random Linear Network Coding (RLNC)-Based Symbol Representation
 
 draft-heide-nwcrg-rlnc-00.txt
 Date: 07/02/2018
 Authors: Janus Heide, Shirley Shi, Muriel Medard, Vince Chook
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the use of Random Linear Network Coding (RLNC) schemes for erasure correction in data transfer, with an emphasis on RLNC encoded symbol representations in data packets. Both block and sliding window RLNC code implementations are described. By providing erasure correction using randomly generated repair symbols, such RLNC-based schemes offer advantages in accommodating varying frame sizes and dynamically changing connections, reducing the need for feedback, and lowering the amount of state information needed at the sender and receiver.
    
draft-heitz-bess-evpn-option-b-01.txt
 Multi-homing and E-Tree in EVPN with Inter-AS Option B
 
 draft-heitz-bess-evpn-option-b-01.txt
 Date: 13/11/2017
 Authors: Jakob Heitz, Ali Sajassi, John Drake, Jorge Rabadan
 Working Group: Individual Submissions (none)
 Formats: txt xml
The BGP speaker that originates an EVPN Ethernet A-D per ES route is identified by the next-hop of the route. When the route is propagated by an ASBR as an Inter-AS Option B route, the ASBR overwrites the next-hop. This document describes a method to identify the originator of the route.
    
draft-heitz-idr-extra-extended-community-00.txt
 BGP Extra Extended Community
 
 draft-heitz-idr-extra-extended-community-00.txt
 Date: 05/03/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-hellstrom-slim-modality-grouping-01.txt
 Human Language Modality Grouping Semantics in Session Description Protocol
 
 draft-hellstrom-slim-modality-grouping-01.txt
 Date: 03/01/2018
 Authors: Gunnar Hellstrom
 Working Group: Individual Submissions (none)
 Formats: txt xml
When setting up a real-time communication session, there may be a need to indicate preference for which media and modality (spoken, written or signed) to use for language communications or a need to indicate preference for receiving the same language content simultaneously in two modalities. This document defines the semantics for grouping media for such purposes in the Session Description Protocol (SDP). The semantics defined in this document are based on the SDP Grouping Framework. Applications are for example negotiation the most suitable common modality or modalities for language communications in a real-time session. The indications are specified for the sending and receiving direction separately.
    
draft-herbert-6man-icmp-limits-03.txt
 ICMPv6 errors for discarding packets due to processing limits
 
 draft-herbert-6man-icmp-limits-03.txt
 Date: 15/01/2018
 Authors: Tom Herbert
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication so it cannot take action to address the cause of discarded packets. This document defines ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may be able to modify what it sends in future packets to avoid subsequent packet discards.
    
draft-herbert-fast-00.txt
 Firewall and Service Tickets
 
 draft-herbert-fast-00.txt
 Date: 11/01/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Firewalls and Service Tickets protocol. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network service to be applied. Applications request tickets from a local agent in the network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to a packets. A single ticket may provide both firewall and service ticket information. Tickets are sent in either IPv6 Destination options or Hop-by-Hop options.
    
draft-herbert-idgroups-00.txt
 Identifier groups
 
 draft-herbert-idgroups-00.txt
 Date: 03/02/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a means to create logical identifier groups to manage identifiers in a mapping system for identifier-locator protocols. An identifier group consists of identifiers that have similar properties in the context of the mapping system. Identifier groups facilitate bulk operations on the mapping system that would affect multiple identifiers. A primary use case for this is to facilitate mobility of devices that are associated with possibly thousands or even millions of identifiers.
    
draft-herbert-ila-ilamp-00.txt
 Identifier Locator Addressing Mapping Protocol
 
 draft-herbert-ila-ilamp-00.txt
 Date: 21/12/2017
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
Identifier-locator protocols rely on a mapping system that is able to map identifiers to locators. ILA nodes that perform ILA translations need to access the mapping system via a protocol. This document specifies the ILA Mapping Protocol that is used by ILA forwarding nodes and hosts to populate and maintain a cache of ILA mappings.
    
draft-herbert-ila-mobile-01.txt
 Identifier Locator Addressing for Mobile User-Plane
 
 draft-herbert-ila-mobile-01.txt
 Date: 05/03/2018
 Authors: Tom Herbert, Kalyani Bogineni
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the applicability of Identifier Locator Addressing (ILA) to the user-plane of mobile networks. ILA allows a means to implement network overlays without the overhead, complexities, or anchor points associated with encapsulation. This solution facilitates highly efficient packet forwarding and provides low latency and scalability in mobile networks. ILA can be used in conjunction with techniques such as network slices and Network Function Virtualization to achieve optimal service based forwarding.
    
draft-herbert-ila-motivation-00.txt
 Identifier Locator Addressing: Problem areas,Motivation,and Use Cases
 
 draft-herbert-ila-motivation-00.txt
 Date: 22/01/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the problems, motivation, and use cases for Identifier-Locator Addressing.
    
draft-herbert-intarea-ila-01.txt
 Identifier-locator addressing for IPv6
 
 draft-herbert-intarea-ila-01.txt
 Date: 05/03/2018
 Authors: Tom Herbert, Petr Lapukhov
 Working Group: Individual Submissions (none)
 Formats: txt
This specification describes identifier-locator addressing (ILA) for IPv6. Identifier-locator addressing differentiates between location and identity of a network node. Part of an address expresses the immutable identity of the node, and another part indicates the location of the node which can be dynamic. Identifier-locator addressing can be used to efficiently implement overlay networks for network virtualization as well as solutions for use cases in mobility.
    
draft-herbert-ipv6-prefix-address-privacy-00.txt
 Privacy in IPv6 Network Prefix Assignment
 
 draft-herbert-ipv6-prefix-address-privacy-00.txt
 Date: 19/02/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses privacy concerns around network prefix assignment in IPv6. It evaluates the privacy threat, proposes a set of ideal criteria for strong privacy, and suggests solutions to achieve a high degree of privacy in addressing.
    
draft-hesmans-mptcp-socket-03.txt
 A socket API to control Multipath TCP
 
 draft-hesmans-mptcp-socket-03.txt
 Date: 05/03/2018
 Authors: benjamin.hesmans@uclouvain.be, Olivier Bonaventure, Fabien Duchene
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an enhanced socket API to allow applications to control the operation of a Multipath TCP stack.
    
draft-hevroni-oauth-seamless-flow-00.txt
 Seamless OAuth 2.0 Client Assertion Grant
 
 draft-hevroni-oauth-seamless-flow-00.txt
 Date: 24/03/2018
 Authors: Omer Hevroni
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines the use of a One Time Password, encoded as JSON Web Token (JWS) Bearer Token, as a means for requesting an OAuth 2.0 access token as well as for client authentication.
    
draft-hfa-bier-pim-signaling-01.txt
 PIM Signaling Through BIER Core
 
 draft-hfa-bier-pim-signaling-01.txt
 Date: 07/02/2018
 Authors: Hooman Bidgoli, Andrew Dolganow, Jayant Kotalwar, Fengman Xu, IJsbrand Wijnands, mankamana mishra
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the procedure needed for PIM Joins and Prunes to be signaled through a BIER core. Allowing PIM routers to run traditional PIM multicast services through a BIER core.
    
draft-hinden-ipv4flag-04.txt
 IPv6 Router Advertisement IPv6-Only Flag
 
 draft-hinden-ipv4flag-04.txt
 Date: 16/04/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 RFC5175.
    
draft-hl-dnsop-cache-filling-00.txt
 Additional Method for Filling DNS Caches
 
 draft-hl-dnsop-cache-filling-00.txt
 Date: 02/03/2018
 Authors: Paul Hoffman, Matt Larson
 Working Group: Individual Submissions (none)
 Formats: txt
DNS recursive resolvers do not always have access to the authoritative resolvers from which they need to get information. For example, when the DNS root servers are under DDoS attack, a recursive resolver may not be able to get an answer from any of the root servers. This document describes how resolvers can populate their caches with zone information, and keep their cache populated, using out-of-band mechanisms that do not rely on the DNS protocol. The protocol is primarily designed for the root zone, but can apply to any zone that wants to participate by publishing values to be cached.
    
draft-hodges-webauthn-registries-01.txt
 Registries for Web Authentication (WebAuthn)
 
 draft-hodges-webauthn-registries-01.txt
 Date: 28/02/2018
 Authors: Jeff Hodges, Giridhar Mandyam, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines IANA registries for W3C Web Authentication attestation statement formats and extension identifiers.
    
draft-hoehlhubmer-https-addon-07.txt
 Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol
 
 draft-hoehlhubmer-https-addon-07.txt
 Date: 25/11/2013
 Authors: Walter Hoehlhubmer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations.
    
draft-hoehrmann-cp-collation-01.txt
 The i;codepoint collation
 
 draft-hoehrmann-cp-collation-01.txt
 Date: 14/09/2010
 Authors: Bjoern Hoehrmann
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations.
    
draft-hof-trans-cross-00.txt
 STH Cross Logging
 
 draft-hof-trans-cross-00.txt
 Date: 15/11/2017
 Authors: Benjamin Hof
 Working Group: Individual Submissions (none)
 Formats: txt xml
A malicious Certificate Transparency (CT) log can offer a modified tree to a client in a "split view" attack. This document proposes to extend CT by submitting Signed Tree Heads (STH) into another log, run by a different operator. Auditors and monitors can use these cross logged STHs to detect split view attacks by the log.
    
draft-hoffman-andrews-caa-simplification-03.txt
 DNS Certification Authority Authorization (CAA) Resource Record
 
 draft-hoffman-andrews-caa-simplification-03.txt
 Date: 23/02/2018
 Authors: Phillip Hallam-Baker, Rob Stradling, Jacob Hoffman-Andrews
 Working Group: Limited Additional Mechanisms for PKIX and SMIME (lamps)
 Formats: txt xml
The Certification Authority Authorization (CAA) DNS Resource Record allows a DNS domain name holder to specify one or more Certification Authorities (CAs) authorized to issue certificates for that domain. CAA Resource Records allow a public Certification Authority to implement additional controls to reduce the risk of unintended certificate mis-issue. This document defines the syntax of the CAA record and rules for processing CAA records by certificate issuers.
    
draft-hoffman-c2pq-03.txt
 The Transition from Classical to Post-Quantum Cryptography
 
 draft-hoffman-c2pq-03.txt
 Date: 12/02/2018
 Authors: Paul Hoffman
 Working Group: Crypto Forum (cfrg)
 Formats: txt
Quantum computing is the study of computers that use quantum features in calculations. For over 20 years, it has been known that if very large, specialized quantum computers could be built, they could have a devastating effect on asymmetric classical cryptographic algorithms such as RSA and elliptic curve signatures and key exchange, as well as (but in smaller scale) on symmetric cryptographic algorithms such as block ciphers, MACs, and hash functions. There has already been a great deal of study on how to create algorithms that will resist large, specialized quantum computers, but so far, the properties of those algorithms make them onerous to adopt before they are needed. Small quantum computers are being built today, but it is still far from clear when large, specialized quantum computers will be built that can recover private or secret keys in classical algorithms at the key sizes commonly used today. It is important to be able to predict when large, specialized quantum computers usable for cryptanalysis will be possible so that organization can change to post-quantum cryptographic algorithms well before they are needed. This document describes quantum computing, how it might be used to attack classical cryptographic algorithms, and possibly how to predict when large, specialized quantum computers will become feasible.
    
draft-hoffman-dns-in-json-14.txt
 Representing DNS Messages in JSON
 
 draft-hoffman-dns-in-json-14.txt
 Date: 18/04/2018
 Authors: Paul Hoffman
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
Some applications use DNS messages, or parts of DNS messages, as data. For example, a system that captures DNS queries and responses might want to be able to easily search those without having to decode the messages each time. Another example is a system that puts together DNS queries and responses from message parts. This document describes a general format for DNS message data in JSON. Specific profiles of this document can be described in other documents for specific applications and usage scenarios.
    
draft-hoffman-simplednsjson-01.txt
 Simple DNS Queries and Responses in JSON
 
 draft-hoffman-simplednsjson-01.txt
 Date: 27/11/2017
 Authors: Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
This draft is now a tombstone. The -00 version of this document has a likely-bad suggestion of how encode DNS queries for A and AAAA RRtypes, and only for those RRtypes, in JSON. The author no longer recommends to do this.
    
draft-hohendorf-secure-sctp-25.txt
 Secure SCTP
 
 draft-hohendorf-secure-sctp-25.txt
 Date: 04/03/2018
 Authors: Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP.
    
draft-hollenbeck-regext-rdap-openid-07.txt
 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect
 
 draft-hollenbeck-regext-rdap-openid-07.txt
 Date: 17/04/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-holmberg-sipcore-sip-push-03.txt
 Push Notification with the Session Initiation Protocol (SIP)
 
 draft-holmberg-sipcore-sip-push-03.txt
 Date: 23/11/2017
 Authors: Christer Holmberg
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes how push notification mechanisms can be used to wake up suspended Session Initiation Protocol (SIP) User Agents (UAs), in order to be able to receive and generate SIP requests. The document defines new SIP URI parameters, that can be used in a SIP REGISTER request to provide push notification information from the SIP User Agent (UA) to the SIP entity (realized as a SIP proxy in this document) that will send a push request to the push server in order to trigger a push notification towards the SIP UA.
    
draft-homma-coms-slice-gateway-01.txt
 Gateway Function for Network Slicing
 
 draft-homma-coms-slice-gateway-01.txt
 Date: 05/03/2018
 Authors: Shunsuke Homma, Xavier de Foy, A. Galis
 Working Group: Individual Submissions (none)
 Formats: xml 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-dmm-5gs-id-loc-coexistence-00.txt
 Co-existence of 3GPP 5GS and Identifier Locator Separation Solution
 
 draft-homma-dmm-5gs-id-loc-coexistence-00.txt
 Date: 17/03/2018
 Authors: Shunsuke Homma, Kenta Kawakami, Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an approach to introduce Identifier Locator Separation solution into 3GPP 5GS with low-impact on its specification, and shows the features and considerations of this approach.
    
draft-honeywell-ctp-04.txt
 Cloud Tunneling Protocol (CTP)
 
 draft-honeywell-ctp-04.txt
 Date: 13/11/2017
 Authors: Piotr Romanczyk, Christopher Colicino, Michael Landi, Tomas Brodsky
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines operating semantics of the Cloud Tunneling Protocol (CTP). CTP enables a standardized mechanism for connecting Internet-of-Things (IoT) devices to hosted cloud services. CTP provides a network efficient means to facilitate multiple concurrent data conversations over the same channel by providing multiplexed virtual sockets. The protocol allows for services on either endpoint to be advertised and accessible to each endpoint of the CTP connection.
    
draft-hong-i2nsf-nsf-monitoring-data-model-03.txt
 YANG Data Model for Monitoring I2NSF Network Security Functions
 
 draft-hong-i2nsf-nsf-monitoring-data-model-03.txt
 Date: 21/03/2018
 Authors: Dongjin Hong, Jaehoon Jeong, Jinyong Kim, Susan Hares, Liang Xia, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a YANG data model for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) system. If the monitoring of NSFs is performed in a comrehensive way, it is possible to detect the indication of malicious activity, anomalous behavior or the potential sign of denial of service attacks in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only a data tree to specify an information model for monitoring NSFs, but also the corresponding YANG data model for monitoring NSFs.
    
draft-hong-icnrg-ccnx-nrs-01.txt
 CCNx Extension for Name Resolution Service
 
 draft-hong-icnrg-ccnx-nrs-01.txt
 Date: 05/03/2018
 Authors: jhong@etri.re.kr, Taewan You, Yong-Geun Hong
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-00.txt
 Architectural Considerations of ICN using Name Resolution Service
 
 draft-hong-icnrg-icnnrs-00.txt
 Date: 05/03/2018
 Authors: jhong@etri.re.kr, Taewan You, Yong-Geun Hong
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses architectural considerations and implications of Information-Centric Networking (ICN) related to the usage of the Name Resolution Service (NRS). It describes how ICN architecture changes and what implications are in the routing system when NRS is utilized in ICN.
    
draft-hongcs-6lo-sbcn-00.txt
 Scheduling to Increase Lifetime for Low Energy Body-Centric Wearable Networks
 
 draft-hongcs-6lo-sbcn-00.txt
 Date: 09/02/2018
 Authors: Choong Hong, ameen@khu.ac.kr, Seung Moon
 Working Group: Individual Submissions (none)
 Formats: txt
Recent advances in Internet of Things(IoT) have increased the usage of sensing technologies. Breakthroughs is microelectronics have increased the use of wearable devices to monitor human body functions and its surroundings. A typical wearable device has low resources in terms of power and processing capabilities. Reducing the energy consumption is one of the key design factors in a wearable network so that the devices may work for longer duration. Idle listening and overhearing are major causes of energy consumption. These issues can be resolved by maximizing the sleeping time of a device (switched off) and avoid unnecessary wakeup time (idle listening) to save energy. An external wakeup scheduling to handle the sleep/wakeup cycle of a device can be adapted. This document describes how a 2wakeup scheduling using an out-of-bound external wake up mechanism can work to successfully increase the lifetime of a typical body-centric wearable network (S-BCN).
    
draft-hope-bailie-http-payments-00.txt
 HTTP-Payments
 
 draft-hope-bailie-http-payments-00.txt
 Date: 30/10/2017
 Authors: Adrian Hope-Bailie
 Working Group: Individual Submissions (none)
 Formats: txt xml
HTTP-Payments describes a mechanism for passing a standardized payment request in the headers of an HTTP 402 response and the expected behaviour of HTTP clients that receive such a response. Feedback This specification is an early experiment in bringing the work of the W3C Web Payments working group to the HTTP protocol. It is maintained at https://github.com/adrianhopebailie/http-payments [1]. The work is inspired by work in the Interledger community on [HTTP-ILP]
    
draft-hou-6lo-plc-03.txt
 Transmission of IPv6 Packets over PLC Networks
 
 draft-hou-6lo-plc-03.txt
 Date: 11/12/2017
 Authors: Jianqiang Hou, Yong-Geun Hong, Xiaojun Tang
 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 the 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. As part of this technology, Narrowband PLC (NBPLC) is focused on the low- bandwidth and low-power scenarios that includes current standards such as ITU-T G.9903, IEEE 1901.2 and IEEE 1901.2a. This document describes how IPv6 packets are transported over constrained PLC networks.
    
draft-housley-cms-mix-with-psk-04.txt
 Using Pre-Shared Key (PSK) in the Cryptographic Message Syntax (CMS)
 
 draft-housley-cms-mix-with-psk-04.txt
 Date: 03/04/2018
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
The invention of a large-scale quantum computer would pose a serious challenge for the cryptographic algorithms that are widely deployed today. The Cryptographic Message Syntax (CMS) supports key transport and key agreement algorithms that could be broken by the invention of such a quantum computer. By storing communications that are protected with the CMS today, someone could decrypt them in the future when a large-scale quantum computer becomes available. Once quantum-secure key management algorithms are available, the CMS will be extended to support them, if current syntax the does not accommodated them. In the near-term, this document describes a mechanism to protect today's communication from the future invention of a large-scale quantum computer by mixing the output of key transport and key agreement algorithms with a pre-shared key.
    
draft-housley-cms-mts-hash-sig-08.txt
 Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS)
 
 draft-housley-cms-mts-hash-sig-08.txt
 Date: 18/12/2017
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the conventions for using the Merkle Tree Signatures (MTS) digital signature algorithm with the Cryptographic Message Syntax (CMS). The MTS algorithm is one form of hash-based digital signature.
    
draft-housley-hash-of-root-key-cert-extn-00.txt
 Hash Of Root Key Certificate Extension
 
 draft-housley-hash-of-root-key-cert-extn-00.txt
 Date: 02/03/2018
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a certificate extension that is carried in the self-signed certificate for a trust anchor, which is often called a Root Certification Authority (CA) certificate, to identify the next public key that will be used by the trust anchor.
    
draft-housley-suite-b-to-historic-04.txt
 Reclassification of Suite B Documents to Historic Status
 
 draft-housley-suite-b-to-historic-04.txt
 Date: 21/02/2018
 Authors: Russ Housley, Lydia Zieglar
 Working Group: Individual Submissions (none)
 Formats: txt
This document reclassifies the RFCs related to the U.S. National Security Agency (NSA) Suite B cryptographic algorithms as Historic, and it discusses the reasons for doing so. This document moves seven informational RFCs to Historic Status: RFC 5759, RFC 6239, RFC 6318, RFC 6379, RFC 6380, RFC 6403, and RFC 6460. In addition, this document moves three obsolete informational RFCs to Historic Status: RFC 4869, RFC 5008, and RFC 5430.
    
draft-housley-tls-tls13-cert-with-extern-psk-00.txt
 TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key
 
 draft-housley-tls-tls13-cert-with-extern-psk-00.txt
 Date: 01/03/2018
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a TLS 1.3 extension that allows a server to authenticate with a combination of a certificate and an external pre- shared key (PSK).
    
draft-hsblss-attic-ps-01.txt
 Access Technology Independent Connectivity and Mobility Control Problem Statement
 
 draft-hsblss-attic-ps-01.txt
 Date: 10/01/2018
 Authors: Dirk Hugo, Behcet Sarikaya, Saleem Bhatti, Marco Liebsch, Roland Schott, SungHoon Seo
 Working Group: Individual Submissions (none)
 Formats: txt
This document attempts to make the case for new work involving possibly a framework and protocols that need to be developed to be used among various virtualized functions and the end user which may be moving. First a set of functional requirements are developed and then these requirements are further elaborated in terms of potential engineering and design constraints. The need for the new work is described next.
    
draft-hspab-5gangip-atticps-00.txt
 IP Issues and Associated Gaps in Fifth Generation Wireless Networks
 
 draft-hspab-5gangip-atticps-00.txt
 Date: 29/01/2018
 Authors: Dirk Hugo, Behcet Sarikaya
 Working Group: Individual Submissions (none)
 Formats: txt
This document attempts to make the case for new work that need to be developed to be used among various virtualized functions and the end user which may be moving. First a set of use cases on tunneling, charging, mobility anchors are developed and then the steps of proposed new work is described next.
    
draft-hu-bier-bfd-00.txt
 BIER BFD
 
 draft-hu-bier-bfd-00.txt
 Date: 24/10/2017
 Authors: fangwei hu, Gregory Mirsky, Chang Liu
 Working Group: Individual Submissions (none)
 Formats: txt
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in BIER network.
    
draft-hu-rtgwg-cu-separation-yang-model-03.txt
 YANG Data Model for Configuration Interface of Control-Plane and User- Plane separation BNG
 
 draft-hu-rtgwg-cu-separation-yang-model-03.txt
 Date: 19/03/2018
 Authors: fangwei hu, RongRong Hua, Sujun Hu, Rong Gu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the YANG data model for operation management of Control-Plane and User-Plane separation BNG (Broadband Network Gateway).
    
draft-hu-spring-sr-tp-use-case-01.txt
 Segment Routing Transport Profile Use Case
 
 draft-hu-spring-sr-tp-use-case-01.txt
 Date: 04/03/2018
 Authors: fangwei hu, Quan Xiong, Gregory Mirsky, Weiqiang Cheng
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the use case and requirement of segment routing is used in MPLS-TP network.
    
draft-hu-spring-srv6-yang-00.txt
 YANG Data Model for SRv6
 
 draft-hu-spring-srv6-yang-00.txt
 Date: 24/10/2017
 Authors: Zhenbin Li, Satoru Matsushima, Katsuhiro Horiba
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage SRv6
    
draft-huang-bier-te-encapsulation-00.txt
 Encapsulation for BIER-TE
 
 draft-huang-bier-te-encapsulation-00.txt
 Date: 04/03/2018
 Authors: Rachel Huang, Toerless Eckert, Naiwen Wei, Pascal Thubert
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes an enhanced encapsulation for BIER to support BIER, BIER-TE and a control word.
    
draft-huang-bier-te-encapsulation-extension-00.txt
 Encapsulation and Extension for BIER-TE
 
 draft-huang-bier-te-encapsulation-extension-00.txt
 Date: 27/10/2017
 Authors: Rachel Huang, Nu Xia, Naiwen Wei
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes to extend the BIER packet format and some BIER-TE forwarding rules specified in BIER traffic engineering architecture.
    
draft-huang-detnet-single-path-pref-00.txt
 Single-path PREF
 
 draft-huang-detnet-single-path-pref-00.txt
 Date: 12/12/2017
 Authors: Daniel Huang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies PREF on the single path for low-rate traffic, and illustrates in details the implementation solutions as well as the impacts on the data plane specified in [I-D.ietf-detnet-dp-alt].
    
draft-huang-nvo3-vxlan-gpe-extension-for-vbng-01.txt
 VXLAN GPE Extension for Packets Exchange Between Control and User Plane of vBNG
 
 draft-huang-nvo3-vxlan-gpe-extension-for-vbng-01.txt
 Date: 29/10/2017
 Authors: Lu Huang, Sujun Hu, Zitao Wang, Ting Ao
 Working Group: Individual Submissions (none)
 Formats: txt
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-huitema-dnssd-privacyscaling-00.txt
 Privacy Extensions for DNS-SD
 
 draft-huitema-dnssd-privacyscaling-00.txt
 Date: 10/02/2018
 Authors: Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: xml txt
DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. The draft currently progressing in the DNSSD Working Group assumes peer-to-peer pairing between the service to be discovered and each of its client. This has good security properties, but create scaling issues. Each server needs to publish as many announcements as it has paired clients. Each client needs to process all announcements from all servers present in the network. This leads to large number of operations when each server is paired with many clients. Different designs are possible. For example, if there was only one server "discovery key" known by each authorized client, each server would only have to announce a single record, and clients would only have to process one response for each server that is present on the network. Yet, these designs will present different privacy profiles, and pose different management challenges. This draft analyses the tradeoffs between privacy and scaling in a set of different designs, using either shared secrets or public keys.
    
draft-huitema-quic-dnsoquic-03.txt
 Specification of DNS over Dedicated QUIC Connections
 
 draft-huitema-quic-dnsoquic-03.txt
 Date: 01/01/2018
 Authors: Christian Huitema, Melinda Shore, Allison Mankin, Sara Dickinson, Jana Iyengar
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-huitema-quic-mpath-req-01.txt
 QUIC Multipath Requirements
 
 draft-huitema-quic-mpath-req-01.txt
 Date: 07/01/2018
 Authors: Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the requirement and plausible architecture of QUIC multipath extensions. While the first version of QUIC is not scheduled to include multipath extensions, there are risks that decisions made in this first version might preclude some options that we may later find attractive. An early review of multipath extension requirements and issues should minimize that risk.
    
draft-hunt-secevent-sstp-00.txt
 Symmetric SET Transfer Protocol
 
 draft-hunt-secevent-sstp-00.txt
 Date: 22/03/2018
 Authors: Phil Hunt, Anthony Nadalin
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines how security event tokens (SETs) may be exchanged between a client and service provider using HTTP POST over TLS using a symmetric format. The specification supports three modes of operation: "push", "pull", and "push-pull" bi-directional SET exchange. The specification also defines a simple acknowledge mechanism allowing parties to confirm delivery.
    
draft-hunt-secevent-stream-mgmt-00.txt
 SET Security Event Stream Management and Provisioning
 
 draft-hunt-secevent-stream-mgmt-00.txt
 Date: 29/10/2017
 Authors: Phil Hunt
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification defines a "control plane" service which enables a client (e.g. an Event Receiver) to establish, monitor, and manage a Security Event Token Stream.
    
draft-huque-dnsop-multi-provider-dnssec-02.txt
 Multi Provider DNSSEC models
 
 draft-huque-dnsop-multi-provider-dnssec-02.txt
 Date: 19/03/2018
 Authors: Shumon Huque, Pallavi Aras, John Dickinson, Jan Vcelak
 Working Group: Individual Submissions (none)
 Formats: txt
Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment can have some challenges depending on the configuration and feature set in use. This document will present several deployment models that may be suitable.
    
draft-huque-dnssec-alg-nego-02.txt
 Algorithm Negotiation in DNSSEC
 
 draft-huque-dnssec-alg-nego-02.txt
 Date: 20/01/2018
 Authors: Shumon Huque, Haya Shulman, Shane Kerr
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a DNS extension that allows a DNS client to specify a list of DNSSEC algorithms, in preference order, that the client desires to use. A DNS server upon receipt of this extension can choose to selectively respond with DNSSEC signatures using the most preferred algorithm they support. This mechanism may make it easier for DNS zone operators to support signing zone data simultaneously with multiple DNSSEC algorithms, without significantly increasing the size of DNS responses. It will also allow an easier way to transition to new algorithms while still retaining support for older DNS validators that do not yet support the new algorithms.
    
draft-hyun-i2nsf-nsf-triggered-steering-05.txt
 Service Function Chaining-Enabled I2NSF Architecture
 
 draft-hyun-i2nsf-nsf-triggered-steering-05.txt
 Date: 05/03/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, Park Jung-Soo, Susan Hares
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
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-03.txt
 I2NSF Registration Interface YANG Data Model
 
 draft-hyun-i2nsf-registration-interface-dm-03.txt
 Date: 05/03/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, Park Jung-Soo
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This document describes an YANG data model for I2NSF registration interface between Security Controller and Developer's Management System. The data model is required for NSF instance registration and dynamic life cycle management of NSF instances.
    
draft-hyun-i2nsf-registration-interface-im-04.txt
 I2NSF Registration Interface Information Model
 
 draft-hyun-i2nsf-registration-interface-im-04.txt
 Date: 05/03/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, Park Jung-Soo
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
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 creation, registration, and deletion request 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-marnew-report-01.txt
 IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) Report
 
 draft-iab-marnew-report-01.txt
 Date: 19/02/2018
 Authors: Natasha Rooney, Spencer Dawkins
 Working Group: Internet Architecture Board (iab)
 Formats: xml txt
The MarNEW workshop aimed to discuss solutions for bandwidth optimisation on mobile networks for encrypted content, as current solutions rely on unencrypted content which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members and various organisations involved in the telecommunications industry including original equipment manufacturers and mobile network operators. The group discussed the current Internet encryption trends and deployment issues identified within the IETF, and the privacy needs of users which should be adhered. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed as well as analysing whether the current issues experienced on the transport layer are also playing a role here. Content providers and CDNs gave an honest view of their experiences delivery content with mobile network operators. Finally, technical responses to regulation was discussed to help the regulated industries relay the issues of impossible to implement or bad-for-privacy technologies back to regulators. A group of suggested solutions were devised which will be discussed in various IETF groups moving forward.
    
draft-icann-registrar-interfaces-00.txt
 ICANN Registrar Interfaces
 
 draft-icann-registrar-interfaces-00.txt
 Date: 22/03/2018
 Authors: Gustavo Lozano, Eduardo Alvarez
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents in order to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications.
    
draft-ichen-rtgwg-forwarding-policy-yang-00.txt
 Forwarding Policy YANG Model
 
 draft-ichen-rtgwg-forwarding-policy-yang-00.txt
 Date: 05/03/2018
 Authors: Ing-Wher Chen, Aseem Choudhary
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model to manage forwarding policies. The forwarding policy YANG model is based on the generic Quality-of-Service (Qos) policy YANG model ietf-qos-policy.yang, and includes augmented data nodes specific to forwarding policies.
    
draft-ideskog-assisted-token-00.txt
 OAuth 2.0 Assisted Token
 
 draft-ideskog-assisted-token-00.txt
 Date: 18/03/2018
 Authors: Jacob Ideskog, Travis Spencer
 Working Group: Individual Submissions (none)
 Formats: xml txt
The OAuth 2.0 authorization flow for Single Page Applications (SPAs), often referred to as the assisted token flow, enables OAuth clients to request user authorization written in scripting languages, like JavaScript, with a simplified integration compared to the implicit grant type flow. Communication does not rely on redirection of the user agent, but instead leverages HTML's iframe element, child windows, and the postMessage interface. This communication is done using an additional endpoint, the assisted token endpoint, which this document defines.
    
draft-idr-bgp-route-refresh-options-04.txt
 Extension to BGP's Route Refresh Message
 
 draft-idr-bgp-route-refresh-options-04.txt
 Date: 01/03/2018
 Authors: Keyur Patel, Aamod Vyavaharkar, Niloofar Fazlollahi, Tony Przygienda
 Working Group: Individual Submissions (none)
 Formats: txt xml
[RFC2918] defines a route refresh capability to be exchanged between BGP speakers. BGP speakers that support this capability are advertising that they can resend the entire BGP Adj-RIB-Out on receipt of a refresh request. By supporting this capability, BGP speakers are more flexible in applying any inbound routing policy changes as they no longer have to store received routes in their unchanged form or reset the session when an inbound routing policy change occurs. The route refresh capability is advertised per AFI, SAFI combination. There are newer AFI, SAFI types that have been introduced to BGP that support a variety of route types (e.g. IPv4/MVPN, L2VPN/EVPN). Currently, there is no way to request a subset of routes in a Route Refresh message for a given AFI, SAFI. This draft defines route refresh capability extensions that help BGP speakers to request a subset of routes for a given address family. This is expected to reduce the amount of update traffic being generated by route refresh requests as well as lessen the burden on the router servicing such requests.
    
draft-ietf-6lo-ap-nd-06.txt
 Address Protected Neighbor Discovery for Low-power and Lossy Networks
 
 draft-ietf-6lo-ap-nd-06.txt
 Date: 23/02/2018
 Authors: Pascal Thubert, Behcet Sarikaya, Mohit Sethi
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This document defines an extension to 6LoWPAN Neighbor Discovery (ND) [RFC6775][I-D.ietf-6lo-rfc6775-update] called Address Protected ND (AP-ND); AP-ND protects the owner of an address against address theft and impersonation inside a low-power and lossy network (LLN). Nodes supporting this extension compute a cryptographic Owner Unique Interface ID and associate it with one or more of their Registered Addresses. The Cryptographic ID uniquely identifies the owner of the Registered Address and can be used for proof-of-ownership. It is used in 6LoWPAN ND in place of the EUI-64-based unique ID that is associated with the registration. Once an address is registered with a Cryptographic ID, only the owner of that ID can modify the anchor state information of the Registered Address, and Source Address Validation can be enforced.
    
draft-ietf-6lo-backbone-router-06.txt
 IPv6 Backbone Router
 
 draft-ietf-6lo-backbone-router-06.txt
 Date: 23/02/2018
 Authors: Pascal Thubert
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This specification proposes proxy operations for IPv6 Neighbor Discovery on behalf of devices located on broadcast-inefficient wireless networks. A broadcast-efficient backbone running classical IPv6 Neighbor Discovery federates multiple wireless links to form a large MultiLink Subnet, but the broadcast domain does not need to extend to the wireless links for the purpose of ND operation. Backbone Routers placed at the wireless edge of the backbone proxy the ND operation and route packets from/to registered nodes, and wireless nodes register or are proxy-registered to the Backbone Router to setup proxy services in a fashion that is essentially similar to a classical Layer-2 association.
    
draft-ietf-6lo-deadline-time-01.txt
 Packet Delivery Deadline time in 6LoWPAN Routing Header
 
 draft-ietf-6lo-deadline-time-01.txt
 Date: 04/03/2018
 Authors: Lijo Thomas, P.M. Akshay, Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This document specifies a new type for the 6LoWPAN routing header containing the delivery deadline time for data packets. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks.
    
draft-ietf-6lo-nfc-09.txt
 Transmission of IPv6 Packets over Near Field Communication
 
 draft-ietf-6lo-nfc-09.txt
 Date: 08/01/2018
 Authors: Younghwan Choi, Yong-Geun Hong, Joo-Sang Youn, Dongkyun Kim, JinHyeock Choi
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LowPAN techniques.
    
draft-ietf-6lo-rfc6775-update-19.txt
 Registration Extensions for 6LoWPAN Neighbor Discovery
 
 draft-ietf-6lo-rfc6775-update-19.txt
 Date: 23/04/2018
 Authors: Pascal Thubert, Erik Nordmark, Samita Chakrabarti, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies including the backbone routers performing proxy Neighbor Discovery in a low power network.
    
draft-ietf-6lo-use-cases-04.txt
 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases
 
 draft-ietf-6lo-use-cases-04.txt
 Date: 05/03/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-ndpioiana-02.txt
 IPv6 ND PIO Flags IANA considerations
 
 draft-ietf-6man-ndpioiana-02.txt
 Date: 10/01/2018
 Authors: Ole Troan
 Working Group: IPv6 Maintenance (6man)
 Formats: xml txt
The Prefix Information Option in the IPv6 Neighbor Discovery Router Advertisement defines an 8-bit flag field with two flags defined and the remaining 6 bits reserved (Reserved1). RFC 6275 has defined a new flag from this field without creating a IANA registry or updating RFC 4861. The purpose of this document is to request that IANA to create a new registry for the PIO flags to avoid potential conflict in the use of these flags. This document updates RFC 4861.
    
draft-ietf-6man-rfc6434-bis-08.txt
 IPv6 Node Requirements
 
 draft-ietf-6man-rfc6434-bis-08.txt
 Date: 20/03/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-12.txt
 IPv6 Segment Routing Header (SRH)
 
 draft-ietf-6man-segment-routing-header-12.txt
 Date: 20/04/2018
 Authors: Stefano Previdi, Clarence Filsfils, John Leddy, Satoru Matsushima, daniel.voyer@bell.ca
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
Segment Routing (SR) allows a node to steer a packet through a controlled set of instructions, called segments, by prepending an SR header to the packet. A segment can represent any instruction, topological or service-based. SR allows a node to steer a flow through any path (topological, or application/service based) while maintaining per-flow state only at the ingress node to the SR domain. Segment Routing can be applied to the IPv6 data plane with the addition of a new type of Routing Extension Header. This document describes the Segment Routing Extension Header Type and how it is used by SR capable nodes.
    
draft-ietf-6tisch-6top-protocol-11.txt
 6top Protocol (6P)
 
 draft-ietf-6tisch-6top-protocol-11.txt
 Date: 31/03/2018
 Authors: Qin Wang, Xavier Vilajosana, Thomas Watteyne
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
This document defines the 6top Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer to the IEEE Std 802.15.4 TSCH medium access control layer. The 6top layer terminates the 6top Protocol defined in this document, and runs one of more 6top Scheduling Function(s). A 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. This document lists the requirements for an SF, but leaves the definition of SFs out of scope.
    
draft-ietf-6tisch-6top-sfx-01.txt
 6TiSCH Experimental Scheduling Function (SFX)
 
 draft-ietf-6tisch-6top-sfx-01.txt
 Date: 05/03/2018
 Authors: Diego Dujovne, Luigi Grieco, Maria Palattella, Nicola Accettura
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt
This document defines a Scheduling Function called "Experimental Scheduling Function" (SFX). SFX dynamically adapts the number of scheduled cells between neighbor nodes, based on the amount of currently allocated cells and the neighbor nodes' cell requirements. Neighbor nodes negotiate in a distributed neighbor-to-neighbor basis the number of cell(s) to be added/deleted. SFX uses the 6P signaling messages to add/delete cells in the schedule. This function selects the candidate cells from the schedule, defines which cells will be added/deleted and triggers the allocation/deallocation process.
    
draft-ietf-6tisch-architecture-13.txt
 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4
 
 draft-ietf-6tisch-architecture-13.txt
 Date: 29/11/2017
 Authors: Pascal Thubert
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
This document describes a network architecture that provides low- latency, low-jitter and high-reliability packet delivery. It combines a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of LowPower wireless deterministic applications.
    
draft-ietf-6tisch-dtsecurity-zerotouch-join-01.txt
 6tisch Zero-Touch Secure Join protocol
 
 draft-ietf-6tisch-dtsecurity-zerotouch-join-01.txt
 Date: 30/10/2017
 Authors: Michael Richardson, Benjamin Damm
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
This document describes a zero-touch 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 her is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security].
    
draft-ietf-6tisch-minimal-security-05.txt
 Minimal Security Framework for 6TiSCH
 
 draft-ietf-6tisch-minimal-security-05.txt
 Date: 05/03/2018
 Authors: Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
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 a short link-layer address. This specification defines the message format, a new Stateless-Proxy CoAP option, and configures the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework.
    
draft-ietf-6tisch-terminology-10.txt
 Terms Used in IPv6 over the TSCH mode of IEEE 802.15.4e
 
 draft-ietf-6tisch-terminology-10.txt
 Date: 02/03/2018
 Authors: Maria Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt
This document provides a glossary of terminology used in IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH). This document extends existing terminology documents for Low-power and Lossy Networks.
    
draft-ietf-ace-actors-06.txt
 An architecture for authorization in constrained environments
 
 draft-ietf-ace-actors-06.txt
 Date: 13/11/2017
 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-cbor-web-token-15.txt
 CBOR Web Token (CWT)
 
 draft-ietf-ace-cbor-web-token-15.txt
 Date: 19/03/2018
 Authors: Michael Jones, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: xml txt
CBOR Web Token (CWT) is a compact means of representing claims to be transferred between two parties. The claims in a CWT are encoded in the Concise Binary Object Representation (CBOR) and CBOR Object Signing and Encryption (COSE) is used for added application layer security protection. A claim is a piece of information asserted about a subject and is represented as a name/value pair consisting of a claim name and a claim value. CWT is derived from JSON Web Token (JWT) but uses CBOR rather than JSON.
    
draft-ietf-ace-coap-est-00.txt
 EST over secure CoAP (EST-coaps)
 
 draft-ietf-ace-coap-est-00.txt
 Date: 28/02/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) [RFC7030] is used as a certificate management protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) [RFC7252] for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST- coaps). This allows low-resource constrained devices to re-use existing EST functionality. Example low-resource use cases for EST are: secure bootstrapping and certificate enrollment.
    
draft-ietf-ace-cwt-proof-of-possession-02.txt
 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
 
 draft-ietf-ace-cwt-proof-of-possession-02.txt
 Date: 03/03/2018
 Authors: Michael Jones, Ludwig Seitz, Goeran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: xml txt
This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs.
    
draft-ietf-ace-dtls-authorize-03.txt
 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
 
 draft-ietf-ace-dtls-authorize-03.txt
 Date: 05/03/2018
 Authors: Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt xml
This specification defines a profile for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. The protocol relies on DTLS for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained node can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory.
    
draft-ietf-ace-oauth-authz-11.txt
 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
 
 draft-ietf-ace-oauth-authz-11.txt
 Date: 19/03/2018
 Authors: Ludwig Seitz, Goeran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined.
    
draft-ietf-ace-oscore-profile-01.txt
 OSCORE profile of the Authentication and Authorization for Constrained Environments Framework
 
 draft-ietf-ace-oscore-profile-01.txt
 Date: 05/03/2018
 Authors: Ludwig Seitz, Francesca Palombini, Martin Gunnarsson, Goeran Selander
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
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-12.txt
 Automatic Certificate Management Environment (ACME)
 
 draft-ietf-acme-acme-12.txt
 Date: 24/04/2018
 Authors: Richard Barnes, Jacob Hoffman-Andrews, Daniel McCarney, James Kasten
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
Certificates in PKI using X.509 (PKIX) are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certificate authorities in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a certification authority (CA) and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org).
    
draft-ietf-acme-email-smime-02.txt
 Extensions to Automatic Certificate Management Environment for end user S/MIME certificates
 
 draft-ietf-acme-email-smime-02.txt
 Date: 04/03/2018
 Authors: Alexey Melnikov
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.
    
draft-ietf-acme-email-tls-04.txt
 Extensions to Automatic Certificate Management Environment for email TLS
 
 draft-ietf-acme-email-tls-04.txt
 Date: 20/03/2018
 Authors: Alexey Melnikov
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by TLS email services.
    
draft-ietf-acme-service-provider-02.txt
 ACME Identifiers and Challenges for VoIP Service Providers
 
 draft-ietf-acme-service-provider-02.txt
 Date: 30/10/2017
 Authors: Mary Barnes, Chris Wendt
 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 VoIP service providers to support Secure Telephony Identity (STI).
    
draft-ietf-acme-star-03.txt
 Support for Short-Term,Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)
 
 draft-ietf-acme-star-03.txt
 Date: 03/03/2018
 Authors: Yaron Sheffer, Diego Lopez, Oscar de Dios, Antonio Pastor, Thomas Fossati
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an attacker. However the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating this sequence upon compromise. This memo proposes an ACME extension to enable the issuance of short- term and automatically renewed (STAR) certificates. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR.
    
draft-ietf-acme-telephone-01.txt
 ACME Identifiers and Challenges for Telephone Numbers
 
 draft-ietf-acme-telephone-01.txt
 Date: 30/10/2017
 Authors: Jon Peterson, Richard Barnes
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificate for telephonoe numbers.
    
draft-ietf-acme-tls-alpn-00.txt
 ACME TLS ALPN Challenge Extension
 
 draft-ietf-acme-tls-alpn-00.txt
 Date: 02/03/2018
 Authors: Roland Shoemaker
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol which allows for domain control validation using TLS.
    
draft-ietf-alto-cdni-request-routing-alto-02.txt
 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO
 
 draft-ietf-alto-cdni-request-routing-alto-02.txt
 Date: 18/03/2018
 Authors: Jan Seedorf, Yang Yang, Kevin Ma, Jon Peterson, Xiao Lin
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Content Delivery Networks Interconnection (CDNI) WG is defining a set of protocols to inter-connect CDNs, to achieve multiple goals such as extending the reach of a given CDN to areas that are not covered by that particular CDN. One component that is needed to achieve the goal of CDNI is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI) [RFC7336]. [RFC8008] has defined precisely the semantics of FCI and provided guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. In this document, we define an FCI protocol using the Application-Layer Traffic Optimization (ALTO) protocol.
    
draft-ietf-alto-cost-calendar-03.txt
 ALTO Cost Calendar
 
 draft-ietf-alto-cost-calendar-03.txt
 Date: 08/12/2017
 Authors: Sabine Randriamasy, Yang Yang, Qin Wu, Deng Lingli, Nico Schwan
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information in order to allow applications to make network informed decisions. The present draft extends the ALTO cost information so as to broaden the decision possibilities of applications to not only decide 'where' to connect to, but also 'when'. This is useful to applications that need to schedule their data transfers and connections and have a degree of freedom to do so. ALTO guidance to schedule application traffic can also efficiently help for load balancing and resources efficiency. Besides, the ALTO Cost Calendar allows to schedule the ALTO requests themselves and thus to save a number of ALTO transactions. This draft proposes new capabilities and attributes on filtered cost maps and endpoint cost maps enabling an ALTO Server to provide "Cost Calendars". These capabilities are applicable to ALTO metrics with time-varying values. With ALTO Cost Calendars, an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes are specified in the IRD and ALTO Server responses.
    
draft-ietf-alto-incr-update-sse-10.txt
 ALTO Incremental Updates Using Server-Sent Events (SSE)
 
 draft-ietf-alto-incr-update-sse-10.txt
 Date: 18/03/2018
 Authors: Wendy Roome, Y. Yang, Shiwei Chen
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. For example, an ALTO server can provide network and cost maps so that an ALTO client can use the maps to determine the costs between endpoints when choosing communicating endpoints. However, the ALTO protocol does not define a mechanism to allow an ALTO client to obtain updates to the information resources, other than by periodically re-fetching them. Because some information resources (e.g., the aforementioned maps) may be large (potentially tens of megabytes), and because only parts of the information resources may change frequently (e.g., only some entries in a cost map), complete re-fetching can be extremely inefficient. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients, to achieve two benefits: (1) Updates can be immediate, in that the server can send updates as soon as they are available; and (2) updates can be incremental, in that if only a small section of an information resource changes, the server can send just the changes.
    
draft-ietf-alto-path-vector-03.txt
 ALTO Extension: Path Vector Cost Type
 
 draft-ietf-alto-path-vector-03.txt
 Date: 05/03/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 several resources and services to provide clients with basic network information. However, the base ALTO protocol and latest extensions only provide end-to-end metrics, 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-03.txt
 ALTO Performance Cost Metrics
 
 draft-ietf-alto-performance-metrics-03.txt
 Date: 22/12/2017
 Authors: Qin Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt xml
Cost Metric is a basic concept in Application-Layer Traffic Optimization (ALTO). It is used in both the Cost Map Service and the Endpoint Cost Service. Different applications may benefit from different Cost Metrics. For example, a Resource Consumer may prefer Resource Providers that offer a low delay delivery to the Resource Consumer. However the base ALTO protocol [ALTO] has documented only one single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]). This document, proposes a set of Cost Metrics, derived and aggregated from routing protocols with different granularity and scope, such as BGP-LS,OSPF-TE and ISIS-TE, or from end-to-end traffic management tools. It currently documents Network Performance Cost Metrics reporting on network delay, jitter, packet loss, hop count, and bandwidth. These metrics may be exposed by an ALTO Server to allow applications to determine "where" to connect based on network performance criteria. Additional Cost Metrics involving ISP specific considerations or other network technologies may be documented in further versions of this draft.
    
draft-ietf-alto-unified-props-new-03.txt
 Unified Properties for the ALTO Protocol
 
 draft-ietf-alto-unified-props-new-03.txt
 Date: 05/03/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 other entity domains, and by presenting those properties as maps, similar to the network and cost maps in ALTO.
    
draft-ietf-alto-xdom-disc-02.txt
 Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
 
 draft-ietf-alto-xdom-disc-02.txt
 Date: 05/03/2018
 Authors: Sebastian Kiesel, Martin Stiemerling
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be needed to discover an ALTO server outside of the own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (i.e., "ALTO: http" or "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URI(s) of information resources related to that IP address or prefix.
    
draft-ietf-anima-autonomic-control-plane-13.txt
 An Autonomic Control Plane (ACP)
 
 draft-ietf-anima-autonomic-control-plane-13.txt
 Date: 17/12/2017
 Authors: Toerless Eckert, Michael Behringer, Steinthor Bjarnason
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
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 OAM (Operations Administration and Management) communications over a network that is secure and reliable even when the network is not configured, or not misconfigured.
    
draft-ietf-anima-bootstrapping-keyinfra-14.txt
 Bootstrapping Remote Secure Key Infrastructures (BRSKI)
 
 draft-ietf-anima-bootstrapping-keyinfra-14.txt
 Date: 14/04/2018
 Authors: Max Pritikin, Michael Richardson, Michael Behringer, Steinthor Bjarnason, Kent Watsen
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
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-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-01.txt
 Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)
 
 draft-ietf-anima-grasp-api-01.txt
 Date: 03/03/2018
 Authors: Brian Carpenter, Bing Liu, Wendong Wang, Xiangyang Gong
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
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-06.txt
 A Reference Model for Autonomic Networking
 
 draft-ietf-anima-reference-model-06.txt
 Date: 23/02/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. 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-anima-stable-connectivity-10.txt
 Using Autonomic Control Plane for Stable Connectivity of Network OAM
 
 draft-ietf-anima-stable-connectivity-10.txt
 Date: 05/02/2018
 Authors: Toerless Eckert, Michael Behringer
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
OAM (Operations, Administration and Maintenance - as per BCP161, (RFC6291) processes for data networks are often subject to the problem of circular dependencies when relying on connectivity provided by the network to be managed for the OAM purposes. Provisioning while bringing up devices and networks tends to be more difficult to automate than service provisioning later on, changes in core network functions impacting reachability cannot be automated because of ongoing connectivity requirements for the OAM equipment itself, and widely used OAM protocols are not secure enough to be carried across the network without security concerns. This document describes how to integrate OAM processes with an autonomic control plane in order to provide stable and secure connectivity for those OAM processes. This connectivity is not subject to aforementioned circular dependencies.
    
draft-ietf-anima-voucher-07.txt
 Voucher Profile for Bootstrapping Protocols
 
 draft-ietf-anima-voucher-07.txt
 Date: 24/01/2018
 Authors: Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document defines an artifact format as a YANG-defined JSON document that has been signed using a CMS structure. Other YANG- derived formats are possible. The voucher artifact is normally generated by the pledge's manufacturer (i.e. the Manufacturer Authorized Signing Authority). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.
    
draft-ietf-avtcore-cc-feedback-message-01.txt
 RTP Control Protocol (RTCP) Feedback for Congestion Control
 
 draft-ietf-avtcore-cc-feedback-message-01.txt
 Date: 05/03/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-05.txt
 Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams
 
 draft-ietf-avtcore-multiplex-guidelines-05.txt
 Date: 30/10/2017
 Authors: Magnus Westerlund, Bo Burman, Colin Perkins, Harald Alvestrand, Roni Even, Hui Zheng
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt xml
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-06.txt
 Frame Marking RTP Header Extension
 
 draft-ietf-avtext-framemarking-06.txt
 Date: 30/10/2017
 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-03.txt
 Applicability of the Babel routing protocol
 
 draft-ietf-babel-applicability-03.txt
 Date: 07/04/2018
 Authors: Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
Where we argue that, although OSPF and IS-IS are fine protocols, there exists a space where the Babel routing protocol (RFC 6126bis) is useful.
    
draft-ietf-babel-information-model-02.txt
 Babel Information Model
 
 draft-ietf-babel-information-model-02.txt
 Date: 05/04/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-04.txt
 The Babel Routing Protocol
 
 draft-ietf-babel-rfc6126bis-04.txt
 Date: 29/10/2017
 Authors: Juliusz Chroboczek, David Schinazi
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.
    
draft-ietf-babel-source-specific-03.txt
 Source-Specific Routing in Babel
 
 draft-ietf-babel-source-specific-03.txt
 Date: 31/01/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-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-04.txt
 Updated processing of control flags for BGP VPLS
 
 draft-ietf-bess-bgp-vpls-control-flags-04.txt
 Date: 16/02/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.
    
draft-ietf-bess-datacenter-gateway-00.txt
 Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection
 
 draft-ietf-bess-datacenter-gateway-00.txt
 Date: 27/10/2017
 Authors: John Drake, Adrian Farrel, Eric Rosen, Keyur Patel, Luay Jalil
 Working Group: BGP Enabled ServiceS (bess)
 Formats: xml txt
Data centers have become critical components of the infrastructure used by network operators to provide services to their customers. Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load balancing, and resiliency reasons. Segment routing is a popular protocol mechanism for operating within a data center, but also for steering traffic that flows between two data center sites. In order that one data center site may load balance the traffic it sends to another data center site it needs to know the complete set of gateway routers at the remote data center, the points of connection from those gateways to the backbone network, and the connectivity across the backbone network. Segment routing may also be operated in other domains, such as access networks. Those domains also need to be connected across backbone networks through gateways. This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the segment routing domains to which it provides access, and also to advertise on behalf of each other gateway to the same segment routing domain.
    
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-03.txt
 Updates on EVPN BUM Procedures
 
 draft-ietf-bess-evpn-bum-procedure-updates-03.txt
 Date: 20/04/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-01.txt
 Framework for EVPN Designated Forwarder Election Extensibility
 
 draft-ietf-bess-evpn-df-election-framework-01.txt
 Date: 12/04/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 PE responsible for sending broadcast, unknown unicast and multicast (BUM) traffic to a multi-homed CE, 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-01.txt
 IGMP and MLD Proxy for EVPN
 
 draft-ietf-bess-evpn-igmp-mld-proxy-01.txt
 Date: 04/03/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-irb-mcast-00.txt
 EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding
 
 draft-ietf-bess-evpn-irb-mcast-00.txt
 Date: 13/02/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), i.e., a single IP subnet, to be distributed over multiple sites. The sites 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 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-01.txt
 Propagation of IPv6 Neighbor Advertisement Flags in EVPN
 
 draft-ietf-bess-evpn-na-flags-01.txt
 Date: 09/04/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-03.txt
 Optimized Ingress Replication solution for EVPN
 
 draft-ietf-bess-evpn-optimized-ir-03.txt
 Date: 23/02/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Ali Sajassi, Aldrin Isaac, Mukul Katiyar
 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-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-pref-df-01.txt
 Preference-based EVPN DF Election
 
 draft-ietf-bess-evpn-pref-df-01.txt
 Date: 09/04/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
RFC7432 defines the Designated Forwarder (DF) in (PBB-)EVPN networks 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 'service-carving' algorithm. While 'service-carving' 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 current RFC7432 DF election procedures so that the above requirements can be met.
    
draft-ietf-bess-evpn-prefix-advertisement-10.txt
 IP Prefix Advertisement in EVPN
 
 draft-ietf-bess-evpn-prefix-advertisement-10.txt
 Date: 27/02/2018
 Authors: Jorge Rabadan, Wim Henderickx, John Drake, Wen Lin, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
EVPN provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO-based 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-04.txt
 Operational Aspects of Proxy-ARP/ND in EVPN Networks
 
 draft-ietf-bess-evpn-proxy-arp-nd-04.txt
 Date: 09/04/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 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 (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, as explained in [RFC6820]. This document describes how the [RFC7432] 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-usage-09.txt
 Usage and applicability of BGP MPLS based Ethernet VPN
 
 draft-ietf-bess-evpn-usage-09.txt
 Date: 24/02/2018
 Authors: Jorge Rabadan, Senad Palislamovic, Wim Henderickx, Ali Sajassi, Jim Uttaro
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document discusses the usage and applicability of BGP MPLS based Ethernet VPN (EVPN) in a simple and fairly common deployment scenario. The different EVPN procedures are explained on the example scenario, analyzing the benefits and trade-offs of each option. This document is intended to provide a simplified guide for the deployment of EVPN networks.
    
draft-ietf-bess-evpn-vpls-seamless-integ-03.txt
 (PBB-)EVPN Seamless Integration with (PBB-)VPLS
 
 draft-ietf-bess-evpn-vpls-seamless-integ-03.txt
 Date: 18/04/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 the (PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for seamless integration of the 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 brownfield deployments of (PBB-)VPLS networks.
    
draft-ietf-bess-evpn-yang-05.txt
 Yang Data Model for EVPN
 
 draft-ietf-bess-evpn-yang-05.txt
 Date: 21/02/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-fat-pw-bgp-04.txt
 Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels
 
 draft-ietf-bess-fat-pw-bgp-04.txt
 Date: 02/03/2018
 Authors: Keyur Patel, Sami Boutros, Jose Liste, Bin Wen, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This draft defines protocol extensions required to synchronize flow label states among Provider Edges PE(s) when using the BGP-based signaling procedures. These protocol extensions are equally applicable to point-to-point Layer2 Virtual Private Networks (L2VPNs). This draft updates RFC 4761 by defining new flags in the Control Flags field of the Layer2 Info Extended Community.
    
draft-ietf-bess-l2l3-vpn-mcast-mib-14.txt
 L2L3 VPN Multicast MIB
 
 draft-ietf-bess-l2l3-vpn-mcast-mib-14.txt
 Date: 27/02/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-08.txt
 YANG Data Model for MPLS-based L2VPN
 
 draft-ietf-bess-l2vpn-yang-08.txt
 Date: 18/02/2018
 Authors: Himanshu Shah, Patrice Brissette, Ing-Wher 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-03.txt
 Yang Data Model for BGP/MPLS L3 VPNs
 
 draft-ietf-bess-l3vpn-yang-03.txt
 Date: 17/04/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-expl-track-09.txt
 Explicit Tracking with Wild Card Routes in Multicast VPN
 
 draft-ietf-bess-mvpn-expl-track-09.txt
 Date: 19/04/2018
 Authors: Andrew Dolganow, Jayant Kotalwar, Eric Rosen, Zhaohui Zhang
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The 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, and 7524.