Internet Society Frontpage

Search/Site Map Membership
About the Internet Standards
Publications Public Policy
About ISOC Education

Publications 

Become an ISOC Member

Internet Drafts - Sorted by name


    
draft-3k1n-6tisch-alice0-01.txt
 Autonomous Link-based TSCH Cell Scheduling
 
 draft-3k1n-6tisch-alice0-01.txt
 Date: 15/12/2016
 Authors: Seohyang Kim, Na Kim, Nguyen Lam, Seoul University
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the limitation of present TSCH cell scheduling methods which use centralized or decentralized approach. It firstly overview pros and cons of various cell scheduling approaches including centralized, decentralized and autonomous TSCH cell scheduling methods. It also suggest design considerations on devising autonomous scheduling approach to avoid unexpected confliction and increase channel utilization. For the last, it provides one example that reflects all design considerations mentioned.
    
draft-aanchal4-ntp-mac-03.txt
 Message Authentication Codes for the Network Time Protocol
 
 draft-aanchal4-ntp-mac-03.txt
 Date: 26/10/2016
 Authors: Aanchal Malhotra, Sharon Goldberg
 Working Group: Network Time Protocol (ntp)
 Formats: xml txt
The Network Time Protocol (NTP) RFC 5905 [RFC5905] uses a message authentication code (MAC) to cryptographically authenticate its UDP packets. Currently, NTP packets are authenticated by appending a 128-bit key to the NTP data, and hashing the result with MD5 to obtain a 128-bit tag. However, as discussed in [BCK] and [RFC6151], this is not a secure MAC. As such, this draft considers different secure MAC algorithms for use with NTP, evaluates their performance, and recommends the use of CMAC-AES [RFC4493]. We also suggest deprecating the use of MD5 as defined in [RFC5905] for authenticating NTP packets.
    
draft-abad-i2nsf-sdn-ipsec-flow-protection-01.txt
 Software-Defined Networking (SDN)-based IPsec Flow Protection
 
 draft-abad-i2nsf-sdn-ipsec-flow-protection-01.txt
 Date: 30/10/2016
 Authors: Rafael Lopez, Gabriel Lopez-Millan, Sowmini Varadhan
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the use case of providing IPsec-based flow protection by means of a Software-Defined Network (SDN) controller and raises the requirements to support this service. It considers two main scenarios: (i) gateway-to-gateway and (ii) host-to-gateway (Road Warrior). For the gateway-to-gateway scenario, this document describes a mechanism to support the distribution of IPsec information to flow-based Network Security Functions (NSFs) that implements IPsec to protect data traffic. between network resources to protect data traffic with IPsec and IKE, in intra and inter-SDN cases. The host-to-gateway case defines a mechanism to distribute IPsec information to the NSF to protect data with IPsec between an end user's device (host) and a gateway.
    
draft-abilash-quic-network-00.txt
 Network Enhancements for QUIC
 
 draft-abilash-quic-network-00.txt
 Date: 04/01/2017
 Authors: Abilash Menon, Ritesh Mukherjee
 Working Group: Individual Submissions (none)
 Formats: txt xml
QUIC aims to improve performance by multiplexing streams and various other enhancements [I-D.ietf-quic-transport]. QUIC performs better than existing transport protocols in most cases. However, its performance suffers compared to HTTP under very high bandwidth when large amounts of data needs to be downloaded [MEG2016]. This is because QUIC is an end to end protocol and provides no means for the intermediate network elements to contribute to QUIC improvements. This draft proposes a change to the QUIC protocol header that will allow session aware routers and other middleboxes to prioritize streams in QUIC packets, divert high priority streams to low loss paths, and adjust packet pacing on a per stream basis. This opens the door to many possible future in-network enhancements.
    
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-00.txt
 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery
 
 draft-acee-idr-lldp-peer-discovery-00.txt
 Date: 13/03/2017
 Authors: Acee Lindem, Keyur Patel, Shawn Zandi
 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-ospf-bgp-rr-00.txt
 OSPF Extensions for Advertising/Signaling BGP Route Reflector Information
 
 draft-acee-ospf-bgp-rr-00.txt
 Date: 13/03/2017
 Authors: Acee Lindem, Keyur Patel, Shawn Zandi
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an OSPF Router Information (RI) TLV to advertise the BGP Router Reflector capability and peering information. This information can be used by BGP Router Reflector clients to dynamically learn and establish sessions with BGP Router Reflectors in the routing domain.
    
draft-acee-ospf-geo-location-03.txt
 OSPF Extensions for Advertising/Signaling Geo Location Information
 
 draft-acee-ospf-geo-location-03.txt
 Date: 28/10/2016
 Authors: Acee Lindem, Naiming Shen, Enke Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an OSPF Router Information (RI) TLV to advertise the current Geo Coordinates of the OSPF router. For Point- to-Point (P2P)) and Point-to-Multi-Point (P2MP) networks, the Geo Coordinates can be used to dynamically computing the cost to neighbors. This is useful both from the standpoint of auto- configuration and situations where the OSPF routers are moving. The Geo Coordinates are also useful for other applications such as Traffic Engineering (TE) and network management.
    
draft-acee-rtgwg-yang-rib-extend-02.txt
 YANG Data Model for RIB Extensions
 
 draft-acee-rtgwg-yang-rib-extend-02.txt
 Date: 28/10/2016
 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 repair paths and additional attributes for routes and next-hops (aka, paths).
    
draft-adligo-hybi-asbp-02.txt
 Asynchronous Services Bus Protocol
 
 draft-adligo-hybi-asbp-02.txt
 Date: 07/10/2016
 Authors: Scott Morgan, Adligo Inc
 Working Group: Individual Submissions (none)
 Formats: txt
ASBP (Asynchronous Services Bus Protocol) is a simple command based application-level protocol for routing data and messages. ASBP is intended to allow implementation of fully Asynchronous Service Bus Architectures, in a simple standardized manor. ASBP is intended to be layered over WebSocket or HTTP. The protocol consists of a simple ASCII or UTF-8 key value(s) header and any arbitrary data (text, binary, XML, JSON, etc.), which the application's specific Command-Attendant or Command-Respondent processes. In addition this document touches on an extension to ASBP, CP (Conversation Protocol) a protocol used to facilitate communication between Asynchronous Service Busses implemented or hosted by different organizations. CP will be covered in more detail in another RFC still in progress. Internet-Draft This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at http://datatracker.ietf.org/drafts/current. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet- Drafts as reference material or to cite them other than as "work in progress.
    
draft-ahn-i2nsf-communications-security-use-case-01.txt
 Use Cases for the Communications Security using Interface to Network Security Functions
 
 draft-ahn-i2nsf-communications-security-use-case-01.txt
 Date: 31/10/2016
 Authors: Tae-Jin Ahn, sehuilee@kt.com, Kyoungyoul Kim, Utae Kim
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides use cases for the IP-based communications security using Interface to Network Security Functions (I2NSF). The use cases in this document cover the detection and prevention of the illegal authentication, call of VoIP/VoLTE and spam message.
    
draft-ahn-its-geo-architecture-00.txt
 Architectural Framework of IPv6-based Geographical Forwarding for ITS
 
 draft-ahn-its-geo-architecture-00.txt
 Date: 19/12/2016
 Authors: Sanghyun Ahn
 Working Group: Individual Submissions (none)
 Formats: txt
For IPv6-based ITS applications, ITS data packets are required to be delivered based on the geographical location information of the destination ITS node or area. In this draft, we describe the architecture of the IPv6-based Geographical Forwarding System (IGFS).
    
draft-ahn-its-geo-problem-00.txt
 Problem Statements of IPv6-based Geographical Forwarding for ITS
 
 draft-ahn-its-geo-problem-00.txt
 Date: 19/12/2016
 Authors: Sanghyun Ahn
 Working Group: Individual Submissions (none)
 Formats: txt
For the support of IPv6-based ITS applications, ITS data packets are required to be delivered based on the geographical location (longitude and latitude) information of the destination ITS node or area. Therefore, geographical forwarding mechanisms are preferred in the ITS environment. In this draft, we define the issues to be considered in delivering IPv6 ITS data based on geographical location.
    
draft-ahn-its-geocast-hbh-option-00.txt
 The IPv6 Hop-by-Hop Option for Geocast
 
 draft-ahn-its-geocast-hbh-option-00.txt
 Date: 19/12/2016
 Authors: Sanghyun Ahn
 Working Group: Individual Submissions (none)
 Formats: txt
For IPv6-based ITS applications, ITS data packets are required to be delivered to a specific destination area, which is called geocast. In this draft, a new IPv6 Hop-by-Hop option, the IPv6 Geocast Hop-by-Hop option, with the geographical information of the destination area and the forwarding mechanism information is defined.
    
draft-ahn-its-geounicast-hbh-option-00.txt
 The IPv6 Hop-by-Hop Option for Geographical Unicast
 
 draft-ahn-its-geounicast-hbh-option-00.txt
 Date: 19/12/2016
 Authors: Sanghyun Ahn
 Working Group: Individual Submissions (none)
 Formats: txt
For IPv6-based ITS applications, ITS data packets are required to be delivered to a specific destination ITS node. In this draft, a new IPv6 Hop-by-Hop option, the IPv6 Geo-unicast Hop-by-Hop option, with the geographical information of the destination ITS node and the forwarding mechanism information is defined.
    
draft-ahn-manet-dsr-crri-01.txt
 DSR Extensions for the Resolution of Cached Route Reply Implosion
 
 draft-ahn-manet-dsr-crri-01.txt
 Date: 13/11/2016
 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 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-aitken-ipfix-pre-defined-templates-00.txt
 Utilizing Pre-defined Templates with IPFIX
 
 draft-aitken-ipfix-pre-defined-templates-00.txt
 Date: 01/03/2017
 Authors: Paul Aitken
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a way to pre-define well-known IPFIX Templates which can be pre-shared with Collectors, thus avoiding the need for Exporters to send those Templates to Collectors. This saves export bandwidth and reduces Collector complexity.
    
draft-ali-ccamp-oducn-signal-type-00.txt
 RSVP-TE Extension for Beyond 100G Signal Types in G.709 Optical Transport Networks (OTNs)
 
 draft-ali-ccamp-oducn-signal-type-00.txt
 Date: 31/10/2016
 Authors: Zafar Ali, Manoj Kumar, Antonello Bonfanti, Akshaya Nadahalli, Fatai Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
RFCs 4328 and 7139 provide signaling extensions in Resource ReserVation Protocol - Traffic Engineering (RSVP-TE) to control the full set of Optical Transport Network (OTN) features. However, these specifications do not cover the additional Optical channel Data Unit (ODU) containers defined in G.709/Y.1331 for ODUC1, ODUC2, ODUC3, ODUC4, ODUC5, ODUC6, ODUC7, ODUC8 and ODUC9. This document defines new Signal Types for these additional containers.
    
draft-ali-ipv6rtr-reqs-02.txt
 Requirements for IPv6 Routers
 
 draft-ali-ipv6rtr-reqs-02.txt
 Date: 18/02/2017
 Authors: Zaid Kahn, John Brzozowski, Russ White
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Internet is not one network, but rather a collection of networks. The interconnected nature of these networks, and the nature of the interconneted systems that make up these networks, is often more fragile than it appears. Perhaps "robust but fragile" is an overstatement, but the actions of each vendor, implementor, and operator in such an interconneted environment can have a major impact on the stability of the overall Internet (as a system). The widespread adoption of IPv6 could, particularly, disrupt network operations, in a way that impacts the entire system. This time of transition is an opportune time to take stock of lessons learned through the operation of large scale networks on IPv4, and consider how to apply these lessons to IPv6. This document provides an overview of the design and architectural decisions that attend IPv6 deployment, and a set of IPv6 requirements for routers, switches, and middleboxes deployed in IPv6 networks. The hope of the editors and contributors is to provide the neccessary background to guide equipment manufacturers, protocol implemenetors, and network operators in effective IPv6 deployment.
    
draft-amsuess-core-request-tag-00.txt
 Request-Tag option
 
 draft-amsuess-core-request-tag-00.txt
 Date: 27/03/2017
 Authors: Christian Amsuess
 Working Group: Individual Submissions (none)
 Formats: xml txt
This memo describes an optional extension to the Constrained Application Protocol (CoAP, [RFC7252] and [RFC7959]) that allows matching of request blocks. This primarily serves to transfer the security properties that Object Security of CoAP (OSCOAP, [I-D.ietf-core-object-security]) provides for single requests to blockwise transfers. The security of blockwise transfer in OSCOAP is reflected on in a dedicated section.
    
draft-an-savi-mib-12.txt
 Definition of Managed Objects for SAVI Protocol
 
 draft-an-savi-mib-12.txt
 Date: 15/12/2016
 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-01.txt
 A Yang Data Model for SAVI Management
 
 draft-an-savi-yang-01.txt
 Date: 15/02/2017
 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-spring-poi-sr-02.txt
 Packet-Optical Integration in Segment Routing
 
 draft-anand-spring-poi-sr-02.txt
 Date: 22/12/2016
 Authors: Madhukar Anand, Sanjoy Bardhan, Ramesh Subrahmaniam, Jeff Tantsura
 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 the defined extensions of segment routing. 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-02.txt
 PCEP Extensions for MPSL-TE LSP Path Protection with stateful PCE
 
 draft-ananthakrishnan-pce-stateful-path-protection-02.txt
 Date: 09/01/2017
 Authors: Hariharan Ananthakrishnan, Siva Sivabalan, Colby Barth, Raveendra Torvi, Ina Minei, Edward Crabbe
 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-andreasen-dots-info-data-model-01.txt
 Distributed Denial-of-Service Open Threat Signaling (DOTS) Information and Data Model
 
 draft-andreasen-dots-info-data-model-01.txt
 Date: 31/10/2016
 Authors: Flemming Andreasen, Tirumaleswar Reddy
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines an information model and a data model for Distributed Denial-of-Service Open Threat Signaling (DOTS). The document specifies the Message and Information Elements that are transported between DOTS agents and their interconnected relationships. The primary purpose of the DOTS Information and Data Model is to address the DOTS requirements and DOTS use cases.
    
draft-andros-nfsv4-client-multipath-discovery-00.txt
 Trunking Discovery For Network File System Version 4.1
 
 draft-andros-nfsv4-client-multipath-discovery-00.txt
 Date: 09/02/2017
 Authors: Andy Adamson, Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: xml txt
Connection trunking is the use of multiple transport connections to increase data and request throughput between one NFS client and server pair. This document describes a means for an NFS version 4.1 client to discover NFS version 4.1 server multipath addresses that may be used for connection trunking.
    
draft-ao-sfc-overlay-01.txt
 Interworking SFC network and Overlay network
 
 draft-ao-sfc-overlay-01.txt
 Date: 12/03/2017
 Authors: Ting Ao, Gregory Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt
For SFC, it's generally transmitted over an overlay network.A Service Function Chain is an overlay carried over by an underlay network.This document defines necessary interworking stand-alone Network Virtual Edge and Service Forwarding Function entities to ensure proper handling of SFC traffic by the underlay network.
    
draft-ao-sfc-scalability-analysis-02.txt
 Analysis of the SFC scalability
 
 draft-ao-sfc-scalability-analysis-02.txt
 Date: 13/03/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 numerous 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 use cases on SFC scale-out and scale-in, and analysis of the requirements to support such capability.
    
draft-aoch-nvo3-edge-datacenter-00.txt
 The use case in Edge Datacenter network
 
 draft-aoch-nvo3-edge-datacenter-00.txt
 Date: 28/10/2016
 Authors: Ting Ao, Zhonghua Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduce the Edge Datacentet network, and describe some use cases about Edge Datacenter, discuss an important component in the Edge Datacenter:Service Gateway and its functions. Service Gateway as a flow distribution device in the Edge DC network, it needs to not only play a gateway of the edge Datacenter network, implementing coordination with existing technology,but also meets many new requirements. For example, acts as a traffic distributor to make sure the packets goes into Edge DC or Metro network, SDN forwarding, and as a leaf in the leaf-spin architecture.
    
draft-aranda-nfvrg-recursive-vnf-03.txt
 High-level VNF Descriptors using NEMO
 
 draft-aranda-nfvrg-recursive-vnf-03.txt
 Date: 09/03/2017
 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.
    
draft-aranda-sfc-dp-mobile-03.txt
 Service Function Chaining Dataplane Elements in Mobile Networks
 
 draft-aranda-sfc-dp-mobile-03.txt
 Date: 02/01/2017
 Authors: Pedro Gutierrez, Marco Gramaglia, Diego Lopez, Walter Haeffner
 Working Group: Individual Submissions (none)
 Formats: txt xml
The evolution of the network towards 5G implies a challenge for the infrastructure. The targeted services and the full deployment of virtualization in all segments of the network will be possible and necessary to provide some traffic-specific services near the next generation base stations where the radio is processed. Thus, service function chains that currently reside in the infrastructure of the Network operator (like, e.g. the Expeded Packet Gateway(EPG)) will be extended to the radio access network (RAN). In this draft we provide a non-exhaustive but representative list of service functions in 4G and 5G networks, and explore different scenarios for service-aware orchestration. We base on the problem statement [RFC7498] and architecture framework [RFC7665] of the SFC working group, as well on the existing mobile networks use cases [I-D.ietf-sfc-use-case-mobility] and the requirement gathering process of the ITU-R IMT 2020 [1] and different initiatives in Europe [2], Korea [3] and China [4] to anticipate network elements that will be needed in 5G networks. We then explore service-aware orchestration scenarios identifying where different network functions can be deployed in a fully virtualised future network, where both the core and the edge provide advanced virtualisation capabilities.
    
draft-aravind-radext-attribute-security-00.txt
 RADIUS Attribute Security
 
 draft-aravind-radext-attribute-security-00.txt
 Date: 17/02/2017
 Authors: Sanal Kariyezhath, Aravind Sridharan
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a simple method to provide security to RADIUS message attribute values.
    
draft-arends-dnsop-dnssec-algorithm-update-00.txt
 DNS Security (DNSSEC) DNSKEY Algorithm IANA Registry Updates
 
 draft-arends-dnsop-dnssec-algorithm-update-00.txt
 Date: 13/03/2017
 Authors: Roy Arends, Jakob Schlyter, Matt Larson
 Working Group: Individual Submissions (none)
 Formats: txt
The DNS Security Extensions (DNSSEC) require the use of cryptographic algorithm suites for generating digital signatures and cryptographic hashes over DNS data. The algorithms specified for use with DNSSEC are reflected in IANA registries. This document updates some entries in these registries. The main reason for these updates is to retire the use of SHA1.
    
draft-arkko-iesg-crossarea-03.txt
 Experiences from Cross-Area Work at the IETF
 
 draft-arkko-iesg-crossarea-03.txt
 Date: 06/02/2013
 Authors: Jari Arkko
 Working Group: General Area (gen)
 Formats: txt xml
This memo discusses the reasons for IETF work on topics that cross area boundaries. Such cross-area work presents challenges for the organization of the IETF as well as on how interested parties can participate the work. The memo also provides some suggestions on managing these challenges.
    
draft-arkko-ietf-finance-thoughts-00.txt
 Thoughts on IETF Finance Arrangements
 
 draft-arkko-ietf-finance-thoughts-00.txt
 Date: 28/02/2017
 Authors: Jari Arkko
 Working Group: Individual Submissions (none)
 Formats: txt
This short memo outlines the author's thoughts of current status and future development questions around IETF's financing mechanisms. This memo is also input for discussion that the IETF community should have. The memo is the first part of the author's goal to document the status and various challenges and opportunities associated with the IETF Administrative Activity (IASA), in the context of the so called "IASA 2.0" project. The memo has no particular official standing, nor does it claim to represent more than the authors' thinking at the time of writing.
    
draft-arkko-ietf-iasa-thoughts-00.txt
 Thoughts on IETF Administrative Support Activities (IASA)
 
 draft-arkko-ietf-iasa-thoughts-00.txt
 Date: 27/03/2017
 Authors: Jari Arkko
 Working Group: Individual Submissions (none)
 Formats: txt
This short memo outlines the author's thoughts about the challenges and opportunities with the IETF's administrative support activities, currently organised as part of the IETF Administrative Support Activities (IASA), IETF Administrative Oversight Committee (IAOC), and IETF Trust. This memo is just input for discussion that the IETF community should have. The memo is a part of the author's goal to document the status and various challenges and opportunities in the context of the so called "IASA 2.0" project. The memo has no particular official standing, nor does it claim to represent more than the authors' thinking at the time of writing.
    
draft-asaeda-icnrg-contrace-02.txt
 Contrace: Traceroute Facility for Content-Centric Network
 
 draft-asaeda-icnrg-contrace-02.txt
 Date: 13/03/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-asechoud-rtgwg-qos-model-00.txt
 YANG Model for QoS
 
 draft-asechoud-rtgwg-qos-model-00.txt
 Date: 28/10/2016
 Authors: Aseem Choudhary, Mahesh Jethanandani, Norm Strahle, Ebben Aries, I. Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG model for Quality of Service (QoS) configuration and operational parameters.
    
draft-ashesh-bfd-stability-05.txt
 BFD Stability
 
 draft-ashesh-bfd-stability-05.txt
 Date: 27/01/2017
 Authors: Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Juniper Networks, Mach Chen, Peng Fan
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD frame loss.
    
draft-atlas-community-hubs-00.txt
 IETF Community Hubs
 
 draft-atlas-community-hubs-00.txt
 Date: 16/02/2017
 Authors: Alia Atlas
 Working Group: Individual Submissions (none)
 Formats: xml txt
IETF Community Hubs are geographically-focused groups that facilitate participation in IETF activities. An IETF Community Hub may have different focuses, depending upon the interests of those participating, such as cross-area learning, outreach, mentoring, problem refinement, implementation and interop testing, and social. An IETF Community Hub's focuses and the energy of its coordinators will determine what types of activities are organized. Sample activities may include sessions of technical talks, social get- togethers, remote hubs during some IETF WG meetings, hackathons, etc.
    
draft-azgin-icnrg-ni-00.txt
 Enabling Network Identifier (NI) in Information Centric Networks to Support Optimized Forwarding
 
 draft-azgin-icnrg-ni-00.txt
 Date: 31/10/2016
 Authors: Aytac Azgin, Ravi Ravindran
 Working Group: Individual Submissions (none)
 Formats: xml txt
The objective of this proposal is to introduce the notion of network identifier (NI) in the ICN architecture. This is in addition to the existing names (i.e., content identifiers, CIs, or application identifiers, AIs, in general) that are currently used for both naming and routing/forwarding purposes. Network identifiers are needed considering the requirements on future networking architectures such as: (i) to support persistent names (or persistently named objects) and large-scale and high-speed mobility of any network entity (i.e, devices, services, and content), (ii) to accommodate different types of Internet of Things (IoT) services, many of which require low- latency performance, and enabling edge computing to support service virtualization, which will require support for large scale migration and replication of named resources, and (iii) to scale the ICN architecture to future Internet scale considering the exponentially increasing named entities. These considerations also require enabling a network based name resolution service for efficient and scalable routing. In the current draft, we begin by highlighting the issues associated with ICN networking when utilizing only the AIs, which include persistently named content, services, and devices. Next we discuss the function NI serves, and provide a discussion on the two current NI-based proposals, along with their scope and functionalities. This is with the objective of having a single NI construct for ICN that is flexible enough to adapt to different networking contexts.
    
draft-baba-iot-problems-02.txt
 Problems in and among industries for the prompt realization of IoT and safety considerations
 
 draft-baba-iot-problems-02.txt
 Date: 27/10/2016
 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-00.txt
 Report on Problem Solving Experiment for Realization of Web-API-based IoT
 
 draft-baba-iot-webapi-00.txt
 Date: 31/10/2016
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Koichi KUNITAKE
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-baeuerle-netnews-cancel-lock-03.txt
 Cancel-Locks in Netnews articles
 
 draft-baeuerle-netnews-cancel-lock-03.txt
 Date: 27/03/2017
 Authors: Michael Bauerle
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an extension to the Netnews Article Format that may be used to authenticate the cancelling and superseding of existing articles. If approved, this document updates RFC5537.
    
draft-bagnulo-tcpm-generalized-ecn-00.txt
 Adding Explicit Congestion Notification (ECN) to TCP control packets and TCP retransmissions
 
 draft-bagnulo-tcpm-generalized-ecn-00.txt
 Date: 29/09/2016
 Authors: Marcelo Bagnulo, Bob Briscoe
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an experimental modification to ECN to allow the use of ECN to the following TCP packets: SYNs, Pure ACKs, Window probes, FINs, RSTs and retransmissions.
    
draft-bailmir-ippm-twamp-dscp-ctrl-mon-02.txt
 Control and Monitoring Differentiated Service Code Point in Two-Way Active Measurement Protocol (TWAMP)
 
 draft-bailmir-ippm-twamp-dscp-ctrl-mon-02.txt
 Date: 21/02/2017
 Authors: Gregory Mirsky, Steve Baillargeon
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an optional extension for Two-Way Active Measurement Protocol (TWAMP) allowing control and monitoring of the Differentiated Service Code Point (DSCP) field in forward and reverse directions within single test session with the TWAMP-Test protocol. This document, if accepted, will be an update to the TWAMP core protocol specified in RFC 5357 and DSCP Monitoring mode defined in RFC 7750 .
    
draft-baker-ipv6-isis-dst-src-routing-06.txt
 IPv6 Source/Destination Routing using IS-IS
 
 draft-baker-ipv6-isis-dst-src-routing-06.txt
 Date: 18/10/2016
 Authors: Fred Baker, David Lamparter
 Working Group: IS-IS for IP Internets (isis)
 Formats: xml txt
This note describes the changes necessary for IS-IS to route IPv6 traffic from a specified prefix to a specified prefix.
    
draft-banghart-mile-rolie-csirt-00.txt
 Definition of ROLIE CSIRT Extension
 
 draft-banghart-mile-rolie-csirt-00.txt
 Date: 31/10/2016
 Authors: John Field, Stephen Banghart
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document extends the Resource-Oriented Lightweight Information Exchange (ROLIE) core to add the information type categories and related requirements needed to support Computer Security Incident Response Team (CSIRT) use cases. The indicator and incident information types are defined as ROLIE extensions. Additional supporting requirements are also defined that describe the use of specific formats and link relations pertaining to the new information types.
    
draft-banghart-sacm-rolie-softwaredescriptor-00.txt
 Definition of the ROLIE Software Descriptor Extension
 
 draft-banghart-sacm-rolie-softwaredescriptor-00.txt
 Date: 31/10/2016
 Authors: David Waltermire, Stephen Banghart
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document extends the Resource-Oriented Lightweight Information Exchange (ROLIE) core to add the information type category and related requirements needed to support Software Record and Software Inventory use cases. The 'software-descriptor' information type is defined as a ROLIE extension. Additional supporting requirements are also defined that describe the use of specific formats and link relations pertaining to the new information type.
    
draft-bao-oftest-cont-latency-00.txt
 Message Processing Latency Test for OpenFlow Controller
 
 draft-bao-oftest-cont-latency-00.txt
 Date: 22/12/2016
 Authors: Yaming Bao, Mike Cheng
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes the test method and test process for controller about the message processing latency.
    
draft-bardhan-spring-poi-sr-oam-01.txt
 OAM for Packet-Optical Integration in Segment Routing
 
 draft-bardhan-spring-poi-sr-oam-01.txt
 Date: 22/12/2016
 Authors: Sanjoy Bardhan, Madhukar Anand, Ramesh Subrahmaniam, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a list of functional requirements for transport segment OAM in Segment Routing (SR) based networks.
    
draft-barkai-lisp-nfv-09.txt
 LISP Based FlowMapping for Scaling NFV
 
 draft-barkai-lisp-nfv-09.txt
 Date: 08/12/2016
 Authors: sbarkai@gmail.com, 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-00.txt
 ACME Identifiers and Challenges for VoIP Service Providers
 
 draft-barnes-acme-service-provider-00.txt
 Date: 13/03/2017
 Authors: Mary Barnes, Chris Wendt
 Working Group: Individual Submissions (none)
 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-barnes-dane-uks-00.txt
 Unknown Key-Share Attacks on DNS-based Authentications of Named Entities (DANE)
 
 draft-barnes-dane-uks-00.txt
 Date: 09/10/2016
 Authors: Richard Barnes, Martin Thomson, Eric Rescorla
 Working Group: Individual Submissions (none)
 Formats: txt xml
Unknown key-share attacks are a class of attacks that allow an attacker to deceive one peer of a secure communication as to the identity of the remote peer. When used with traditional, PKI-based authentication, TLS-based applications are generally safe from unknown key-share attacks. DNS-based Authentication of Named Entities (DANE), however, proposes that applications perform a different set of checks as part of authenticating a TLS connection. As a result, DANE as currently specified is likely to lead to unknown key-share attacks when clients support DANE for authentication. We describe these risks and some simple mitigations.
    
draft-barth-pce-association-bidir-01.txt
 PCEP Extensions for Associated Bidirectional Label Switched Paths (LSPs) with Stateful PCE
 
 draft-barth-pce-association-bidir-01.txt
 Date: 12/03/2017
 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.
    
draft-bashandy-isis-srv6-extensions-00.txt
 IS-IS Extensions to Support Segment Routing over IPv6 Dataplane
 
 draft-bashandy-isis-srv6-extensions-00.txt
 Date: 10/03/2017
 Authors: Ahmed Bashandy, Clarence Filsfils, Les Ginsberg, Bruno Decraene
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane.
    
draft-bashandy-rtgwg-segment-routing-ti-lfa-00.txt
 Abstract
 
 draft-bashandy-rtgwg-segment-routing-ti-lfa-00.txt
 Date: 16/02/2017
 Authors: Ahmed Bashandy, Clarence Filsfils, Bruno Decraene, Stephane Litkowski, Pierre Francois
 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-bashir-idr-inter-provider-flowspec-actions-00.txt
 Inter-provider Propagation of BGP Flow specification Rules
 
 draft-bashir-idr-inter-provider-flowspec-actions-00.txt
 Date: 13/12/2016
 Authors: Ahmed Bashir
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a mechanism to propagate and handle flowspec messages beyond adjacent flowspec address family peers. The message propagation and handling techniques described in this draft allows the actions to be taken in the nearst point to DDoS Attack origin.
    
draft-bchv-rfc6890bis-05.txt
 Special-Purpose IP Address Registries
 
 draft-bchv-rfc6890bis-05.txt
 Date: 10/03/2017
 Authors: Ron Bonica, Michelle Cotton, Brian Haberman, Leo Vegoda
 Working Group: Internet Area (int)
 Formats: txt
This memo updates the IANA IPv6 Special-Purpose Address Registries to address issues raised by the definition of a global prefix. For completeness, this memo contains all the assignments made to the IANA Special-Purpose Address Registries. This memo obsoletes RFC 6890.
    
draft-bcx-behave-address-fmt-extension-10.txt
 Extended IPv6 Addressing for Encoding Port Range
 
 draft-bcx-behave-address-fmt-extension-10.txt
 Date: 28/01/2017
 Authors: Congxiao Bao, Xing Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses an extension of the algorithmic translation between IPv4 and IPv4-translatable IPv6 addresses. The extended address format contains transport-layer port set identification (PSID) which allows several IPv6 nodes to share a single IPv4 address with each node managing a different range of ports. This address format extension can be used for IPv4/IPv6 translation, as well as IPv4 over IPv6 tunneling.
    
draft-beauchamp-private-wire-10.txt
 A Session Initiation Protocol (SIP) INFO package for Private Wire
 
 draft-beauchamp-private-wire-10.txt
 Date: 02/12/2016
 Authors: Finlay Fraser, Chris Boulton
 Working Group: Individual Submissions (none)
 Formats: txt
Application level data exchanged using the SIP INFO method are supported and documented in specifications known as 'INFO Packages'. This document defines functionality associated with Session Initiation Protocol (SIP) Private Wire functionality and creates an 'INFO Package' for carrying such application level data.
    
draft-becker-core-coap-sms-gprs-06.txt
 Transport of CoAP over SMS
 
 draft-becker-core-coap-sms-gprs-06.txt
 Date: 19/02/2017
 Authors: Koojana Kuladinithi, Markus Becker, Kepeng Li, Thomas Poetsch
 Working Group: Individual Submissions (none)
 Formats: txt
Short Message Service (SMS) of mobile cellular networks is frequently used in Machine-To-Machine (M2M) communications, such as for telematic devices. The service offers small packet sizes and high delays just as other typical low-power and lossy networks (LLNs), i.e. 6LoWPANs. The design of the Constrained Application Protocol (CoAP, RFC7252), that took the limitations of LLNs into account, is thus also applicable to other transports. The adaptation of CoAP to SMS transport mechanisms is described in this document.
    
draft-bellis-dnsext-multi-qtypes-03.txt
 DNS Multiple QTYPEs
 
 draft-bellis-dnsext-multi-qtypes-03.txt
 Date: 26/10/2016
 Authors: Ray Bellis
 Working Group: Individual Submissions (none)
 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-01.txt
 EDNS X-Proxied-For
 
 draft-bellis-dnsop-xpf-01.txt
 Date: 09/01/2017
 Authors: Ray Bellis
 Working Group: Individual Submissions (none)
 Formats: xml txt
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 an option within the EDNS(0) Extension Mechanism for DNS that allows a DNS server to receive the original client source IP address when supplied by trusted proxies.
    
draft-bernardos-detnet-crosshaul-requirements-00.txt
 DETNET crosshauling requirements
 
 draft-bernardos-detnet-crosshaul-requirements-00.txt
 Date: 31/10/2016
 Authors: Carlos Bernardos, Antonio de la Oliva, Luca Cominardi, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
Future 5G networks will not make a clear distinction between fronthaul and backhaul transport networks, because varying portions of radio access network functionality might be moved toward the network as required for cost reduction and performance increase. This will pose additional challenges on the transport network, driving for a new design of integrated fronthaul and backhaul, usually referred to as crosshaul. This document present the crosshaul architecture framework being developed by the EU 5G-Crosshaul project, as well as identifies several key requirements for the transport network, with the goal of fostering discussion at the DETNET WG.
    
draft-bernardos-dmm-cmip-07.txt
 An IPv6 Distributed Client Mobility Management approach using existing mechanisms
 
 draft-bernardos-dmm-cmip-07.txt
 Date: 13/03/2017
 Authors: Carlos Bernardos, Antonio de la Oliva, Fabio Giust
 Working Group: Individual Submissions (none)
 Formats: txt
The use of centralized mobility management approaches -- such as Mobile IPv6 -- poses some difficulties to operators of current and future networks, due to the expected large number of mobile users and their exigent demands. All this has triggered the need for distributed mobility management alternatives, that alleviate operators' concerns allowing for cheaper and more efficient network deployments. This draft describes a possible way of achieving a distributed mobility behavior with Client Mobile IP, based on Mobile IPv6 and the use of Cryptographic Generated Addresses.
    
draft-bernardos-dmm-distributed-anchoring-08.txt
 PMIPv6-based distributed anchoring
 
 draft-bernardos-dmm-distributed-anchoring-08.txt
 Date: 30/09/2016
 Authors: Carlos Bernardos, Juan Zuniga
 Working Group: Individual Submissions (none)
 Formats: txt
Distributed Mobility Management solutions allow for setting up networks so that traffic is distributed in an optimal way and does not rely on centralized deployed anchors to provide IP mobility support. There are many different approaches to address Distributed Mobility Management, as for example extending network-based mobility protocols (like Proxy Mobile IPv6), or client-based mobility protocols (as Mobile IPv6), among others. This document follows the former approach, and proposes a solution based on Proxy Mobile IPv6 in which mobility sessions are anchored at the last IP hop router (called distributed gateway). The distributed gateway is an enhanced access router which is also able to operate as local mobility anchor or mobility access gateway, on a per prefix basis. The draft focuses on the required extensions to effectively support simultaneously anchoring several flows at different distributed gateways. This draft introduces the concept of distributed logical interface (at the distributed gateway), which is a software construct that allows to easily hide the change of anchor from the mobile node. Additionally, the draft describes how to provide session continuity in inter-domain scenarios in which dynamic tunneling or signaling between distributed gateways from different operators is not allowed.
    
draft-bernardos-dmm-pmip-08.txt
 A PMIPv6-based solution for Distributed Mobility Management
 
 draft-bernardos-dmm-pmip-08.txt
 Date: 13/03/2017
 Authors: Carlos Bernardos, Antonio de la Oliva, Fabio Giust
 Working Group: Individual Submissions (none)
 Formats: txt
The number of mobile users and their traffic demand is expected to be ever-increasing in future years, and this growth can represent a limitation for deploying current mobility management schemes that are intrinsically centralized, e.g., Mobile IPv6 and Proxy Mobile IPv6. For this reason it has been waved a need for distributed and dynamic mobility management approaches, with the objective of reducing operators' burdens, evolving to a cheaper and more efficient architecture. This draft describes multiple solutions for network-based distributed mobility management inspired by the well known Proxy Mobile IPv6.
    
draft-bernardos-nfvrg-multidomain-02.txt
 Multi-domain Network Virtualization
 
 draft-bernardos-nfvrg-multidomain-02.txt
 Date: 13/03/2017
 Authors: Carlos Bernardos, Luis Contreras, Ishan Vaishnavi, Robert Szabo
 Working Group: Individual Submissions (none)
 Formats: txt
This draft 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 project.
    
draft-bernardos-sfc-fog-ran-00.txt
 Service Function Chaining Use Cases in Fog RAN
 
 draft-bernardos-sfc-fog-ran-00.txt
 Date: 31/10/2016
 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-bernini-nfvrg-vnf-orchestration-03.txt
 VNF Pool Orchestration For Automated Resiliency in Service Chains
 
 draft-bernini-nfvrg-vnf-orchestration-03.txt
 Date: 04/10/2016
 Authors: Giacomo Bernini, Giada Landi, Diego Lopez, Pedro Aranda
 Working Group: Individual Submissions (none)
 Formats: txt
Network Function Virtualisation (NFV) aims at evolving the way network operators design, deploy and provision their networks by leveraging on standard IT virtualisation technologies to move and consolidate a wide range of network functions and services onto industry standard high volume servers, switches and storage. The primary target for operators, stimulated by the recent updates on NFV and SDN, is the network edge. In fact, operators are considering their future datacentres and Points of Presence (PoPs) as increasingly dynamic infrastructures where Virtualised Network Functions (VNFs) and on-demand chained services with high elasticity will be deployed. This document presents an orchestration framework for automated deployment of highly available VNF chains. Resiliency of VNFs and chained services is a key requirement for operators to improve, ease, automate and speed up services lifecycle management. The proposed VNFs orchestration framework is also positioned with respect to current NFV and Service Function Chaining (SFC) architectures and solutions.
    
draft-bertz-dime-policygroups-03.txt
 Diameter Policy Groups and Sets
 
 draft-bertz-dime-policygroups-03.txt
 Date: 09/03/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-01.txt
 Diameter Predicted Units
 
 draft-bertz-dime-predictunits-01.txt
 Date: 27/02/2017
 Authors: Lyle Bertz
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the conveyance of predicted usage information for proper dimensioning of network services that use Diameter based authorization.
    
draft-bertz-netmod-commonaugment-01.txt
 YANG extension for Common Augmentations
 
 draft-bertz-netmod-commonaugment-01.txt
 Date: 09/03/2017
 Authors: Lyle Bertz
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG extension to convey common schema augmentations.
    
draft-betts-netmod-framework-data-schema-uml-04.txt
 Framework for Deriving Interface Data Schema from UML Information Models
 
 draft-betts-netmod-framework-data-schema-uml-04.txt
 Date: 28/10/2016
 Authors: Malcolm Betts, Nigel Davis, Kam Lam, Eve Varma, Bernd Zeuner, Scott Mansfield, Paul Doolan
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This draft describes a framework for how purpose and protocol specific interfaces can be systematically derived from an underlying common information model, focusing upon the networking and forwarding domain. The benefit of using such an approach in interface specification development is to promote convergence, interoperability, and efficiency.
    
draft-bhaprasud-ippm-pm-02.txt
 Packet Loss measurement Model
 
 draft-bhaprasud-ippm-pm-02.txt
 Date: 05/03/2017
 Authors: Bharat Gaonkar, Giuseppe Fioccola, Qin Wu, Praveen Ananthasankaran
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines the loss measurement matrix models for service level packets on the network which can be implemented in different kind of network scenarios.
    
draft-bhati-intarea-frag-label-reassembly-00.txt
 Label Based IP Reassembly
 
 draft-bhati-intarea-frag-label-reassembly-00.txt
 Date: 25/10/2016
 Authors: ABHISHEK BHATI
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a faster mechanism to re-assemble IPv4 and IPv6 fragments when fragment labels are used instead of fragment offset to reassemble the packets.
    
draft-bhati-l2tpext-l2tpv4-00.txt
 Layer Two Tunneling Protocol - Version 4 (L2TPv4)
 
 draft-bhati-l2tpext-l2tpv4-00.txt
 Date: 25/10/2016
 Authors: ABHISHEK BHATI
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Layer Two Tunneling protocol (L2TPv4). L2TPv4 defines implementation friendly and more secured encapsulation headers for carrying multiple Layer 2 connections between two IP nodes.
    
draft-bhjl-x509-srv-03.txt
 Using a DNS SRV Record to Locate an X.509 Certificate Store
 
 draft-bhjl-x509-srv-03.txt
 Date: 16/01/2017
 Authors: Brian Haberman, John Levine
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a method to allow parties to locate X.509 certificate stores with Domain Name System Service records in order to retrieve certificates and certificate revocation lists. The primary purpose of such retrievals is to facilitate the association of X.509 and PGP public keys with e-mail addresses to allow for encrypted e-mail exchanges.
    
draft-bi-savi-problem-12.txt
 Problem Statement of SAVI Beyond the First Hop
 
 draft-bi-savi-problem-12.txt
 Date: 13/11/2016
 Authors: Jun Bi, Bingyang Liu
 Working Group: Individual Submissions (none)
 Formats: txt
IETF Source Address Validation Improvements (SAVI) working group is chartered for source address validation within the first hop from end hosts, i.e., preventing a node from spoofing the IP source address of another node in the same IP link. However, since SAVI requires the edge routers or switches to be upgraded, the deployment of SAVI will need a long time. During this transition period, some source address validation techniques beyond the first hop (SAVI-BF) may be needed to complement SAVI and protect the networks from spoofing based attacks. In this document, we first propose three desired features of the SAVI-BF techniques. Then we analyze the problems of the current SAVI-BF technique, ingress filtering. Finally, we discuss the directions that we can explore to improve SAVI-BF.
    
draft-bi-savi-wlan-11.txt
 A SAVI Solution for WLAN
 
 draft-bi-savi-wlan-11.txt
 Date: 27/01/2017
 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-birkholz-tuda-04.txt
 Time-Based Uni-Directional Attestation
 
 draft-birkholz-tuda-04.txt
 Date: 13/03/2017
 Authors: Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo documents the method and bindings used to conduct time- based uni-directional attestation between distinguishable endpoints over the network.
    
draft-birrane-dtn-ama-05.txt
 Asynchronous Management Architecture
 
 draft-birrane-dtn-ama-05.txt
 Date: 13/03/2017
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-bishop-httpbis-extended-settings-01.txt
 HTTP/2 Extended SETTINGS Extension
 
 draft-bishop-httpbis-extended-settings-01.txt
 Date: 15/11/2016
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: txt xml
HTTP/2 defines the SETTINGS frame to contain a single 32-bit value per setting. While this is sufficient to convey everything used in the core HTTP/2 specification, some protocols will require more complex values, such as arrays of code-points or strings. For such protocols, this extension defines a parallel to the SETTINGS frame, EXTENDED_SETTINGS, where the value of a setting is not a 32-bit value, but a variable-length opaque data blob whose interpretation is subject entirely to the definition of the protocol using it.
    
draft-bishop-httpbis-http2-additional-certs-03.txt
 Secondary Certificate Authentication in HTTP/2
 
 draft-bishop-httpbis-http2-additional-certs-03.txt
 Date: 27/03/2017
 Authors: Mike Bishop, Nick Sullivan, Martin Thomson
 Working Group: Individual Submissions (none)
 Formats: txt xml
TLS provides fundamental mutual authentication services for HTTP, supporting up to one server certificate and up to one client certificate associated to the session to prove client and server identities as necessary. This draft provides mechanisms for providing additional such certificates at the HTTP layer when these constraints are not sufficient. Many HTTP servers host content from several origins. HTTP/2 [RFC7540] permits clients to reuse an existing HTTP connection to a server provided that the secondary origin is also in the certificate provided during the TLS [I-D.ietf-tls-tls13] handshake. In many cases, servers will wish to maintain separate certificates for different origins but still desire the benefits of a shared HTTP connection. Similarly, servers may require clients to present authentication, but have different requirements based on the content the client is attempting to access. This document describes how TLS exported authenticators [I-D.sullivan-tls-exported-authenticator] can be used to provide proof of ownership of additional certificates to the HTTP layer to support both scenarios.
    
draft-bishop-quic-http-and-qpack-02.txt
 Header Compression for HTTP/QUIC
 
 draft-bishop-quic-http-and-qpack-02.txt
 Date: 08/02/2017
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-bjorklund-netmod-yang-tree-diagrams-00.txt
 YANG Tree Diagrams
 
 draft-bjorklund-netmod-yang-tree-diagrams-00.txt
 Date: 13/03/2017
 Authors: Martin Bjorklund, Lou Berger
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document captures the current syntax used in YANG module Tree Diagrams. The purpose of the document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language.
    
draft-bonica-intarea-eping-04.txt
 Extended Ping (Xping)
 
 draft-bonica-intarea-eping-04.txt
 Date: 03/03/2017
 Authors: Ron Bonica, Reji Thomas, J. Linkova, Chris Lenart
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a new diagnostic tool called Extended Ping (Xping). Network operators execute Xping to determine the status of a remote interface. In this respect, Xping is similar to Ping. Xping differs from Ping in that it does not require network reachability between itself and remote interface whose status is being queried. Xping relies on two new ICMP messages, called Extended Echo Request and Extended Echo Reply. Both ICMP messages are defined herein.
    
draft-bormann-cbor-tags-oid-06.txt
 Concise Binary Object Representation (CBOR) Tags and Techniques for Object Identifiers,UUIDs,Enumerations,Binary Entities,Regular Expressions,and Sets
 
 draft-bormann-cbor-tags-oid-06.txt
 Date: 13/03/2017
 Authors: Carsten Bormann, Sean Leonard
 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. Useful tags and techniques have emerged since the publication of RFC 7049; the present document makes use of CBOR's built-in major types to define and refine several useful constructs, without changing the wire protocol. This document adds object identifiers (OIDs) to CBOR with CBOR tags <> and <> [values TBD]. It is intended as the reference document for the IANA registration of the CBOR tags so defined. Useful techniques for enumerations and sets are presented (without new tags). As the documentation for binary UUIDs (tag 37), MIME entities (tag 36) and regular expressions (tag 35) RFC 7049 left much out, this document provides more comprehensive specifications.
    
draft-bormann-cbor-time-tag-00.txt
 Concise Binary Object Representation (CBOR) Tags for Time,Duration,and Period
 
 draft-bormann-cbor-time-tag-00.txt
 Date: 13/03/2017
 Authors: Carsten Bormann, Ben Gamari, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt
The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC3339 time) and tag 1 (Posix time [TIME_T], int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, as well as CBOR tags for duration and time period. It is intended as the reference document for the IANA registration of the CBOR tags defined.
    
draft-bormann-lpwan-cbor-template-00.txt
 Concise Binary Object Representation (CBOR) Tag for CBOR Templates
 
 draft-bormann-lpwan-cbor-template-00.txt
 Date: 11/01/2017
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. The present document makes use of this extensibility to define a CBOR tag for a variable within a CBOR data item, which then could be filled in by a separate process (e.g., from another CBOR data item).
    
draft-bormann-lwig-7228bis-00.txt
 Terminology for Constrained-Node Networks
 
 draft-bormann-lwig-7228bis-00.txt
 Date: 30/10/2016
 Authors: Carsten Bormann, 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-slipmux-00.txt
 Slipmux: Using an UART interface for diagnostics,configuration,and packet transfer
 
 draft-bormann-t2trg-slipmux-00.txt
 Date: 13/01/2017
 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-sworn-00.txt
 SWORN: Secure Wake on Radio Nudging
 
 draft-bormann-t2trg-sworn-00.txt
 Date: 27/03/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-bundled-signaling-alias-00.txt
 Signaling that a domain name is an alias of another one
 
 draft-bortzmeyer-bundled-signaling-alias-00.txt
 Date: 14/11/2016
 Authors: Stephane Bortzmeyer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document suggests a light-weight and semantics-free way to signal, in the DNS itself, that a domain name is actually an alias of another one (and therefore that they are member of the same bundle). REMOVE BEFORE PUBLICATION: this document should be discussed in the dnsbundled maiing list . The source of the document, as well as a list of open issues, is currently kept at Github [1].
    
draft-bortzmeyer-dprive-step-2-05.txt
 Next step for DPRIVE: resolver-to-auth link
 
 draft-bortzmeyer-dprive-step-2-05.txt
 Date: 20/12/2016
 Authors: Stephane Bortzmeyer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document examines the possible future work for the DPRIVE (DNS privacy) working group, specially in securing the resolver-to- authoritative name server link with TLS under DNS. It is not intended to be published as a RFC. 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-bosch-sieve-special-use-01.txt
 Sieve Email Filtering: Delivering to Special-Use Mailboxes
 
 draft-bosch-sieve-special-use-01.txt
 Date: 10/10/2016
 Authors: Stephan Bosch
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows clients to identify special-use mailboxes; e.g., where draft or sent messages should be put. This simplifies client configuration. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a test for checking whether a special-use attribute is assigned for a particular mailbox or any mailbox, and it adds the ability to file messages into an anonymous mailbox that has a particular special-use attribute assigned.
    
draft-boucadair-connectivity-provisioning-protocol-13.txt
 Connectivity Provisioning Negotiation Protocol (CPNP)
 
 draft-boucadair-connectivity-provisioning-protocol-13.txt
 Date: 08/12/2016
 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-lisp-bulk-04.txt
 LISP Mapping Bulk Retrieval
 
 draft-boucadair-lisp-bulk-04.txt
 Date: 03/02/2017
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
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. In addition, this document allows to request mappings that match destination IP prefixes, names, or AS numbers. This document updates RFC6830.
    
draft-boucadair-lisp-function-discovery-03.txt
 LISP Mapping Service Functions Discovery (LMSFD) using OSPF
 
 draft-boucadair-lisp-function-discovery-03.txt
 Date: 24/11/2016
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies extensions to the Open Shortest Path First (OSPF) protocol for the discovery of Locator/ID Separation Protocol (LISP) Mapping Service functions, especially the Map-Resolver (MR) and Map-Server (MS) LISP components.
    
draft-boucadair-lisp-itr-failure-03.txt
 Improving ITR Resiliency in Locator/ID Separation Protocol (LISP) Networks
 
 draft-boucadair-lisp-itr-failure-03.txt
 Date: 03/02/2017
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an extension to the Locator/ID Separation Protocol (LISP) to minimize LISP service disruption during Ingress Tunnel Routers (ITRs) failure events.
    
draft-boucadair-lisp-subscribe-04.txt
 LISP Subscription
 
 draft-boucadair-lisp-subscribe-04.txt
 Date: 03/02/2017
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: xml txt
Mapping Services in Locator/ID Separation Protocol (LISP) networks are key to proper LISP forwarding operation. When considering the deployment of LISP at large scale, these Mapping Services are even more crucial for the sake of the LISP forwarding efficiency. This document introduces two additional LISP messages that are meant to facilitate the dynamic discovery of Mapping Systems, improve Ingress Tunnel Routers (ITR) recovery times and optimize the solicitation of the LISP Mapping System as a function of the ITR location, in particular.
    
draft-boucadair-lisp-v6-compact-header-04.txt
 A Compact LISP Encapsulation Scheme to Transport IPv4 Packets over an IPv6 Network
 
 draft-boucadair-lisp-v6-compact-header-04.txt
 Date: 13/12/2016
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: xml txt
The encapsulation scheme used by the Locator/ID Separation Protocol (LISP) may sometimes raise MTU issues at the cost of possibly degrading the overall performance of the LISP network, especially in IPv6 migration contexts. This document proposes a new, more compact, encapsulation scheme that aims to accommodate such issues and facilitate LISP deployment for IPv6 migration purposes, in particular. This compact header may be considered to provide IPv4 over IPv6 connectivity for mobile LISP-capable devices.
    
draft-boucadair-mptcp-dhc-06.txt
 DHCP Options for Network-Assisted Multipath TCP (MPTCP)
 
 draft-boucadair-mptcp-dhc-06.txt
 Date: 26/10/2016
 Authors: Mohamed Boucadair, Christian Jacquenet, Tirumaleswar Reddy
 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 MPTCP Conversion Point (MCP). 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. MCPs 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 MPTCP Conversion Point(s) is explicitly configured on connected hosts. This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Multipath TCP (MPTCP) parameters.
    
draft-boucadair-mptcp-max-subflow-03.txt
 Negotiating the Maximum Number of Multipath TCP (MPTCP) Subflows
 
 draft-boucadair-mptcp-max-subflow-03.txt
 Date: 24/11/2016
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies an experimental Multipath TCP (MPTCP) option that is meant to negotiate the maximum number of subflows that can be established and maintained for a given MPTCP connection. The purpose is to minimize any possible performance degradation that can be induced by a possibly large number of establishment requests for additional subflows if the remote endpoint is not appropriately dimensioned to handle such requests.
    
draft-boucadair-mptcp-plain-mode-10.txt
 Extensions for Network-Assisted MPTCP Deployment Models
 
 draft-boucadair-mptcp-plain-mode-10.txt
 Date: 09/03/2017
 Authors: Mohamed Boucadair, Christian Jacquenet, Olivier Bonaventure, Denis Behaghel, stefano.secci@lip6.fr, Wim Henderickx, Robert Skog, Suresh Vinapamula, SungHoon Seo, Wouter Cloetens, Ullrich Meyer, Luis Contreras, Bart Peirens
 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 MPTCP Conversion Point (MCP). 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. MCPs 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 extensions for Network-Assisted MPTCP deployment models.
    
draft-boucadair-mptcp-radius-03.txt
 RADIUS Extensions for Network-Assisted Multipath TCP (MPTCP)
 
 draft-boucadair-mptcp-radius-03.txt
 Date: 26/10/2016
 Authors: Mohamed Boucadair, Christian Jacquenet
 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 MPTCP Conversion Point (MCP). 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. MCPs 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 MCPs.
    
draft-boucadair-pcp-yang-03.txt
 YANG Data Models for the Port Control Protocol (PCP)
 
 draft-boucadair-pcp-yang-03.txt
 Date: 22/11/2016
 Authors: Mohamed Boucadair, Christian Jacquenet, Senthil Sivakumar, Suresh Vinapamula
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines YANG data models for the Port Control Protocol (PCP), including PCP client, PCP server, PCP proxy, and Universal Plug and Play (UPnP) Internet Gateway Device - Port Control Protocol Interworking Function.
    
draft-boucadair-tcpm-capability-option-01.txt
 TCP Capability Option
 
 draft-boucadair-tcpm-capability-option-01.txt
 Date: 08/12/2016
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an experimental TCP option that can be used to negotiate a set of options that are supported by two TCP endpoints. The main motivation for designing this option is the optimization of the option space for SYN segments.
    
draft-boutros-bess-evpn-auto-provisoning-02.txt
 EVPN auto provisioning using a controller
 
 draft-boutros-bess-evpn-auto-provisoning-02.txt
 Date: 21/10/2016
 Authors: Sami Boutros, Rex Fernando, Ali Sajassi, Junying Pang, tsingh@juniper.net
 Working Group: Individual Submissions (none)
 Formats: txt
In some datacenter use cases, priori knowledge of what PE/NVE to be configured for a given L2 or L3 service may not be available. This document describes how EVPN can be extended to discover what L2 or L3 services to be enabled on a given PE/NVE, based on first sign of life FSOL packets received on the PE/NVE ports. An EVPN route based on the FSOL packets will be sent to a controller to trigger a push of the related L2/L3 or subscriber service configuration to be provisioned on the PE/NVE and on the switch ports.
    
draft-boutros-bess-evpn-vpws-service-edge-gateway-03.txt
 EVPN-VPWS Service Edge Gateway
 
 draft-boutros-bess-evpn-vpws-service-edge-gateway-03.txt
 Date: 21/10/2016
 Authors: Sami Boutros, Patrice Brissette, Ali Sajassi, daniel.voyer@bell.ca, John Drake
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how a service node can dynamically terminate EVPN virtual private wire transport service (VPWS) from access nodes and offer Layer 2, Layer 3 and Ethernet VPN overlay services to Customer edge devices connected to the access nodes. Service nodes using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN overlay services it can offer for the terminated EVPN VPWS transport service. On an access node an operator can specify the L2 or L3 or Ethernet VPN overlay service needed by the customer edge device connected to the access node that will be transported over the EVPN- VPWS service between access node and service node.
    
draft-boutros-bess-vxlan-evpn-02.txt
 VXLAN DCI Using EVPN
 
 draft-boutros-bess-vxlan-evpn-02.txt
 Date: 21/10/2016
 Authors: Sami Boutros, Ali Sajassi, Samer Salam, Dennis Cai, Samir Thoria, tsingh@juniper.net, John Drake, Jeff Tantsura
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes how Ethernet VPN (E-VPN) technology can be used to interconnect VXLAN or NVGRE networks over an MPLS/IP network. This is to provide intra-subnet connectivity at Layer 2 and control- plane separation among the interconnected VXLAN or NVGRE networks. The scope of the learning of host MAC addresses in VXLAN or NVGRE network is limited to data plane learning in this document.
    
draft-bradley-oauth-jwt-encoded-state-07.txt
 Encoding claims in the OAuth 2 state parameter using a JWT
 
 draft-bradley-oauth-jwt-encoded-state-07.txt
 Date: 13/03/2017
 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-04.txt
 Stateless Client Identifier for OAuth 2
 
 draft-bradley-oauth-stateless-client-id-04.txt
 Date: 11/01/2017
 Authors: John Bradley, Justin <>
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation.
    
draft-bradner-rfc3979bis-13.txt
 Intellectual Property Rights in IETF Technology
 
 draft-bradner-rfc3979bis-13.txt
 Date: 08/03/2017
 Authors: Scott Bradner, Jorge Contreras
 Working Group: General Area (gen)
 Formats: txt
The IETF policies about Intellectual Property Rights (IPR), such as patent rights, relative to technologies developed in the IETF are designed to ensure that IETF working groups and participants have as much information as possible about any IPR constraints on a technical proposal as early as possible in the development process. The policies are intended to benefit the Internet community and the public at large, while respecting the legitimate rights of IPR holders. This document sets out the IETF policies concerning IPR related to technology worked on within the IETF. It also describes the objectives that the policies are designed to meet. This document updates RFC 2026 and, with RFC 5378, replaces Section 10 of RFC 2026. This document also obsoletes RFC 3979 and RFC 4879.
    
draft-briscoe-tsvwg-aqm-dualq-coupled-00.txt
 DualQ Coupled AQM for Low Latency,Low Loss and Scalable Throughput
 
 draft-briscoe-tsvwg-aqm-dualq-coupled-00.txt
 Date: 31/10/2016
 Authors: Koen De Schepper, Bob Briscoe, Olga Bondarenko, Ing Tsang
 Working Group: Individual Submissions (none)
 Formats: xml txt
Data Centre TCP (DCTCP) was designed to provide predictably low queuing latency, near-zero loss, and throughput scalability using explicit congestion notification (ECN) and an extremely simple marking behaviour on switches. However, DCTCP does not co-exist with existing TCP traffic---throughput starves. So, until now, DCTCP could only be deployed where a clean-slate environment could be arranged, such as in private data centres. This specification defines `DualQ Coupled Active Queue Management (AQM)' to allow scalable congestion controls like DCTCP to safely co-exist with classic Internet traffic. The Coupled AQM ensures that a flow runs at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but without inspecting transport layer flow identifiers. When tested in a residential broadband setting, DCTCP achieved sub-millisecond average queuing delay and zero congestion loss under a wide range of mixes of DCTCP and `Classic' broadband Internet traffic, without compromising the performance of the Classic traffic. The solution also reduces network complexity and eliminates network configuration.
    
draft-briscoe-tsvwg-ecn-l4s-id-02.txt
 Identifying Modified Explicit Congestion Notification (ECN) Semantics for Ultra-Low Queuing Delay
 
 draft-briscoe-tsvwg-ecn-l4s-id-02.txt
 Date: 31/10/2016
 Authors: Koen De Schepper, Bob Briscoe, Ing Tsang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines the identifier to be used on IP packets for a new network service called low latency, low loss and scalable throughput (L4S). It is similar to the original (or 'Classic') Explicit Congestion Notification (ECN). 'Classic' ECN marking was required to be equivalent to a drop, both when applied in the network and when responded to by a transport. Unlike 'Classic' ECN marking, for packets carrying the L4S identifier, the network applies marking more immediately and more aggressively than drop, and the transport response to each mark is reduced and smoothed relative to that for drop. The two changes counterbalance each other so that the throughput of an L4S flow will be roughly the same as a 'Classic' flow under the same conditions. However, the much more frequent control signals and the finer responses to them result in ultra-low queuing delay without compromising link utilization, even during high load. Examples of new active queue management (AQM) marking algorithms and examples of new transports (whether TCP-like or real- time) are specified separately. The new L4S identifier is the key piece that enables them to interwork and distinguishes them from 'Classic' traffic. It gives an incremental migration path so that existing 'Classic' TCP traffic will be no worse off, but it can be prevented from degrading the ultra-low delay and loss of the new scalable transports.
    
draft-briscoe-tsvwg-l4s-arch-01.txt
 Low Latency,Low Loss,Scalable Throughput (L4S) Internet Service: Architecture
 
 draft-briscoe-tsvwg-l4s-arch-01.txt
 Date: 13/03/2017
 Authors: Bob Briscoe, Koen De Schepper, Marcelo Bagnulo
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the L4S architecture for the provision of a new service that the Internet could provide to eventually replace best efforts for all traffic: Low Latency, Low Loss, Scalable throughput (L4S). It is becoming common for _all_ (or most) applications being run by a user at any one time to require low latency. However, the only solution the IETF can offer for ultra-low queuing delay is Diffserv, which only favours a minority of packets at the expense of others. In extensive testing the new L4S service keeps average queuing delay under a millisecond for _all_ applications even under very heavy load, without sacrificing utilization; and it keeps congestion loss to zero. It is becoming widely recognized that adding more access capacity gives diminishing returns, because latency is becoming the critical problem. Even with a high capacity broadband access, the reduced latency of L4S remarkably and consistently improves performance under load for applications such as interactive video, conversational video, voice, Web, gaming, instant messaging, remote desktop and cloud-based apps (even when all being used at once over the same access link). The insight is that the root cause of queuing delay is in TCP, not in the queue. By fixing the sending TCP (and other transports) queuing latency becomes so much better than today that operators will want to deploy the network part of L4S to enable new products and services. Further, the network part is simple to deploy - incrementally with zero-config. Both parts, sender and network, ensure coexistence with other legacy traffic. At the same time L4S solves the long- recognized problem with the future scalability of TCP throughput. This document describes the L4S architecture, briefly describing the different components and how the work together to provide the aforementioned enhanced Internet service.
    
draft-brockners-inband-oam-data-03.txt
 Data Fields for In-situ OAM
 
 draft-brockners-inband-oam-data-03.txt
 Date: 13/03/2017
 Authors: Frank Brockners, Shwetha Bhandari, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, David Mozes, Petr Lapukhov, Remy <>
 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 discusses the data fields and associated data types for in-situ OAM. In-situ OAM data fields can be embedded into a variety of transports such as NSH, Segment Routing, VXLAN-GPE, Geneve, native IPv6 (via extension header), or IPv4. In-situ OAM can be used to complement current out-of-band OAM mechanisms based on ICMP or other types of probe packets.
    
draft-brockners-inband-oam-requirements-03.txt
 Requirements for In-situ OAM
 
 draft-brockners-inband-oam-requirements-03.txt
 Date: 13/03/2017
 Authors: Frank Brockners, Shwetha Bhandari, Sashank Dara, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, David Mozes, Tal Mizrahi, Petr <>, remy@barefootnetworks.com
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses the motivation and requirements for including specific operational and telemetry information into data packets while the data packet traverses a path between two points in the network. This method is referred to as "in-situ" Operations, Administration, and Maintenance (OAM), given that the OAM information is carried with the data packets as opposed to in "out-of-band" packets dedicated to OAM. In situ OAM complements other OAM mechanisms which use dedicated probe packets to convey OAM information.
    
draft-brockners-inband-oam-transport-03.txt
 Encapsulations for In-situ OAM Data
 
 draft-brockners-inband-oam-transport-03.txt
 Date: 13/03/2017
 Authors: Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, David Mozes, Petr Lapukhov, Remy <>
 Working Group: Individual Submissions (none)
 Formats: xml txt
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. In-situ OAM is to complement current out-of-band OAM mechanisms based on ICMP or other types of probe packets. This document outlines how in-situ OAM data fields can be transported in protocols such as NSH, Segment Routing, VXLAN-GPE, native IPv6 (via extension headers), and IPv4. Transport options are currently investigated as part of an implementation study. This document is intended to only serve informational purposes.
    
draft-brockners-proof-of-transit-03.txt
 Proof of Transit
 
 draft-brockners-proof-of-transit-03.txt
 Date: 13/03/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-browne-sfc-nsh-kpi-stamp-00.txt
 Network Service Header KPI Stamping
 
 draft-browne-sfc-nsh-kpi-stamp-00.txt
 Date: 26/10/2016
 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-bruneau-intarea-provisioning-domains-00.txt
 Proposals to discover Provisioning Domains
 
 draft-bruneau-intarea-provisioning-domains-00.txt
 Date: 13/03/2017
 Authors: Basile Bruneau, Pierre Pfister, dschinazi@apple.com, Tommy Pauly, Eric Vyncke
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes one possible way for hosts to retrieve additional information about their Internet access configuration. The set of configuration items required to access the Internet is called a Provisioning Domain (PvD) and is identified by a Fully Qualified Domain Name. This document separates the way of getting the Provisioning Domain identifier, the way of getting the Provisioning Domain information and the potential information contained in the Provisioning Domain.
    
draft-bryant-mpls-rfc6374-sfl-03.txt
 RFC6374 Synonymous Flow Labels
 
 draft-bryant-mpls-rfc6374-sfl-03.txt
 Date: 28/10/2016
 Authors: Stewart Bryant, Mach Chen, Zhenbin Li, George Swallow, Siva Sivabalan, Gregory Mirsky, Giuseppe Fioccola
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a method of making RFC6374 performance measurements on flows carried over an MPLS Label Switched path. This allows loss and delay measurements to be made on multi-point to point LSPs and allows the measurement of flows within an MPLS construct using RFC6374.
    
draft-bryant-mpls-sfl-control-01.txt
 MPLS Flow Identification Considerations
 
 draft-bryant-mpls-sfl-control-01.txt
 Date: 10/03/2017
 Authors: Stewart Bryant, George Swallow, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: txt
In draft-bryant-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-mpls-sfl-framework-03.txt
 Synonymous Flow Label Framework
 
 draft-bryant-mpls-sfl-framework-03.txt
 Date: 09/03/2017
 Authors: Stewart Bryant, Mach Chen, Zhenbin Li, George Swallow, Siva Sivabalan, Gregory Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt
draft-ietf-mpls-flow-ident describes the requirement for introducing flow identities within the MPLS architecture. This document describes a method of accomplishing this by using a technique called Synonymous Flow Labels in which labels which mimic the behaviour of other labels provide the identification service. These identifiers can be used to trigger per-flow operations on the on the packet at the receiving label switching router.
    
draft-bryant-rtgwg-param-sync-01.txt
 Synchronisation of Routing Parameters
 
 draft-bryant-rtgwg-param-sync-01.txt
 Date: 27/02/2017
 Authors: Stewart Bryant, Alia Atlas, Chris Bowers
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a mechanism for a link state routing protocol to coordinate the value of a network-wide routing parameter amongst routers in the flooding domain. The document also defines the solution to one specific case: the agreement of a common convergence timer value for use in network convergence.
    
draft-bryskin-teas-yang-ietf-vs-onf-00.txt
 ONF/T-API Services vs. IETF/YANG Models and Interfaces
 
 draft-bryskin-teas-yang-ietf-vs-onf-00.txt
 Date: 13/03/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-busibel-teas-yang-path-computation-02.txt
 Yang model for requesting Path Computation
 
 draft-busibel-teas-yang-path-computation-02.txt
 Date: 03/03/2017
 Authors: Italo Busi, Sergio Belotti, Victor Lopezalvarez, Oscar de Dios, ansharma@infinera.com, Yan Shi, Ricard Vilata, Karthik Sethuraman, Michael Scharf, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: txt pdf
There are scenarios, typically in a hierarchical SDN context, in which an orchestrator may not have detailed information to be able to perform an end-to-end path computation and would need to request lower layer/domain controllers to calculate some (partial) feasible paths. Multiple protocol solutions can be used for communication between different controller hierarchical levels. This document assumes that the controllers are communicating using YANG-based protocols (e.g., NETCONF or RESTCONF). This document describes some use cases where a path computation request, via YANG-based protocols (e.g., NETCONF or RESTCONF), can be needed. This document also proposes a yang model for a stateless RPC which complements the stateful solution defined in [TE-TUNNEL].
    
draft-cai-nfvrg-recursive-monitor-03.txt
 Recursive Monitoring Language in Network Function Virtualization (NFV) Infrastructures
 
 draft-cai-nfvrg-recursive-monitor-03.txt
 Date: 15/11/2016
 Authors: Xuejun Cai, Catalin Meirosu, Greg >
 Working Group: Individual Submissions (none)
 Formats: xml txt
Network Function Virtualization (NFV) poses a number of monitoring challenges; one potential solution to these challenges is a recursive monitoring language. This document presents a set of requirements for such a recursive monitoring language.
    
draft-campbell-oauth-resource-indicators-02.txt
 Resource Indicators for OAuth 2.0
 
 draft-campbell-oauth-resource-indicators-02.txt
 Date: 14/11/2016
 Authors: Brian Campbell, John Bradley, Hannes Tschofenig
 Working Group: Individual Submissions (none)
 Formats: txt xml
This straw-man specification defines an extension to The OAuth 2.0 Authorization Framework that enables the client and authorization server to more explicitly to communicate about the protected resource(s) to be accessed.
    
draft-campbell-oauth-tls-client-auth-00.txt
 Mutual X.509 Transport Layer Security (TLS) Authentication for OAuth Clients
 
 draft-campbell-oauth-tls-client-auth-00.txt
 Date: 10/10/2016
 Authors: Brian Campbell, John Bradley
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes X.509 certificates as OAuth client credentials using Transport Layer Security (TLS) mutual authentication as a mechanism for client authentication to the authorization server's token endpoint.
    
draft-campbell-tokbind-tls-term-00.txt
 HTTPS Token Binding and TLS Terminating Reverse Proxies
 
 draft-campbell-tokbind-tls-term-00.txt
 Date: 11/01/2017
 Authors: Brian Campbell
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document defines an HTTP header field that enables a TLS terminating reverse proxy to convey the information a backend server needs in order for it to process and validate a Token Binding Message sent by the client.
    
draft-cao-core-delegated-observe-00.txt
 CoAP Delegated Observe
 
 draft-cao-core-delegated-observe-00.txt
 Date: 27/10/2016
 Authors: Zhen Cao, Rahul Jadhav
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the scenarios for "delegated observe", in which a subscriber needs to register some resources on behalf of some other entities. This document also presents a CoAP protocol extension for the delegated observe operation.
    
draft-carney-regext-domainconnect-02.txt
 Domain Connect API - Communications between DNS Provider and Services
 
 draft-carney-regext-domainconnect-02.txt
 Date: 01/02/2017
 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-ani-objectives-01.txt
 Technical Objective Formats for the Autonomic Network Infrastructure
 
 draft-carpenter-anima-ani-objectives-01.txt
 Date: 12/02/2017
 Authors: Brian Carpenter, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines the formats of several technical objectives for the Generic Autonomic Signaling Protocol (GRASP) used by components of the Autonomic Networking Infrastructure outlined in the ANIMA reference model. It also covers other initial use cases for Autonomic Networking.
    
draft-carpenter-anima-asa-guidelines-01.txt
 Guidelines for Autonomic Service Agents
 
 draft-carpenter-anima-asa-guidelines-01.txt
 Date: 06/01/2017
 Authors: Brian Carpenter, Sheng Jiang
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-cavage-http-signatures-06.txt
 Signing HTTP Messages
 
 draft-cavage-http-signatures-06.txt
 Date: 10/01/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-cel-nfsv4-federated-fs-nce-06.txt
 A Simpler Mechanism For Organizing FedFS NSDBs
 
 draft-cel-nfsv4-federated-fs-nce-06.txt
 Date: 25/10/2016
 Authors: Chuck Lever, Simo Sorce
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a new, simpler mechanism for searching FedFS NSDBs (Name Space Data Bases) for FedFS records. This mechanism replaces the mechanism described in existing FedFS Proposed Standards.
    
draft-cel-nfsv4-federated-fs-security-addendum-06.txt
 Federated Filesystem Security Addendum
 
 draft-cel-nfsv4-federated-fs-security-addendum-06.txt
 Date: 25/10/2016
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document addresses critical security-related items that are missing from existing FedFS Proposed Standards.
    
draft-cel-nfsv4-reminv-design-05.txt
 Using Remote Invalidation With RPC-Over-RDMA Transports
 
 draft-cel-nfsv4-reminv-design-05.txt
 Date: 13/03/2017
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-01.txt
 RDMA Connection Manager Private Messages For RPC-Over-RDMA Version One
 
 draft-cel-nfsv4-rpcrdma-cm-pvt-msg-01.txt
 Date: 28/03/2017
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the format of RDMA-CM Private Data exchanged between RPC-over-RDMA Version One 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-version-two-03.txt
 RPC-over-RDMA Version Two Protocol
 
 draft-cel-nfsv4-rpcrdma-version-two-03.txt
 Date: 01/12/2016
 Authors: Chuck Lever, David Noveck
 Working Group: Individual Submissions (none)
 Formats: xml txt
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 One.
    
draft-cfrg-re-keying-00.txt
 Re-keying Mechanisms for Symmetric Keys
 
 draft-cfrg-re-keying-00.txt
 Date: 20/02/2017
 Authors: Stanislav Smyshlyaev, Russ Housley, Mihir Bellare, Evgeny Alekseev, Smyshliaeva Ekaterina, Daniel Franke, Lilia Ahmetzyanova, Ruth Ng
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This specification contains a description of a variety of methods to increase the lifetime of symmetric keys. It provides external and internal re-keying mechanisms that can be used with such modes of operations as CTR, GCM, CBC, CFB, OFB and OMAC.
    
draft-chan-quic-owl-01.txt
 One Way Latency Considerations for Multipath in QUIC
 
 draft-chan-quic-owl-01.txt
 Date: 13/03/2017
 Authors: Anthony Chan, Anni Wei, Fei Song, Hong-Ke Zhang
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document discusses the use of One Way Latency (OWL) for enhancing multipath transmission in QUIC. Several representative usages of OWL, such as congestion control mechanism, retransmission policy, crucial data scheduling are analyzed. Two kinds of OWL measurement approaches are also provided and compared. More explorations related with OWL will be researched to improve the performance of QUIC.
    
draft-chen-ati-adaptive-ipv4-address-space-00.txt
 Adaptive IPv4 Address Space
 
 draft-chen-ati-adaptive-ipv4-address-space-00.txt
 Date: 14/12/2016
 Authors: Abraham Chen, Ramamurthy Ati
 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), discusses the IPv4 public address pool expansion and the Internet system architecture enhancement aspects. It was originated by a study called ExIP (Extended IPv4) analyzing the use of the first available octet (eight bits) in the reserved private network pools (10/8, 172.16/12 and 192.168/16) to achieve a moderate address space expansion factor of 256 by each, while maintaining their familiar operation characteristics. Along the way, a parallel yet similar effort, called EnIP (Enhanced IPv4), was discovered. EnIP fully utilizes the same private network pools to increase the address space by a factor of 17.1M with end-to-end connectivity. EzIP is a superset that proposes one unified format for not only encompassing the considerations of both, but also identifying additional capabilities and flexibilities. For example, EzIP may expand an IPv4 address at least by a factor of 256 to as high as 256M without affecting the existing IPv4 public address assignments, while still keeping intact the current private networks for the 256M case if desired. The EzIP is in full conformance with the IPv4 protocol, and supports not only both categories of connectivity, but also their interoperability. The traditional Internet traffic and the IoT operations may coexist simultaneously without perturbing their existing setups, while offering end-users the freedom to choose one or the other. If the IPv4 public pool were reorganized, the assignable pool could be multiplied by 512M or even up to 2B times with end-to-end connectivity. EzIP may be deployed as a firmware enhancement to the Internet edge routers or private network gateways wherever needed, or simply installed as an inline adjunct module between the two, enabling a seamless introduction. The 256M case establishes a spherical layer of routers providing a complete interconnection between the Internet and end-users. This configuration enables the entire current Internet and private networks characteristics to remain intact. These proposed interim facilities would afford IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.
    
draft-chen-ati-ezipb-00.txt
 IPv4 with Adaptive Address Space
 
 draft-chen-ati-ezipb-00.txt
 Date: 26/11/2016
 Authors: Abraham Chen, Ramamurthy Ati
 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), discusses the IPv4 public address pool expansion and the Internet system architecture enhancement aspects. It was originated by a study called ExIP (Extended IPv4) analyzing the use of the first available octet (eight bits) in the reserved private network pools (10/8, 172.16/12 and 192.168/16) to achieve a moderate address space expansion factor of 256 by each, while maintaining their familiar operation characteristics. Along the way, a parallel yet similar effort, called EnIP (Enhanced IPv4), was discovered. EnIP fully utilizes the same private network pools to increase the address space by a factor of 17.1M with end-to-end connectivity. EzIP is a superset that proposes one unified format for not only encompassing the considerations of both, but also identifying additional capabilities and flexibilities. For example, EzIP may expand an IPv4 address at least by a factor of 256 to as high as 256M without affecting the existing IPv4 public address assignments, while still keeping intact the current private networks for the 256M case if desired. The EzIP is in full conformance with the IPv4 protocol, and supports not only both categories of connectivity, but also their interoperability. The traditional Internet traffic and the IoT operations may coexist simultaneously without perturbing their existing setups, while offering end-users the freedom to choose one or the other. If the IPv4 public pool were reorganized, the assignable pool could be multiplied by 512M or even up to 2B times with end-to-end connectivity. EzIP may be deployed as a firmware enhancement to the Internet edge routers or private network gateways wherever needed, or simply installed as an inline adjunct module between the two, enabling a seamless introduction. The 256M case establishes a spherical layer of routers providing a complete interconnection between the Internet and end-users. This configuration enables the entire current Internet and private networks characteristics to remain intact. These proposed interim facilities would afford IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.
    
draft-chen-ati-ezipc-00.txt
 IPv4 with Adaptive Address Space
 
 draft-chen-ati-ezipc-00.txt
 Date: 26/11/2016
 Authors: Abraham Chen, Ramamurthy Ati
 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), discusses the IPv4 public address pool expansion and the Internet system architecture enhancement aspects. It was originated by a study called ExIP (Extended IPv4) analyzing the use of the first available octet (eight bits) in the reserved private network pools (10/8, 172.16/12 and 192.168/16) to achieve a moderate address space expansion factor of 256 by each, while maintaining their familiar operation characteristics. Along the way, a parallel yet similar effort, called EnIP (Enhanced IPv4), was discovered. EnIP fully utilizes the same private network pools to increase the address space by a factor of 17.1M with end-to-end connectivity. EzIP is a superset that proposes one unified format for not only encompassing the considerations of both, but also identifying additional capabilities and flexibilities. For example, EzIP may expand an IPv4 address at least by a factor of 256 to as high as 256M without affecting the existing IPv4 public address assignments, while still keeping intact the current private networks for the 256M case if desired. The EzIP is in full conformance with the IPv4 protocol, and supports not only both categories of connectivity, but also their interoperability. The traditional Internet traffic and the IoT operations may coexist simultaneously without perturbing their existing setups, while offering end-users the freedom to choose one or the other. If the IPv4 public pool were reorganized, the assignable pool could be multiplied by 512M or even up to 2B times with end-to-end connectivity. EzIP may be deployed as a firmware enhancement to the Internet edge routers or private network gateways wherever needed, or simply installed as an inline adjunct module between the two, enabling a seamless introduction. The 256M case establishes a spherical layer of routers providing a complete interconnection between the Internet and end-users. This configuration enables the entire current Internet and private networks characteristics to remain intact. These proposed interim facilities would afford IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.
    
draft-chen-ati-ezipd-00.txt
 IPv4 with Adaptive Address Space
 
 draft-chen-ati-ezipd-00.txt
 Date: 13/12/2016
 Authors: Abraham Chen, Ramamurthy Ati
 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), discusses the IPv4 public address pool expansion and the Internet system architecture enhancement aspects. It was originated by a study called ExIP (Extended IPv4) analyzing the use of the first available octet (eight bits) in the reserved private network pools (10/8, 172.16/12 and 192.168/16) to achieve a moderate address space expansion factor of 256 by each, while maintaining their familiar operation characteristics. Along the way, a parallel yet similar effort, called EnIP (Enhanced IPv4), was discovered. EnIP fully utilizes the same private network pools to increase the address space by a factor of 17.1M with end-to-end connectivity. EzIP is a superset that proposes one unified format for not only encompassing the considerations of both, but also identifying additional capabilities and flexibilities. For example, EzIP may expand an IPv4 address at least by a factor of 256 to as high as 256M without affecting the existing IPv4 public address assignments, while still keeping intact the current private networks for the 256M case if desired. The EzIP is in full conformance with the IPv4 protocol, and supports not only both categories of connectivity, but also their interoperability. The traditional Internet traffic and the IoT operations may coexist simultaneously without perturbing their existing setups, while offering end-users the freedom to choose one or the other. If the IPv4 public pool were reorganized, the assignable pool could be multiplied by 512M or even up to 2B times with end-to-end connectivity. EzIP may be deployed as a firmware enhancement to the Internet edge routers or private network gateways wherever needed, or simply installed as an inline adjunct module between the two, enabling a seamless introduction. The 256M case establishes a spherical layer of routers providing a complete interconnection between the Internet and end-users. This configuration enables the entire current Internet and private networks characteristics to remain intact. These proposed interim facilities would afford IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.
    
draft-chen-ati-with-adaptive-address-space-00.txt
 IPv4 with Adaptive Address Space
 
 draft-chen-ati-with-adaptive-address-space-00.txt
 Date: 13/12/2016
 Authors: Abraham Chen, Ramamurthy Ati
 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), discusses the IPv4 public address pool expansion and the Internet system architecture enhancement aspects. It was originated by a study called ExIP (Extended IPv4) analyzing the use of the first available octet (eight bits) in the reserved private network pools (10/8, 172.16/12 and 192.168/16) to achieve a moderate address space expansion factor of 256 by each, while maintaining their familiar operation characteristics. Along the way, a parallel yet similar effort, called EnIP (Enhanced IPv4), was discovered. EnIP fully utilizes the same private network pools to increase the address space by a factor of 17.1M with end-to-end connectivity. EzIP is a superset that proposes one unified format for not only encompassing the considerations of both, but also identifying additional capabilities and flexibilities. For example, EzIP may expand an IPv4 address at least by a factor of 256 to as high as 256M without affecting the existing IPv4 public address assignments, while still keeping intact the current private networks for the 256M case if desired. The EzIP is in full conformance with the IPv4 protocol, and supports not only both categories of connectivity, but also their interoperability. The traditional Internet traffic and the IoT operations may coexist simultaneously without perturbing their existing setups, while offering end-users the freedom to choose one or the other. If the IPv4 public pool were reorganized, the assignable pool could be multiplied by 512M or even up to 2B times with end-to-end connectivity. EzIP may be deployed as a firmware enhancement to the Internet edge routers or private network gateways wherever needed, or simply installed as an inline adjunct module between the two, enabling a seamless introduction. The 256M case establishes a spherical layer of routers providing a complete interconnection between the Internet and end-users. This configuration enables the entire current Internet and private networks characteristics to remain intact. These proposed interim facilities would afford IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.
    
draft-chen-bier-pce-bier-02.txt
 PCEP Extensions for BIER
 
 draft-chen-bier-pce-bier-02.txt
 Date: 03/01/2017
 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-te-ping-01.txt
 BIER-TE Ping and Trace
 
 draft-chen-bier-te-ping-01.txt
 Date: 08/10/2016
 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-id-locator-split-5g-solution-00.txt
 ID Locator Split Based Solution for 5G Network
 
 draft-chen-id-locator-split-5g-solution-00.txt
 Date: 31/10/2016
 Authors: Cheng Chen, Xinpeng Wei
 Working Group: Individual Submissions (none)
 Formats: txt
In this memo, a generic network scheme based on ID / Locator separation architecture is proposed to satisfy the emerging new requirements of future networks.
    
draft-chen-idr-com-cntlrs-01.txt
 BGP for Communications among Controllers
 
 draft-chen-idr-com-cntlrs-01.txt
 Date: 05/01/2017
 Authors: Huaimo Chen, Susan Hares, Yi Yang, Yanhe Fan, Mehmet Toy, Zhenqiang Li, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes extensions to the BGP routing protocol for supporting communications among SDN controllers in a centralized control system, which comprises multiple SDN controllers controlling a network with a number of domains.
    
draft-chen-idr-geo-coordinates-02.txt
 Carrying Geo Coordinates in BGP
 
 draft-chen-idr-geo-coordinates-02.txt
 Date: 31/10/2016
 Authors: Enke Chen, Naiming Shen, Robert Raszuk
 Working Group: Individual Submissions (none)
 Formats: txt
In this document we specify a new BGP capability - the Geo Coordinate Capability, and a new BGP attribute - the Geo Coordinate Attribute, for carrying the Geo Coordinate information in BGP.
    
draft-chen-isis-black-hole-avoid-00.txt
 Avoiding Traffic Black-Holes for Route Aggregation in IS-IS
 
 draft-chen-isis-black-hole-avoid-00.txt
 Date: 13/03/2017
 Authors: Zhe Chen, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 extends IS-IS to solve this problem.
    
draft-chen-isis-ias-lk-00.txt
 ISIS Extensions for Broadcast Inter-AS TE Link
 
 draft-chen-isis-ias-lk-00.txt
 Date: 13/03/2017
 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-rfc5316bis-02.txt
 ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering
 
 draft-chen-isis-rfc5316bis-02.txt
 Date: 04/01/2017
 Authors: Mach Chen, Les Ginsberg, Stefano Previdi, Xiaodong Duan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes extensions to the ISIS (ISIS) protocol to support Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems (ASes). It defines ISIS-TE extensions for the flooding of TE information about inter-AS links, which can be used to perform inter- AS TE path computation. No support for flooding information from within one AS to another AS is proposed or defined in this document. This document obsoletes [RFC5316]
    
draft-chen-isis-sl-overheads-reduction-00.txt
 Overheads Reduction for IS-IS Enabled Spine-Leaf Networks
 
 draft-chen-isis-sl-overheads-reduction-00.txt
 Date: 06/01/2017
 Authors: Zhe Chen, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt
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 assigning different area identifiers (AIDs) to the Leaf nodes. The solution requires that an IS-IS router SHOULD check a Level-1 LSP's AIDs before it advertises the LSP to its neighbor.
    
draft-chen-netmod-enterprise-yang-namespace-03.txt
 Grammar for Enterprise YANG Module Namespace
 
 draft-chen-netmod-enterprise-yang-namespace-03.txt
 Date: 13/10/2016
 Authors: I. Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the grammar to create enterprise YANG module namespaces that are globally unique, as required by the YANG modeling language.
    
draft-chen-nvo3-vxlan-yang-04.txt
 YANG Data Model for VxLAN Protocol
 
 draft-chen-nvo3-vxlan-yang-04.txt
 Date: 26/12/2016
 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-opsawg-composite-vpn-dm-00.txt
 YANG Data Model for Composite VPN Service Delivery
 
 draft-chen-opsawg-composite-vpn-dm-00.txt
 Date: 27/10/2016
 Authors: Rui Chen, Liya Zhang, DENG Hui, 4c 67, Chongfeng Xie
 Working Group: Individual Submissions (none)
 Formats: txt
The operator facing data model is valuable to reduce the operations and management. This document describes the YANG data model of the composite VPN for operators to provision, optimize, monitor and diagnose the end to end PE-based VPN services across multiple autonomous systems (ASes). The model from this document are limited to multiple ASes within one service provider.
    
draft-chen-ospf-ias-lk-00.txt
 OSPF Extensions for Broadcast Inter-AS TE Link
 
 draft-chen-ospf-ias-lk-00.txt
 Date: 13/03/2017
 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-ospf-tts-01.txt
 Extensions to OSPF for Temporal LSP
 
 draft-chen-ospf-tts-01.txt
 Date: 29/12/2016
 Authors: Huaimo Chen, Mehmet Toy, Vic liu, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies extensions to OSPF for distributing Traffic Engineering (TE) information on a link in a sequence of time intervals.
    
draft-chen-pals-pw-yang-01.txt
 YANG Data Model for PW Protocol
 
 draft-chen-pals-pw-yang-01.txt
 Date: 07/10/2016
 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-association-ecmp-00.txt
 Path Computation Element communication Protocol extension for Associated ECMP
 
 draft-chen-pce-association-ecmp-00.txt
 Date: 09/03/2017
 Authors: Ran Chen, fangwei hu
 Working Group: Individual Submissions (none)
 Formats: txt
[I-D.ietf-pce-association-group]introduces and explains a generic mechanism to create a grouping of LSPs. The grouping can then be used to define associations between a set of LSPs and/or a set of attributes (such as configuration parameters or behaviours) and is equally applicable to the active and passive modes of a stateful PCE [I-D.ietf-pce-stateful-pce] as well as a stateless PCE [RFC5440]. This document specifies a PCEP extension to bind one or more LSPs into an ECMP Associated Group.
    
draft-chen-pce-compute-backup-egress-10.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-10.txt
 Date: 31/10/2016
 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-10.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-10.txt
 Date: 31/10/2016
 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-11.txt
 A Forward-Search P2MP TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2mp-path-11.txt
 Date: 31/10/2016
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt
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-12.txt
 A Forward-Search P2P TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2p-path-computation-12.txt
 Date: 31/10/2016
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt
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-02.txt
 PCEP Link State Abstraction
 
 draft-chen-pce-h-connect-access-02.txt
 Date: 13/03/2017
 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-02.txt
 Hierarchical PCE Determination
 
 draft-chen-pce-h-discovery-02.txt
 Date: 13/03/2017
 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-01.txt
 PCE Hierarchical SDNs
 
 draft-chen-pce-h-sdns-01.txt
 Date: 31/10/2016
 Authors: Huaimo Chen, Mehmet Toy, Lei Liu, vic
 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-05.txt
 Extensions to PCEP for Distributing Label Cross Domains
 
 draft-chen-pce-label-x-domains-05.txt
 Date: 31/10/2016
 Authors: Huaimo Chen, Autumn Liu, Fengman Xu, Mehmet Toy, vic
 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-02.txt
 Static PCEP Link State
 
 draft-chen-pce-pcc-ted-02.txt
 Date: 13/03/2017
 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-09.txt
 The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks.
 
 draft-chen-pce-protection-applicability-09.txt
 Date: 31/10/2016
 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-pce-tts-05.txt
 Extensions to PCEP for Temporal LSP
 
 draft-chen-pce-tts-05.txt
 Date: 29/12/2016
 Authors: Huaimo Chen, Xufeng Liu, Mehmet Toy, Vic liu, Lei Liu, Khuzema Pithewan
 Working Group: Individual Submissions (none)
 Formats: txt
For existing MPLS LSP tunnel services, it is hard for LSP tunnels to be booked in advance. In addition, once an LSP tunnel is set up, it is assumed to consume a certain amount of resources such as link bandwidth forever. Temporal LSP tunnel services (TTS) provides an easy way for us to book temporal LSP tunnels in advance. More importantly, a temporal LSP is an LSP with one or more time intervals and it is assumed to consume the resources and carry traffic only in these time intervals. This document specifies extensions to PCEP for computing a path for a temporal LSP, initiating and maintaining a temporal LSP with a sequence of time intervals, during each of which the LSP carries traffic.
    
draft-chen-radext-extended-header-02.txt
 RADIUS Identifier Attribute
 
 draft-chen-radext-extended-header-02.txt
 Date: 26/03/2017
 Authors: Enke Chen, Naiming Shen
 Working Group: Individual Submissions (none)
 Formats: txt
The limitation with the one-octet "Identifier" field in the RADIUS packet is well known. In this document we propose extensions to the RADIUS protocol to address this fundamental limitation, and thus allowing for more efficient and more scalable implementations.
    
draft-chen-rtgwg-qos-yang-04.txt
 YANG Data Model for QoS
 
 draft-chen-rtgwg-qos-yang-04.txt
 Date: 20/10/2016
 Authors: I. Chen
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a YANG data model to describe quality-of- service (QoS) configurations.
    
draft-chen-teas-rsvp-tts-01.txt
 Extensions to MPLS for Temporal LSP
 
 draft-chen-teas-rsvp-tts-01.txt
 Date: 29/12/2016
 Authors: Huaimo Chen, Mehmet Toy, Vic liu, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies extensions to RSVP-TE for creating and maintaining a Traffic Engineering (TE) Label Switched Path (LSP) in a time interval or a sequence of time intervals.
    
draft-cheng-manet-dlep-da-credit-extension-00.txt
 DLEP DiffServ Aware Credit Windowing Extension
 
 draft-cheng-manet-dlep-da-credit-extension-00.txt
 Date: 27/10/2016
 Authors: Bow-Nan Cheng, David Wiggins, Lou Berger
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an extension to the DLEP protocol that enables a DiffServ aware credit-windowing scheme for destination-specific flow control.
    
draft-cheng-manet-dlep-latency-extension-00.txt
 DLEP Lantency Range Extension
 
 draft-cheng-manet-dlep-latency-extension-00.txt
 Date: 27/10/2016
 Authors: Bow-Nan Cheng, Lou Berger
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an extension to the DLEP protocol to provide the range of latency that may be experienced on a link.
    
draft-cheng-manet-dlep-multi-hop-extension-00.txt
 DLEP Multi-Hop Forwarding Extension
 
 draft-cheng-manet-dlep-multi-hop-extension-00.txt
 Date: 27/10/2016
 Authors: Bow-Nan Cheng, Lou Berger
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an extension to the DLEP protocol that enables a the reporting and control of Multi-Hop Forwarding by DLEP capable modems.
    
draft-cheng-manet-dlep-pause-extension-00.txt
 DLEP Control Plane Based Pause Extension
 
 draft-cheng-manet-dlep-pause-extension-00.txt
 Date: 27/10/2016
 Authors: Bow-Nan Cheng, David Wiggins, Lou Berger
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an extension to the DLEP protocol that enables a simple control plane based flow control mechanism.
    
draft-cheng-oftest-cont-rate-00.txt
 Flow Setup Rate Test for OpenFlow Controller
 
 draft-cheng-oftest-cont-rate-00.txt
 Date: 22/12/2016
 Authors: Mike Cheng, Yaming Bao
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes the test method and test process for controller about the flow setup rate.
    
draft-cheng-sdn-switchtest-00.txt
 SDN Switch Benchmark Test Cases Summary
 
 draft-cheng-sdn-switchtest-00.txt
 Date: 21/12/2016
 Authors: Mike Cheng, Yaming Bao
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document summarized the test cases for SDN switches, and introduced the test methodologies for each case of them.
    
draft-cheng-supa-applicability-01.txt
 Applicability of SUPA
 
 draft-cheng-supa-applicability-01.txt
 Date: 13/03/2017
 Authors: Ying Cheng, Dapeng Liu, Borui Fu, Dacheng Zhang, Narasimha Vadrevu
 Working Group: Individual Submissions (none)
 Formats: txt xml
SUPA will define a generic policy model, an imperative ECA (Event Condition Action) policy information model and a declarative (intent- based) policy information model which is the extension of the generic model, and a set of policy data models which will make use of the common concepts defined in the generic model. This memo will explore some typical use cases and demonstrate the applicability of SUPA policy models.
    
draft-chenpeng-mpls-ldp-ext-00.txt
 LDP Extensions for FEC elements sharing label
 
 draft-chenpeng-mpls-ldp-ext-00.txt
 Date: 28/10/2016
 Authors: Ran Chen, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
Label Distribution Protocol (LDP) is defined in [RFC5036] for distribution of labels inside one MPLS domain. It defined how to associate a Forwarding Equivalence Class (FEC) with each label it distributes. A FEC is a list of one or more FEC elements, but it does not describe operations how to achieve one or more FEC element share the same label. Currently Label resources are getting more and more nervous, and it is necessary to save the label resources. This document defines extensions to the LDP protocol to achieve one or more FEC element share the same label.
    
draft-cheshire-homenet-dot-home-04.txt
 Special Use Top Level Domain 'home'
 
 draft-cheshire-homenet-dot-home-04.txt
 Date: 13/03/2017
 Authors: Stuart Cheshire
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies usage of the top-level domain ".home", for names that are meaningful and resolvable within some scope smaller than the entire global Internet, but larger than the single link supported by Multicast DNS.
    
draft-cheshire-sudn-ipv4only-dot-arpa-06.txt
 Special Use Domain Name 'ipv4only.arpa'
 
 draft-cheshire-sudn-ipv4only-dot-arpa-06.txt
 Date: 14/11/2016
 Authors: Stuart Cheshire, dschinazi@apple.com
 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, as of November 2016 'ipv4only.arpa' still does not appear as one of the names with special properties that are recorded in the Special-Use Domain Names registry. This document formally declares the actual special properties of the name, and adds similar declarations for the corresponding reverse mapping names.
    
draft-cho-netvc-applypvq-03.txt
 Applying PVQ Outside Daala
 
 draft-cho-netvc-applypvq-03.txt
 Date: 13/11/2016
 Authors: Yushin Cho
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Perceptual Vector Quantization (PVQ) outside of the Daala video codec, where PVQ was originally developed. It discusses the issues arising while integrating PVQ into a traditional video codec, AV1.
    
draft-cho-pce-initiated-auto-path-00.txt
 PCEP Extensions for PCE-initiated Automatic Path Setup in a Stateful PCE Model
 
 draft-cho-pce-initiated-auto-path-00.txt
 Date: 31/10/2016
 Authors: Eunyoung Cho, Taehyun Kwon
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces an automatic setup and maintenance mechanism to compute, create, update and delete for a packet and/or optical layer path and pseudowire paths(PWs) via an extension to the Path Computation Element Communication Protocol(PCEP) and DB Synchronization procedures.
    
draft-chodorek-6man-multigroup-multicast-addr-04.txt
 Multiple multicast addressing architecture
 
 draft-chodorek-6man-multigroup-multicast-addr-04.txt
 Date: 07/02/2017
 Authors: Robert Chodorek
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces a new class of IPv6 multicast addresses called "multiple multicast". We define multiple multicast as a set of multicast addresses belonging to one multicast session.
    
draft-chodorek-traffic-flow-option-06.txt
 An IP option for describing the traffic flow
 
 draft-chodorek-traffic-flow-option-06.txt
 Date: 12/12/2016
 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-chodorek-tsvwg-rsvp-dynamic-resv-04.txt
 RSVP Extensions for Dynamic Reservation
 
 draft-chodorek-tsvwg-rsvp-dynamic-resv-04.txt
 Date: 23/12/2016
 Authors: Robert Chodorek, Agnieszka Chodorek
 Working Group: Individual Submissions (none)
 Formats: txt
RSVP reservations are static in nature and typically last for the whole session. The proposed extension to the RSVP allows the RSVP to make elastic adjustments to reservations for the current demand of network resources. The proposed method dynamically changes the RSVP reservations on the basis of knowledge about transmitted traffic.
    
draft-chowbat-irl-00.txt
 Internet Research Labs
 
 draft-chowbat-irl-00.txt
 Date: 15/02/2017
 Authors: harish@nixi.in, Mohit Batra, Nalini Elkins
 Working Group: Individual Submissions (none)
 Formats: txt
Many people learn technical concepts best in a hands-on environment, and Internet protocols and standards are no exception. Internet Research Labs (IRL) will facilitate a platform and encourage the technical community (seasoned professionals and newcomers alike) to discuss, collaborate, design and develop utilities, ideas, sample code and solutions that show practical implementations (Proof of Concept) of existing IETF standards. These labs may also be used by the IETF Mentoring Program and/or EDU teams for hands-on training to mentees or newcomers. This base draft intends to provide a high-level overview of the concept of Internet Research Labs in terms of objectives, requirements, challenges and deliverables without going into details of a specific lab, technology or an IETF Working Group (WG). After this draft matures and gains traction within the IETF community, we foresee more and more Internet drafts for the specific labs.
    
draft-clw-rfc6434-bis-01.txt
 IPv6 Node Requirements
 
 draft-clw-rfc6434-bis-01.txt
 Date: 13/03/2017
 Authors: Tim Chown, John Loughney, Timothy Winters
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-cope-heh-01.txt
 Hash-Encrypt-Hash,a block cipher mode of operation
 
 draft-cope-heh-01.txt
 Date: 21/12/2016
 Authors: Alex Cope
 Working Group: Individual Submissions (none)
 Formats: xml txt
This memo describes a block cipher mode of operation known as Hash- Encrypt-Hash (HEH).
    
draft-copeland-rtcweb-p2p-idp-auth-00.txt
 Requirements for Trust and Privacy in WebRTC Peer-to-peer Authentication
 
 draft-copeland-rtcweb-p2p-idp-auth-00.txt
 Date: 26/09/2016
 Authors: Rebecca Copeland, Kevin Corre, Ingo Friese, Saad El Jaouhari
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document studies the relationships of WebRTC communication users with their web Calling Services (CS) and their Identity Providers (IdPs), in order to identify requirements for IdP based peer-to-peer authentication. This study focuses in particular on issues of privacy, security and trust that are raised by the introduction of the IdP into the WebRTC call model, and by a different browser-based calling paradigm, compared with Mobile networks or traditional VoIP systems. The document lists privacy and trust scenarios for WebRTC authentication for individuals as well as organizations. This contribution is proposed to the RTCWEB working group.
    
draft-cuellar-ace-pat-priv-enhanced-authz-tokens-04.txt
 Privacy-Enhanced Tokens for Authorization in ACE
 
 draft-cuellar-ace-pat-priv-enhanced-authz-tokens-04.txt
 Date: 29/12/2016
 Authors: Jorge Cuellar, prabhakaran1989@gmail.com, Daniel Calvo
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification defines PAT, "Privacy-Enhanced-Authorization- Tokens" or "Pseudonym-based Authorization Tokens", a protocol and a token construction procedure for client authorization in a constrained environment. This memo also specifies a profile for ACE framework for Authentication and Authorization for constrained environments. This draft uses CBOR Web Token (CWT) and CBOR Object Signing and Encryption (COSE) to encode PAT messages.
    
draft-daigle-deen-ggie-uri-snaptr-00.txt
 Glass to Glass Internet Ecosystem URI and S-NAPTR Use
 
 draft-daigle-deen-ggie-uri-snaptr-00.txt
 Date: 20/10/2016
 Authors: Leslie Daigle, Glenn Deen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the URI scheme "median" for "media networks" as defined in the Glass to Glass Internet Ecosystem work, as well as the necessary components to resolve median URIs using the S-NAPTR system.
    
draft-daigle-iasa-retrospective-00.txt
 After the first decade: IASA Retrospective
 
 draft-daigle-iasa-retrospective-00.txt
 Date: 31/10/2016
 Authors: Leslie Daigle
 Working Group: Individual Submissions (none)
 Formats: txt
The IETF Administrative Support Activity was formally established and undertaken as a project of the Internet Society in 2005. In the following 10+ years, the IETF has grown and changed, as have the responsibilities that fall to the IASA. This document reflects on some of those changes and the implications within the IASA structure, providing some areas for further discussion to consider evolvingthe IASA and the IETF/ISOC relationship.
    
draft-davids-dmarc-fi-tag-01.txt
 DMARC Failure reporting Interval tag
 
 draft-davids-dmarc-fi-tag-01.txt
 Date: 24/11/2016
 Authors: Marco Davids
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document extends the DMARC (RFC7489) record format by defining an additional tag. This new tag, the "fi" tag, is to be used in conjunction with the "ruf" tag used for message-specific failure reporting. It provides a Domain Owner with a simple way of requesting limitation of the rate at which such reports are sent.
    
draft-dawes-sipcore-mediasec-parameter-05.txt
 Security Mechanism Names for Media
 
 draft-dawes-sipcore-mediasec-parameter-05.txt
 Date: 16/11/2016
 Authors: Peter Dawes
 Working Group: Individual Submissions (none)
 Formats: txt
Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is described in [2]. This document adds the capability to distinguish security mechanisms that apply to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label such security mechanisms.
    
draft-dawra-idr-srv6-vpn-00.txt
 BGP Signaling of IPv6-Segment-Routing-based VPN Networks
 
 draft-dawra-idr-srv6-vpn-00.txt
 Date: 13/03/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 xml
This draft defines procedures and messages for BGP SRv6-based EVPNs and L3 VPNs. It builds on RFC7432 "BGP MPLS-Based Ethernet VPN" and RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" to provide a migration path from MPLS-based VPNs to SRv6 based VPNs.
    
draft-decraene-idr-next-hop-capability-03.txt
 BGP Next-Hop dependant capabilities
 
 draft-decraene-idr-next-hop-capability-03.txt
 Date: 26/01/2017
 Authors: Bruno Decraene, Kireeti Kompella, Wim Henderickx
 Working Group: Individual Submissions (none)
 Formats: txt xml
RFC 5492 defines capabilities advertisement for the BGP peer. In addition, it is useful to be able to advertise BGP Next-Hop dependant capabilities, in particular for forwarding plane features. RFC 5492 is not applicable because the BGP peer may be different from the BGP Next-Hop, in particular when BGP Route Reflection is used. This document defines a mechanism to advertise such BGP Next Hop dependant Capabilities. This document defines a new BGP non-transitive attribute to carry Next-Hop Capabilities. This attribute is deleted or possibly modified when the BGP Next Hop is changed. This document also defines a Next-Hop capability to advertise the ability to handle the MPLS Entropy Label defined in RFC 6790. It updates RFC 6790 with regard to this BGP signaling.
    
draft-deen-daigle-ggie-02.txt
 Glass to Glass Internet Ecosystem Introduction
 
 draft-deen-daigle-ggie-02.txt
 Date: 24/10/2016
 Authors: Glenn Deen, Leslie Daigle
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the Glass to Glass Internet Ecosystem (GGIE). GGIE's purpose is to improve how the Internet is used create and consume video, both amateur and professional, reflecting that the line between amateur and professional video technology is increasingly blurred. Glass to Glass refers to the entire video ecosystem, from the camera lens to the viewing screen. As the name implies, GGIE's scope is the entire video ecosystem from capture, through the steps of editing, packaging, distributed and searching, and finally viewing. GGIE is not a complete end to end architecture or solution, it provides foundational elements that can serve as building blocks for new Internet video innovation. This is a companion effort to the GGIE W3C Taskforce in the W3C Web and TV Interest Group. This document is being discussed on the ggie@ietf.org mailing list.
    
draft-defoy-netslices-3gpp-network-slicing-00.txt
 Network Slicing - 3GPP Use Case
 
 draft-defoy-netslices-3gpp-network-slicing-00.txt
 Date: 06/03/2017
 Authors: Xavier de Foy, Akbar Rahman
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes work conducted at the 3GPP standard organization on 5G Network Slicing. Its goal is to provide a detailed use case, and help better define requirements, for Internet Protocols supporting Network Slicing.
    
draft-dejong-remotestorage-08.txt
 remoteStorage
 
 draft-dejong-remotestorage-08.txt
 Date: 29/11/2016
 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-saag-dhcp-keys-00.txt
 DHCP Keys via 802.1X
 
 draft-dekok-saag-dhcp-keys-00.txt
 Date: 24/10/2016
 Authors: Alan DeKok
 Working Group: Individual Submissions (none)
 Formats: txt
While RFC 3118 made provisions for securing DHCP, it made no provisions for creating or distributing authentication keys. This specification describes how in some cases, DHCP keys can be automatically derived from 802.1X authentication. The pros and cons of this approach are also discussed
    
draft-deng-chinese-names-05.txt
 Pronouncing and Using Chinese Personal Names
 
 draft-deng-chinese-names-05.txt
 Date: 26/12/2016
 Authors: DENG Hui, Zhen Cao, Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document gives general rules for how to pronounce Mandarin Chinese names in conversation, and how to determine which name is someone's surname. It also covers some other related topics about Chinese names. The intent is to allow IETF participants who are not familiar with Chinese to communicate better with Chinese participants.
    
draft-deshmukh-mpls-rsvp-rmr-extension-00.txt
 RSVP Extensions for RMR
 
 draft-deshmukh-mpls-rsvp-rmr-extension-00.txt
 Date: 10/03/2017
 Authors: Abhishek Deshmukh, Kireeti Kompella
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-dfranke-ntp-data-minimization-02.txt
 NTP Client Data Minimization
 
 draft-dfranke-ntp-data-minimization-02.txt
 Date: 27/03/2017
 Authors: Daniel Franke, Aanchal Malhotra
 Working Group: Network Time Protocol (ntp)
 Formats: xml txt
This memo proposes backward-compatible updates to the Network Time Protocol to strip unnecessary identifying information from client requests and to improve resilience against blind spoofing of unauthenticated server responses.
    
draft-dfranke-nts-00.txt
 Network Time Security
 
 draft-dfranke-nts-00.txt
 Date: 07/10/2016
 Authors: Daniel Franke
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo specifies Network Time Security (NTS), a mechanism for using Datagram TLS to provide cryptographic security for the Network Time Protocol or other network time synchronization protocols.
    
draft-dharini-ccamp-dwdm-if-param-yang-01.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-01.txt
 Date: 13/03/2017
 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 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 draft-ietf-ccamp-flexi-grid-fwk 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-03.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-03.txt
 Date: 13/03/2017
 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-actn-poi-use-case-07.txt
 Packet Optical Integration (POI) Use Cases for Abstraction and Control of TE Networks (ACTN)
 
 draft-dhody-actn-poi-use-case-07.txt
 Date: 28/10/2016
 Authors: Dhruv Dhody, Xian Zhang, Oscar de Dios, Daniele Ceccarelli, Bin-Yeong Yoon
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Abstraction and Control of TE Networks (ACTN) use cases related to Packet and Optical Integration (POI), that may be potentially deployed in various TE networks and apply to different applications.
    
draft-dhody-pce-applicability-actn-02.txt
 Applicability of Path Computation Element (PCE) for Abstraction and Control of TE Networks (ACTN)
 
 draft-dhody-pce-applicability-actn-02.txt
 Date: 13/03/2017
 Authors: Dhruv Dhody, Young Lee, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: xml txt
Abstraction and Control of TE Networks (ACTN) refers to the set of virtual network operations needed to orchestrate, control and manage large-scale multi-domain TE networks so as to facilitate network programmability, automation, efficient resource sharing, and end-to- end virtual service aware connectivity and network function virtualization services. 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. This document examines the applicability of PCE to the ACTN framework.
    
draft-dhody-pce-association-attr-06.txt
 Path Computation Element communication Protocol extension for relationship between LSPs and Attributes
 
 draft-dhody-pce-association-attr-06.txt
 Date: 12/03/2017
 Authors: Dhruv Dhody, Wenson Wu
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS). This document defines a mechanism to create associations between a set of LSPs and a set of attributes (such as configuration parameters).
    
draft-dhody-pce-association-policy-00.txt
 Path Computation Element communication Protocol extension for associating Policies and LSPs
 
 draft-dhody-pce-association-policy-00.txt
 Date: 28/10/2016
 Authors: Dhruv Dhody, Siva Sivabalan, Stephane Litkowski, Jeff Tantsura, Jonathan Hardwick
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a simple mechanism to associate policies to a group of Label Switched Paths (LSPs) via an extension to the Path Computation Element (PCE) Communication Protocol (PCEP).
    
draft-dhody-pce-of-diverse-06.txt
 PCE support for Maximizing Diversity
 
 draft-dhody-pce-of-diverse-06.txt
 Date: 28/10/2016
 Authors: Dhruv Dhody, Qin Wu
 Working Group: Individual Submissions (none)
 Formats: xml txt
The computation of one or a set of Traffic Engineering Label Switched Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks is subject to a set of one or more specific optimization criteria, referred to as objective functions. In the Path Computation Element (PCE) architecture, a Path Computation Client (PCC) may want a set of services that are required to be diverse (disjointed) from each other. In case when full diversity could not be achieved, it is helpful to maximize diversity as much as possible (or in other words, minimize the common shared resources). This document defines objective function code types for three new objective functions for this purpose to be applied to a set of synchronized path computation requests.
    
draft-dhody-pce-pcep-exp-codepoints-03.txt
 Experimental Codepoint Allocation for Path Computation Element communication Protocol (PCEP)
 
 draft-dhody-pce-pcep-exp-codepoints-03.txt
 Date: 27/03/2017
 Authors: Dhruv Dhody, Daniel King
 Working Group: Individual Submissions (none)
 Formats: txt xml
IANA assigns values to the Path Computation Element (PCE) communication Protocol (PCEP) parameters (messages, objects, TLVs). IANA established a new top-level registry to contain all PCEP codepoints and sub-registries. The allocation policy for each new registry is by IETF Consensus. This document seeks to mark some codepoints for experimental usage of PCEP.
    
draft-dhody-pce-pcep-p2mp-per-destination-11.txt
 Supporting Explicit Inclusion or Exclusion of Abstract Nodes for a Subset of P2MP Destinations in Path Computation Element Communication Protocol (PCEP).
 
 draft-dhody-pce-pcep-p2mp-per-destination-11.txt
 Date: 13/03/2017
 Authors: Dhruv Dhody, Udayasree Palle, Venugopal Kondreddy
 Working Group: Individual Submissions (none)
 Formats: xml txt
The ability to determine paths of point-to-multipoint (P2MP) Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering Label Switched Paths (TE LSPs) is one the key requirements for Path Computation Element (PCE). The PCEP has been extentded for intra and inter domain path computation via PCE(s) for P2MP TE LSP. This document describes the motivation and PCEP extension for explicitly specifying abstract nodes for inclusion or exclusion for a subset of destinations during P2MP path computation via PCE(s).
    
draft-dhody-pce-recv-srlg-06.txt
 PCEP Extensions for Receiving SRLG Information
 
 draft-dhody-pce-recv-srlg-06.txt
 Date: 28/10/2016
 Authors: Dhruv Dhody, Fatai Zhang, Xian Zhang, Victor Lopezalvarez, Oscar de Dios
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) provides functions of path computation in support of traffic engineering (TE) in networks controlled by Multi-Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS). This document provides extensions for the Path Computation Element Protocol (PCEP) to receive Shared Risk Link Group (SRLG) information during path computation via encoding this information in the path computation reply message.
    
draft-dhody-pce-stateful-pce-interdomain-04.txt
 Stateful Path Computation Element (PCE) Inter-domain Considerations
 
 draft-dhody-pce-stateful-pce-interdomain-04.txt
 Date: 12/03/2017
 Authors: Dhruv Dhody, Xian Zhang
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 extentions to PCEP.
    
draft-dhody-pce-stateful-pce-vendor-02.txt
 Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for stateful PCE.
 
 draft-dhody-pce-stateful-pce-vendor-02.txt
 Date: 11/03/2017
 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 stateful PCE.
    
draft-dhodylee-pce-pcep-ls-07.txt
 PCEP Extension for Distribution of Link-State and TE Information.
 
 draft-dhodylee-pce-pcep-ls-07.txt
 Date: 01/03/2017
 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-dhodylee-pce-stateful-hpce-03.txt
 Hierarchical Stateful Path Computation Element (PCE).
 
 draft-dhodylee-pce-stateful-hpce-03.txt
 Date: 13/03/2017
 Authors: Dhruv Dhody, Young Lee, Daniele Ceccarelli, Jongyoon Shin, Daniel King, Oscar de Dios
 Working Group: Individual Submissions (none)
 Formats: txt
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). The Hierarchical Path Computation Element (H-PCE) architecture, provides an architecture to allow the optimum sequence of inter-connected domains to be selected, and network policy to be applied if applicable, via the use of a hierarchical relationship between PCEs. Combining the capabilities of Stateful PCE and the Hierarchical PCE would be advantageous. This document describes general considerations and use cases for the deployment of Stateful PCE(s) using the Hierarchical PCE architecture.
    
draft-diao-aeip-nam-08.txt
 Autonomous Extensible Internet with Network Address Multiplexing(AEIP NAM)
 
 draft-diao-aeip-nam-08.txt
 Date: 13/02/2017
 Authors: Diao Yuping, Diao Yongping, Ming Liao
 Working Group: Individual Submissions (none)
 Formats: txt
The two key issues of today's Internet are autonomy and extensibility. Autonomous Internet(AIP) technology can provide extensible internet architecture, own independent root DNS servers and self management internet network; Furthermore, based on the Autonomous Internet, here provides a way with extensible address capacity to solve IP address deficiency and realize Autonomous Extensible Internet(AEIP) with global network address and multiplexing local network address. This AEIP with Network Address Multiplexing(AEIP NAM) can realize autonomy and extensibility with minimal cost.
    
draft-diao-aeip-nat-07.txt
 Autonomous Extensible Internet with Network Address Translation(AEIP NAT)
 
 draft-diao-aeip-nat-07.txt
 Date: 14/10/2016
 Authors: Diao Yongping, Ming Liao, Diao Yuping
 Working Group: Individual Submissions (none)
 Formats: txt
The two key issues of today's Internet are autonomy and extensibility. Autonomous Internet(AIP) technology can provide extensible internet architecture, own independent root DNS servers and self management internet network; Furthermore, based on the Autonomous Internet, here provides a way with extensible address capacity to solve IP address deficiency and realize Autonomous Extensible Internet(AEIP). It mainly adopts local network address based on per Autonomous IP network and uses bilateral dynamic NAT with global network address between Autonomous IP networks to solve IP address deficient problem. This AEIP with Network Address Translation(AEIP NAT) can realize autonomy and extensibility with minimal cost.
    
draft-diao-aip-dns-10.txt
 DNS Extension for Autonomous Internet(AIP)
 
 draft-diao-aip-dns-10.txt
 Date: 18/01/2017
 Authors: Diao Yuping, Diao Yongping, Ming Liao
 Working Group: Individual Submissions (none)
 Formats: txt
With the reality of Internet, Autonomous Internet technology in this article constructs independent autonomous extensible domain name architecture and domain name hierarchy through current domain name architecture, provides independent root DNS server, inner/outer DNS resolution mechanism for each autonomous internet network system, and provides reformation and transition solution from current Internet to realize autonomy even in unilateral technical action.
    
draft-dnoveck-nfsv4-nfsulb-00.txt
 Transport-generic Network File System (NFS) Upper Layer Bindings To RPC- Over-RDMA
 
 draft-dnoveck-nfsv4-nfsulb-00.txt
 Date: 01/02/2017
 Authors: David Noveck
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies Upper Layer Bindings to allow use of RPC- over-RDMA by protocols related to the Network File System (NFS). Such bindings are required when using RPC-over-RDMA, in order to enable use of Direct Data Placement and for a number of other reasons. These bindings are structured to be applicable to all known version of the RPC-over-RDMA transport, including optional extensions. All versions of NFS are addressed.
    
draft-dnoveck-nfsv4-rpcrdma-rtissues-03.txt
 Issues Related to RPC-over-RDMA Internode Round Trips
 
 draft-dnoveck-nfsv4-rpcrdma-rtissues-03.txt
 Date: 27/02/2017
 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-01.txt
 RPC-over-RDMA Extensions to Reduce Internode Round-trips
 
 draft-dnoveck-nfsv4-rpcrdma-rtrext-01.txt
 Date: 03/12/2016
 Authors: David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
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 purpose 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-dnsop-eden-alias-rr-type-00.txt
 Alias RR Type
 
 draft-dnsop-eden-alias-rr-type-00.txt
 Date: 29/03/2017
 Authors: Anthony Eden
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a new DNS record type, ALIAS, which is used by authoritative name servers to resolve a stored host name to its corresponding A or AAAA records at request time.
    
draft-dolson-plus-middlebox-benefits-03.txt
 Beneficial Functions of Middleboxes
 
 draft-dolson-plus-middlebox-benefits-03.txt
 Date: 09/03/2017
 Authors: David Dolson, Juho Snellman, Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
At IETF97, at a meeting regarding the Path Layer UDP Substrate (PLUS) protocol, a request was made for documentation about the benefits that might be provided by permitting middleboxes to have some visibility to transport-layer information. This document summarizes benefits provided to the Internet 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, in particular the PLUS and QUIC working groups, to aid understanding of what might be gained or lost by design decisions that may affect (or be affected by) middlebox operation.
    
draft-dong-network-slicing-problem-statement-00.txt
 Problem Statement of Network Slicing in IP/MPLS Networks
 
 draft-dong-network-slicing-problem-statement-00.txt
 Date: 31/10/2016
 Authors: Jie Dong, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: txt
The research and standardization of IMT-2020 (a.k.a. 5G) are in progress in several industry communities and standard organizations. The goal of 5G is to integrate various services, each of which has a set of unique requirements, into a single network, such that each service has a customized network suited to its needs. The concept "Network Slicing" is widely discussed and considered as the key mechanism to meet the diverse service requirements concurrently with the same physical network infrastructure. This document provides an overview of the concept "network slicing" in the current IMT-2020 (a.k.a. 5G) related works, and discusses the corresponding requirements on IP/MPLS network, which will be used as the mobile transport network for 5G.
    
draft-dong-ospf-flush-mitigation-00.txt
 LSA Flushing Problem Mitigation in OSPF Networks
 
 draft-dong-ospf-flush-mitigation-00.txt
 Date: 31/10/2016
 Authors: Jie Dong, Xudong Zhang, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
In OSPF protocol, LSAs with the LS age at MaxAge are not used in routing table calculation and MUST be flushed in the network. In some cases, the flushing of OSPF MaxAge LSAs may cause flooding storm of OSPF packets and severely impact network stability and the services provided by the network. This document specifies a backward compatible mechanism to mitigate the impact of MaxAge LSA flushing in OSPF networks.
    
draft-dong-ospf-maxage-flush-problem-statement-01.txt
 OSPF LSA Flushing Problem Statement
 
 draft-dong-ospf-maxage-flush-problem-statement-01.txt
 Date: 31/10/2016
 Authors: Jie Dong, Xudong Zhang, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
In OSPF protocol, Link State Advertisements (LSAs) are exchanged in Link State Update (LSU) packets to achieve link state database (LSDB) synchronization and consistent route calculation. OSPF protocol specifies several scenarios in which an LSA is flushed with the LS age field set to MaxAge. In some cases, the flushing of MaxAge LSAs may cause flooding storm of OSPF packets and severely impact the services provided by the network. This document describes the problem of OSPF LSA flushing, and ask for solutions to solve this problem.
    
draft-dong-pce-discovery-proto-bgp-06.txt
 BGP Extensions for Path Computation Element (PCE) Discovery
 
 draft-dong-pce-discovery-proto-bgp-06.txt
 Date: 27/10/2016
 Authors: Jie Dong, Mach Chen, Dhruv Dhody, Jeff Tantsura, Kenji Kumaki, Tomoki Murai
 Working Group: Individual Submissions (none)
 Formats: txt
In networks where a Path Computation Element (PCE) is used for path computation, it is desirable for the Path Computation Clients (PCCs) to discover dynamically and automatically a set of PCEs along with certain information relevant for PCE selection. RFC 5088 and RFC 5089 define the PCE discovery mechanisms based on Interior Gateway Protocols (IGP). This document defines extensions to BGP for the advertisement of PCE Discovery information. The BGP based PCE discovery mechanism is complementary to the existing IGP based mechanisms.
    
draft-donnelly-capport-detection-01.txt
 Captive Portal (CAPPORT) API
 
 draft-donnelly-capport-detection-01.txt
 Date: 13/03/2017
 Authors: Mark Donnelly, Margaret Cullen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an HTTP API that allows User Equipment to detect the existence of a Captive Portal on the local network, determine the properties of the Captive Portal, and satisfy requirements for network access.
    
draft-doron-dots-telemetry-00.txt
 Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry Specifications
 
 draft-doron-dots-telemetry-00.txt
 Date: 30/10/2016
 Authors: Ehud Doron, Tirumaleswar Reddy, Flemming Andreasen, Liang Xia, Kaname Nishizuka
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document aims to enrich DOTS Signaling with various telemetry attributes allowing optimal DDoS/DoS attack mitigation. The nature of the DOTS architecture is to allow DOTS Agents to be integrated in highly diverse environments. Therefore, the DOTS architecture imposes a significant challenge in delivering optimal mitigation services. The DOTS Telemetry covered in this document aims to provide all needed attributes and feedback signaled from DOTS Agents such that optimal mitigation services can be delivered based on DOTS Signaling.
    
draft-douglass-icalendar-series-00.txt
 Support for Series in iCalendar
 
 draft-douglass-icalendar-series-00.txt
 Date: 15/02/2017
 Authors: Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This specification updates [RFC5545] by defining a new repeating set of events known as a series. This differs from recurrences in that each instance is a separate entity with a parent relationship to a specified template entity.
    
draft-douglass-subscription-upgrade-01.txt
 Calendar subscription upgrades
 
 draft-douglass-subscription-upgrade-01.txt
 Date: 16/02/2017
 Authors: Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This specification introduces an approach to allow subscribers to calendar feeds to upgrade to a more performant protocol.
    
draft-drake-bess-datacenter-gateway-02.txt
 Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Data Center Interconnection
 
 draft-drake-bess-datacenter-gateway-02.txt
 Date: 16/10/2016
 Authors: John Drake, Adrian Farrel, Eric Rosen, Keyur Patel, Luay Jalil
 Working Group: Individual Submissions (none)
 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. 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 data center site to which it provides access, and also to advertise on behalf of each other gateway to the same data center site.
    
draft-dreibholz-ipv4-flowlabel-25.txt
 An IPv4 Flowlabel Option
 
 draft-dreibholz-ipv4-flowlabel-25.txt
 Date: 22/01/2017
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6.
    
draft-dreibholz-rserpool-applic-distcomp-22.txt
 Applicability of Reliable Server Pooling for Real-Time Distributed Computing
 
 draft-dreibholz-rserpool-applic-distcomp-22.txt
 Date: 22/01/2017
 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-21.txt
 Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility
 
 draft-dreibholz-rserpool-applic-mobility-21.txt
 Date: 22/01/2017
 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-20.txt
 Handle Resolution Option for ASAP
 
 draft-dreibholz-rserpool-asap-hropt-20.txt
 Date: 22/01/2017
 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-19.txt
 Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling
 
 draft-dreibholz-rserpool-delay-19.txt
 Date: 22/01/2017
 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-17.txt
 Takeover Suggestion Flag for the ENRP Handle Update Message
 
 draft-dreibholz-rserpool-enrp-takeover-17.txt
 Date: 22/01/2017
 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-07.txt
 Ideas for a Next Generation of the Reliable Server Pooling Framework
 
 draft-dreibholz-rserpool-nextgen-ideas-07.txt
 Date: 22/01/2017
 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-20.txt
 Reliable Server Pooling (RSerPool) Bakeoff Scoring
 
 draft-dreibholz-rserpool-score-20.txt
 Date: 22/01/2017
 Authors: Thomas Dreibholz, Michael Tuexen
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.
    
draft-dreibholz-tsvwg-sctp-nextgen-ideas-05.txt
 Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)
 
 draft-dreibholz-tsvwg-sctp-nextgen-ideas-05.txt
 Date: 22/01/2017
 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-14.txt
 SCTP Socket API Extensions for Concurrent Multipath Transfer
 
 draft-dreibholz-tsvwg-sctpsocket-multipath-14.txt
 Date: 22/01/2017
 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-14.txt
 Sender Queue Info Option for the SCTP Socket API
 
 draft-dreibholz-tsvwg-sctpsocket-sqinfo-14.txt
 Date: 22/01/2017
 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-05.txt
 The Applicability of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL)
 
 draft-dreibholz-vnfpool-rserpool-applic-05.txt
 Date: 20/02/2017
 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-ds-functional-architecture-00.txt
 Data providing service requirements and functional architecture
 
 draft-ds-functional-architecture-00.txt
 Date: 15/02/2017
 Authors: Eui-Nam Huh, gawon@khu.ac.kr, Yunkon Kim, Jintaek Kim
 Working Group: Individual Submissions (none)
 Formats: txt
The standard describes concept and characteristics of data providing service. To derive functional architecture, requirements are described on the perspective of providing and using data.
    
draft-ds-overview-00.txt
 Data providing service definition,concept,and use-cases
 
 draft-ds-overview-00.txt
 Date: 15/02/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 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-dt-detnet-dp-sol-00.txt
 DetNet Data Plane solution
 
 draft-dt-detnet-dp-sol-00.txt
 Date: 13/03/2017
 Authors: Jouni Korhonen, Loa Andersson, Yuanlong Jiang, Balazs Varga, Janos Farkas, Carlos Bernardos, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a PseudoWire-based Deterministic Networking data plane solution. The data plane solution can be applied over either IP or MPLS Packet Switched Networks.
    
draft-dt-nvo3-encap-01.txt
 NVO3 Encapsulation Considerations
 
 draft-dt-nvo3-encap-01.txt
 Date: 13/03/2017
 Authors: Sami Boutros, Sam Aldrin, Uri Elzur, Ilango Ganga, Rajeev Manur, David Mozes, Michael Smith
 Working Group: Individual Submissions (none)
 Formats: txt
As communicated by WG Chairs, the IETF NVO3 chairs and Routing Area director have chartered a design team to take forward the encapsulation discussion and see if there is potential to design a common encapsulation that addresses the various technical concerns. There are implications of different encapsulations in real environments consisting of both software and hardware implementations and spanning multiple data centers. For example, OAM functions such as path MTU discovery become challenging with multiple encapsulations along the data path. The design team recommend Geneve with few modifications as the common encapsulation, more details are described in section 7.
    
draft-dt-rmcat-feedback-message-01.txt
 RTP Control Protocol (RTCP) Feedback for Congestion Control
 
 draft-dt-rmcat-feedback-message-01.txt
 Date: 28/10/2016
 Authors: Zaheduzzaman Sarker, Colin Perkins, Varun Singh, Michael Ramalho
 Working Group: RTP Media Congestion Avoidance Techniques (rmcat)
 Formats: txt xml
This document describes a feedback message intended to enable congestion control for interactive real-time traffic. The RTP Media Congestion Avoidance Techniques (RMCAT) Working Group formed a design team to analyze feedback requirements from various congestion control algorithms and to design a generic feedback message to help ensure interoperability across those algorithms. The feedback message is designed for a sender-based congestion control, which means the receiver of the media will send necessary feedback to the sender of the media to perform the congestion control at the sender.
    
draft-du-anima-an-intent-05.txt
 ANIMA Intent Policy and Format
 
 draft-du-anima-an-intent-05.txt
 Date: 14/02/2017
 Authors: Zongpeng Du, Sheng Jiang, Jeferson Nobre, Laurent Ciavaglia, Michael Behringer
 Working Group: Individual Submissions (none)
 Formats: xml txt
One of the goals of autonomic networking is to simplify the management of networks by human operators. Intent Based Networking (IBN) is a possible approach to realize this goal. With IBN, the operator indicates to the network what to do (i.e. her intent) and not how to do it. In the field of Policy Based Management (PBM), the concept of intent is called a declarative policy. This document proposes a refinement of the intent concept initially defined in [RFC7575] for autonomic networks by providing a more complete definition, a life-cycle, some use cases and a tentative format of the ANIMA Intent Policy.
    
draft-duchene-mptcp-load-balancing-00.txt
 Multipath TCP Load Balancing
 
 draft-duchene-mptcp-load-balancing-00.txt
 Date: 31/10/2016
 Authors: Fabien Duchene, Vladimir Olteanu, Olivier Bonaventure, Costin Raiciu
 Working Group: Individual Submissions (none)
 Formats: txt
In this document we propose several solutions to allow Multipath TCP to better work behind load balancers.
    
draft-dugeon-brpc-stateful-00.txt
 A Backward Recursive PCE-initiated inter-domain LSP Setup
 
 draft-dugeon-brpc-stateful-00.txt
 Date: 13/03/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 tunnels 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 BGP 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 LSP tunnels. This draft propose to combine a Backward Recursive method with PCInitiate message to setup independent LSP tunnels per domain and stitch or nest the different LSP tunnels to setup end-to-end inter-domain LSP tunnels without the need of inter- domain signaling between BGP border routers. A new Stitching Label definition and new LSP-TYPE code points are proposed for that purpose.
    
draft-dukes-lisp-colored-engineered-underlays-00.txt
 LISP Colored Engineered Underlays
 
 draft-dukes-lisp-colored-engineered-underlays-00.txt
 Date: 11/03/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 that can be used to select an engineered underlay path to the corresponding RLOC.
    
draft-dulaunoy-dnsop-passive-dns-cof-02.txt
 Passive DNS - Common Output Format
 
 draft-dulaunoy-dnsop-passive-dns-cof-02.txt
 Date: 24/10/2016
 Authors: Alexandre Dulaunoy, Aaron Kaplan, Paul Vixie, Henry Stern
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a common output format of Passive DNS Servers which clients can query. The output format description includes also in addition a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily.
    
draft-dulaunoy-misp-core-format-00.txt
 MISP core format
 
 draft-dulaunoy-misp-core-format-00.txt
 Date: 15/10/2016
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-taxonomy-format-01.txt
 MISP taxonomy format
 
 draft-dulaunoy-misp-taxonomy-format-01.txt
 Date: 13/02/2017
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the MISP taxonomy format which describes a simple JSON format to represent machine tags (also called triple tags) vocabularies. A public directory of common vocabularies MISP taxonomies is available and relies on the MISP taxonomy format.
    
draft-dunbar-e2e-latency-arch-view-and-gaps-01.txt
 Architectural View of E2E Latency and Gaps
 
 draft-dunbar-e2e-latency-arch-view-and-gaps-01.txt
 Date: 28/03/2017
 Authors: Linda Dunbar
 Working Group: Individual Submissions (none)
 Formats: txt
Ultra-Low Latency is a highly desired property for many types of services, such as 5G MTC (Machine Type Communication) requiring E2E connection for V2V to be less than 2ms, AR/VR requiring delay less than 5ms, V2X less than 20ms, etc. This draft examines the E2E latency from architectural perspective, from studying how different OSI layers contribute to E2E latency, how different domains, which can be different operators' domains or administrative domains, contribute to E2E latency, to analyzing the gaps of recent technology advancement in reducing latency. By studying the contributing factors to E2E latency from various angles, the draft identifies some gaps of recent technology advancement for E2E services traversing multiple domains and involving multiple layers, which can be the basis for IAB to organize more in-depth discussion, like workshop or cross Area (or industry wide) BOF, as the scope of the discussion will be too wide for one IETF WG. The discussion might touch upon multiple IETF areas. The goal of those further "deep-dive" workshop or cross area BOF is to establish more comprehensive foundation to IESG and the IETF community in identifying potential new work initiatives for reducing E2E latency of services over the Internet.
    
draft-dunbar-opsawg-private-networks-over-thin-cpe-01.txt
 Client Defined Private Networks laid over Thin CPEs
 
 draft-dunbar-opsawg-private-networks-over-thin-cpe-01.txt
 Date: 31/10/2016
 Authors: Linda Dunbar, Lucy Yong
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a type of private networks that interconnect thin CPEs at multiple client sites by IP tunnels, or more specifically, lay over multiple client sites' Thin CPEs via IP tunnels. Those private overlay networks not only interconnect those sites by secure IP tunnels but can also enforce the client specified policies to govern how applications or hosts within those sites communicate and how to access public internet. Hosts or applications in those sites can be interconnected by Layer 2 networks or/and by Layer 3 networks. The network that the IP tunnels are traversing can be IPv4 or IPv6 networks. This document describes the special properties of the client defined networks over Thin CPEs. A separate draft will describes the special features that those IP tunnels need to have in order to interconnect multiple sites as if those sites are directly connected by wires and how communication policies are enforced.
    
draft-dwpz-pce-domain-diverse-06.txt
 PCE support for Domain Diversity
 
 draft-dwpz-pce-domain-diverse-06.txt
 Date: 28/10/2016
 Authors: Dhruv Dhody, Qin Wu, Udayasree Palle, Xian Zhang
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Path Computation Element (PCE) may be used for computing path for services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks. Path computation should facilitate the selection of paths with domain diversity. This document examines the existing mechanisms to do so and further propose some extensions to Path Computation Element Protocol (PCEP).
    
draft-eastlake-fnv-12.txt
 The FNV Non-Cryptographic Hash Algorithm
 
 draft-eastlake-fnv-12.txt
 Date: 13/12/2016
 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-05.txt
 Additional XML Security Uniform Resource Identifiers (URIs)
 
 draft-eastlake-rfc6931bis-xmlsec-uris-05.txt
 Date: 28/03/2017
 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-rfc7042bis-01.txt
 IANA Considerations and IETF Protocol and Documentation Usage for IEEE 802 Parameters
 
 draft-eastlake-rfc7042bis-01.txt
 Date: 12/12/2016
 Authors: Donald Eastlake, Joe Abley
 Working Group: Individual Submissions (none)
 Formats: txt
Some IETF protocols make use of Ethernet frame formats and IEEE 802 parameters. This document discusses several uses of such parameters in IETF protocols, specifies IANA considerations for assignment of points under the IANA OUI (Organizationally Unique Identifier), and provides some values for use in documentation. This document obsoletes RFC 7042.
    
draft-eastlake-trill-group-keying-01.txt
 TRILL: Group Keying
 
 draft-eastlake-trill-group-keying-01.txt
 Date: 28/12/2016
 Authors: Donald Eastlake
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a general group keying protocol. It also provides use profiles for the application of this group keying protocol to multi-destination TRILL Extended RBridge Channel message security and TRILL over IP packet security.
    
draft-eastlake-trill-link-security-05.txt
 TRILL: Link Security
 
 draft-eastlake-trill-link-security-05.txt
 Date: 27/03/2017
 Authors: Donald Eastlake, Dacheng Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
The TRILL protocol supports arbitrary link technologies between TRILL switches, both point-to-point and broadcast links, and supports Ethernet links between edge TRILL switches and end stations. Communications links are constantly under attack by criminals and national intelligence agencies as discussed in RFC 7258. Link security is an important element of security in depth, particularly for links that are not entirely under the physical control of the TRILL network operator or that include device which may have been compromised. This document specifies link security recommendations for TRILL over Ethernet, PPP, and pseudowire links. It updates RFC 6325, RFC 6361, and RFC 7173. It requires that link encryption MUST be implemented and that all TRILL Data packets between TRILL switch ports capable of encryption at line speed MUST default to being encrypted. [This is a early partial draft.]
    
draft-eddy-tsvwg-saratoga-tfrc-10.txt
 TFRC-based Congestion Control for Saratoga
 
 draft-eddy-tsvwg-saratoga-tfrc-10.txt
 Date: 19/11/2016
 Authors: Wesley Eddy, lloyd.wood@yahoo.co.uk, 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-elie-nntp-tls-recommendations-05.txt
 Use of Transport Layer Security (TLS) in the Network News Transfer Protocol (NNTP)
 
 draft-elie-nntp-tls-recommendations-05.txt
 Date: 07/02/2017
 Authors: Julien Elie
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
This document provides recommendations for improving the security of the Network News Transfer Protocol (NNTP) when using Transport Layer Security (TLS). It modernizes the NNTP usage of TLS to be consistent with TLS best current practices. If approved, this document updates RFC 4642.
    
draft-elie-nntp-tls-recommendations-rfc4642bis-01.txt
 Modernization of RFC 4642
 
 draft-elie-nntp-tls-recommendations-rfc4642bis-01.txt
 Date: 04/01/2017
 Authors: Julien Elie
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document shows the sections that changed between RFC 4642 and draft-elie-nntp-tls-recommendations. The -00 version contains the wording in RFC 4642. The -01 version contains the wording in draft- elie-nntp-tls-recommendations-04.
    
draft-elkchow-iea-deploy-00.txt
 Deployment Issues for Internationalized Email
 
 draft-elkchow-iea-deploy-00.txt
 Date: 04/10/2016
 Authors: Nalini Elkins, harish@nixi.in
 Working Group: Individual Submissions (none)
 Formats: txt
International Email Addresses (IEA) are far from the global reality. The current de-facto language of the Internet is English. Even today, many of the users of the Internet do not speak English as their primary language. The next billion users of the Internet are likely to be even less familiar with English. IEA is probably the first application needed in a truly internationalized Internet. The Email Address Internationalization (EAI) Working Group defined the RFCs to support internationalized email. The time may now finally have come to develop best practices and to discuss the deployment challenges for IEA.
    
draft-elkins-ippm-pdm-nn-00.txt
 Using PDM to Monitor Net Neutrality
 
 draft-elkins-ippm-pdm-nn-00.txt
 Date: 29/03/2017
 Authors: Nalini Elkins
 Working Group: Individual Submissions (none)
 Formats: txt
Monitoring of net neutrality is of interest to regulators as well as users throughout the world. Standardized metrics are lacking. Measurements need to be at the end user client, be able to accurately separate wire and host time, detect quality of service provided to individual applications and be lightweight. The IPv6 Performance and Diagnostic Metrics (PDM) Destination Option meets all these criteria. We propose that PDM be used for such measurements. A gap analysis shows that PDM is available for IPv6 only and not for IPv4 or low powered devices.
    
draft-elkins-mtgvenue-participation-metrics-01.txt
 Definition of Participation Metrics for IETF Attendees
 
 draft-elkins-mtgvenue-participation-metrics-01.txt
 Date: 31/10/2016
 Authors: Nalini Elkins, Vinayak Hegde
 Working Group: Individual Submissions (none)
 Formats: txt
IETF meetings are held physically in various geographic regions of the world. One of the criteria for choosing a location is the amount of participation by the people in that region. Additionally, questions arise as to whether holding a physical meeting in a location increases the amount of participation by local attendees. Participation in the IETF process may occur in a number of different ways: email lists, writing drafts, physical or remote attendance at a meeting, chairing Working Groups and so on. This document defines the metrics and terms which may be used to measure participation both before and after an IETF meeting.
    
draft-eriksson-http-resource-map-00.txt
 Resource Maps
 
 draft-eriksson-http-resource-map-00.txt
 Date: 31/10/2016
 Authors: Goran Eriksson, Christer Holmberg, Zaheduzzaman Sarker, Julian Reschke
 Working Group: Individual Submissions (none)
 Formats: txt xml
When the 'out-of-band' content coding ('OOB') is used for delivering a number of resources from a primary server via a secondary server, the additional round trips for OOB responses and load on the primary server can be a significant nuisance. In such situations, it is useful for the primary server to be able to provide the client with OOB response information for several resources in one go anticipating future client requests. This document describes a format for providing the client with the information, called a resource map, and how the resource map could be delivered to a client.
    
draft-ermagan-lisp-nat-traversal-12.txt
 NAT traversal for LISP
 
 draft-ermagan-lisp-nat-traversal-12.txt
 Date: 06/03/2017
 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-03.txt
 LISP Control Plane integration with NSH
 
 draft-ermagan-lisp-nsh-03.txt
 Date: 27/03/2017
 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-eromenko-ipff-05.txt
 Intended status: Standards Track A.Eromenko September 2016
 
 draft-eromenko-ipff-05.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies version 5 of the Internet Protocol (IPv5). a.k.a Internet Protocol Five Fields, that started as a hybrid between IPv4 and IPv6, but solved problems in innovative ways, and significantly improved on both.
    
draft-eromenko-ipff-addressing-05.txt
 Intended status: Standards Track A. Eromenko September 2016
 
 draft-eromenko-ipff-addressing-05.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines the addressing architecture of the IP Version 5 (IPFF) protocol. The document includes the IPFF addressing model, text representations of IPFF addresses, definition of IPFF unicast addresses, anycast addresses, and multicast addresses.
    
draft-eromenko-ipff-arp-01.txt
 Intended status: Standards Track
 
 draft-eromenko-ipff-arp-01.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
Address Resolution Protocol in IPv5 is basically the same as in IPv4, and it is intended to resolve Data Link Layer Ethernet addresses to Network Layer IP-FF addresses, in addition to Duplicate Address Detection (DAD), includes optional duplicate MAC address detection. This spec was written for IEEE 802.3 Ethernet links or compatible. Separate specifications may be required for other link types.
    
draft-eromenko-ipff-babysitter-02.txt
 Intended status: Standards Track A.Eromenko September 2016
 
 draft-eromenko-ipff-babysitter-02.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
Babysitter is a form of an advanced NAT, mostly for desktop clients. It gives mixed IP-FF and IPv4 clients access to IPv4-only Internet. It is somewhat resembling NAT64 + DNS64 combo, and will aid during transition period. Assumption: We work on IPv4-only Internet, but we want to implement both IP-FF and IPv4 hosts inside our organization, so nodes can work between themselves with, and take advantage of, IP-FF, but still able to connect to the Internet. If/when this assumption is invalid, and end-to-end IP-FF becomes commonplace, other forms of connection should be used, and babysitter may be disabled.
    
draft-eromenko-ipff-design-decisions-00.txt
 Intended status: Informational A.Eromenko September 2016
 
 draft-eromenko-ipff-design-decisions-00.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
Goal of IP-FF: provide future growth, without design complexity of IPv6. This document writes the design decisions behind IP-FF and explains why they were done.
    
draft-eromenko-ipff-dhcp-02.txt
 Intended status: Standards Track
 
 draft-eromenko-ipff-dhcp-02.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the changes needed from DHCPv4, as defined in RFC-2131, to bring DHCP to IP-FF.
    
draft-eromenko-ipff-dns-02.txt
 Intended status: Standards Track
 
 draft-eromenko-ipff-dns-02.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the changes that need to be made to the Domain Name System (DNS) to support hosts running IP version 5 (IPFF). The changes include a resource record type to store an IPFF address, a domain to support lookups based on an IPFF address, and updated definitions of existing query types that return Internet addresses as part of additional section processing. The extensions are designed to be compatible with existing applications and, in particular, DNS implementations themselves.
    
draft-eromenko-ipff-fdp-00.txt
 Intended status: Standards Track A.Eromenko September 2016
 
 draft-eromenko-ipff-fdp-00.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
A heavy-weight version of the UDP protocol, intended to provide simple fragmentation mechanism with Internet Protocol "Five Fields", along with a stronger checksum at a cost of somewhat higher overhead.
    
draft-eromenko-ipff-icmp-04.txt
 Intended status: Standards Track
 
 draft-eromenko-ipff-icmp-04.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the format of a set of control messages used in ICMPv5 (Internet Control Message Protocol). ICMPv5 is the Internet Control Message Protocol for Internet Protocol Five Fields (IPFF).
    
draft-eromenko-ipff-mops-02.txt
 Intended status: Experimental A.Eromenko September 2016
 
 draft-eromenko-ipff-mops-02.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a mechanism, that can be used to live-migrate opened TCP/UDP/other transport sessions between a mobile server and a mobile client. This can work even after a mobile node moved to a different subnet or disconnected, as long as a session did not timeout. It also describes limitations and includes NAT traversal scenarios and guidelines for "middlebox" vendors.
    
draft-eromenko-ipff-tcp64-04.txt
 Intended status: Standards Track A.Eromenko September 2016
 
 draft-eromenko-ipff-tcp64-04.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
This document attempts to modernize TCP protocol for new reality, faster bandwidth, encryption-optimization and optional checksums, which is required for Identity-Locator Network Protocol (ILNP) compatibility. This extension is backwards compatible with the original TCP specification during session establishment, but not compatible during the rest of the session nor with deployed middleboxes.
    
draft-eromenko-ipff-udp-03.txt
 Intended status: Standards Track A.Eromenko September 2016
 
 draft-eromenko-ipff-udp-03.txt
 Date: 29/09/2016
 Authors: Alexey Eromenko
 Working Group: Individual Submissions (none)
 Formats: txt
Minor modification of the UDP protocol to reduce overhead by 2 bytes. Intended to be used with Internet Protocol "Five Fields".
    
draft-esale-ldp-rmr-extensions-00.txt
 LDP Extensions for RMR
 
 draft-esale-ldp-rmr-extensions-00.txt
 Date: 31/10/2016
 Authors: Santosh Esale, Kireeti Kompella
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes LDP extensions to signal Resilient MPLS Ring (RMR) Label Switched Paths (LSPs). An RMR LSP is a multipoint to point LSP signaled using LDP (Label Distribution Protocol). RMR Architecture document - draft-ietf-mpls-rmr-02 - describes why and how MPLS should be used in ring topologies.
    
draft-esale-mpls-ldp-node-frr-05.txt
 Fast Reroute for Node Protection in LDP-based LSPs
 
 draft-esale-mpls-ldp-node-frr-05.txt
 Date: 13/03/2017
 Authors: Santosh Esale, Raveendra Torvi, Luyuan Fang, Luay Jalil
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes procedures to support node protection for unicast Label Switched Paths (LSPs) established by Label Distribution Protocol (LDP). In order to protect a node N, the Point of Local Repair (PLR) of N must discover the Merge Points (MPs) of node N such that traffic can be redirected to them in case of node N failure. Redirecting the traffic around the failed node N depends on existing point-to-point LSPs originated from the PLR to the MPs while bypassing the protected node N. The procedures described in this document are topology independent in a sense that they provide node protection in any topology so long as there is a alternate path in the network that avoids the protected node.
    
draft-esale-mpls-ldp-rmr-extensions-00.txt
 LDP Extensions for RMR
 
 draft-esale-mpls-ldp-rmr-extensions-00.txt
 Date: 13/03/2017
 Authors: Santosh Esale, Kireeti Kompella
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes LDP extensions to signal Resilient MPLS Ring (RMR) Label Switched Paths (LSPs). An RMR LSP is a multipoint to point LSP signaled using LDP (Label Distribution Protocol). RMR Architecture document - draft-ietf-mpls-rmr-02 - describes why and how MPLS should be used in ring topologies.
    
draft-evens-grow-bmp-adj-rib-out-00.txt
 Support for Adj-RIB-Out in BGP Monitoring Protocol (BMP)
 
 draft-evens-grow-bmp-adj-rib-out-00.txt
 Date: 13/03/2017
 Authors: Tim Evens, Serpil Bayraktar, Manish Bhardwaj, Paolo Lucente
 Working Group: Individual Submissions (none)
 Formats: txt
The BGP Monitoring Protocol (BMP) defines access to only the Adj-RIB- In Routing Information Bases (RIBs). This document updates the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the Adj-RIB- Out RIBs. It adds a new flag to the peer header to distinguish Adj- RIB-In and Adj-RIB-Out.
    
draft-evens-grow-bmp-local-rib-00.txt
 Support for Local RIB in BGP Monitoring Protocol (BMP)
 
 draft-evens-grow-bmp-local-rib-00.txt
 Date: 13/03/2017
 Authors: Tim Evens, Serpil Bayraktar, Manish Bhardwaj, Paolo Lucente
 Working Group: Individual Submissions (none)
 Formats: txt
The BGP Monitoring Protocol (BMP) defines access to the Adj-RIB-In and locally originated routes (e.g. routes distributed into BGP from protocols such as static) but not access to the BGP instance Loc-RIB. This document updates the BGP Monitoring Protocol (BMP) RFC 7854 by adding access to the BGP instance Local-RIB, as defined in RFC 4271 the routes that have been selected by the local BGP speaker's Decision Process. These are the routes over all peers, locally originated, and after best-path selection.
    
draft-fan-bess-pm-bgp-00.txt
 BGP Extension For L3VPN Performance Monitoring
 
 draft-fan-bess-pm-bgp-00.txt
 Date: 28/12/2016
 Authors: Jiajia Fan, Zhenbin Li, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a new VT address family in BGP to exchange information required for apply performance monitoring in MPLS/BGP VPN, as described in [I-D.dong-l3vpn-pm-framework].
    
draft-fan-ccamp-gmpls-g709v5-ospf-ext-00.txt
 GMPLS Routing Extension for Optical Transport Networks with Beyond 100G in G.709 Edition 5
 
 draft-fan-ccamp-gmpls-g709v5-ospf-ext-00.txt
 Date: 09/03/2017
 Authors: Zheyu Fan
 Working Group: Individual Submissions (none)
 Formats: txt
The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended the Recommendation G.709 to support beyond 100G (B100G) features. Corresponding Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol extensions are included in this document.
    
draft-fan-yang-mac-00.txt
 A Yang Data Model for MAC Management
 
 draft-fan-yang-mac-00.txt
 Date: 29/12/2016
 Authors: Huihua Fan
 Working Group: Individual Submissions (none)
 Formats: txt
This memo proposes a yang model for MAC management.
    
draft-faq-netmod-cpe-yang-profile-01.txt
 YANG Models Required for Managing Residential Gateway (RG) Devices
 
 draft-faq-netmod-cpe-yang-profile-01.txt
 Date: 13/03/2017
 Authors: Ian Farrer, Qi Sun, Sladjana Zoric, Mikael Abrahamsson
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document collects together the set of YANG models necessary for managing NETCONF-enabled Residential Gateway (RG) devices.
    
draft-farinacci-lisp-eid-anonymity-01.txt
 LISP EID Anonymity
 
 draft-farinacci-lisp-eid-anonymity-01.txt
 Date: 31/10/2016
 Authors: Dino Farinacci, Padma Pillay-Esnault
 Working Group: Individual Submissions (none)
 Formats: txt
This specification will describe how ephemeral LISP EIDs can be used to create source anonymity. The idea makes use of frequently changing EIDs much like how a credit-card system uses a different credit-card numbers for each transaction.
    
draft-farinacci-lisp-geo-02.txt
 LISP Geo-Coordinate Use-Cases
 
 draft-farinacci-lisp-geo-02.txt
 Date: 28/10/2016
 Authors: Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols.
    
draft-farinacci-lisp-name-encoding-03.txt
 LISP Distinguished Name Encoding
 
 draft-farinacci-lisp-name-encoding-03.txt
 Date: 27/03/2017
 Authors: Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines how to use the AFI=17 Distinguished Names in LISP.
    
draft-farinacci-lisp-predictive-rlocs-01.txt
 LISP Predictive RLOCs
 
 draft-farinacci-lisp-predictive-rlocs-01.txt
 Date: 13/11/2016
 Authors: Dino Farinacci, Padma Pillay-Esnault
 Working Group: Individual Submissions (none)
 Formats: txt
This specification will describe a method to achieve near-zero packet loss when an EID is roaming quickly across RLOCs.
    
draft-farinacci-lisp-rig-05.txt
 LISP-DDT Referral Internet Groper (RIG)
 
 draft-farinacci-lisp-rig-05.txt
 Date: 16/12/2014
 Authors: Dino Farinacci, Amit Jain, Isidor Kouvelas, Darrel Lewis
 Working Group: Individual Submissions (none)
 Formats: txt
A simple tool called the LISP-DDT Referral Internet Groper or 'rig' can be used to query the LISP-DDT hierarchy. This draft describes how the 'rig' tool works.
    
draft-farinacci-lisp-te-12.txt
 LISP Traffic Engineering Use-Cases
 
 draft-farinacci-lisp-te-12.txt
 Date: 28/02/2017
 Authors: Dino Farinacci, Michael Kowal, Parantap Lahiri
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how LISP reencapsulating tunnels can be used for Traffic Engineering purposes. The mechanisms described in this document require no LISP protocol changes but do introduce a new locator (RLOC) encoding. The Traffic Engineering features provided by these LISP mechanisms can span intra-domain, inter-domain, or combination of both.
    
draft-farkas-detnet-flow-information-model-00.txt
 DetNet Flow Information Model Based on TSN
 
 draft-farkas-detnet-flow-information-model-00.txt
 Date: 12/03/2017
 Authors: Janos Farkas, Balazs Varga, rodney.cummings@ni.com
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document describes flow information model for Deterministic Networking (DetNet). The DetNet service is provided either for a Layer 3 or a Layer 2 flow. This document provides DetNet flow information model both for Layer 3 and Layer 2 flows in an integrated fashion.
    
draft-farrel-sfc-convent-01.txt
 Operating the Network Service Header (NSH) with Next Protocol "None"
 
 draft-farrel-sfc-convent-01.txt
 Date: 16/02/2017
 Authors: Adrian Farrel, Lucy Yong, John Drake
 Working Group: Individual Submissions (none)
 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 only carrying 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-soon-04.txt
 A Definition of the Term "Soon" for Use in Discussions with Working Group Chairs and Area Directors
 
 draft-farrel-soon-04.txt
 Date: 21/02/2017
 Authors: Adrian Farrel
 Working Group: Individual Submissions (none)
 Formats: xml txt
Many discussions with IETF Area Directors and Working Group Chairs utilize the word "soon" to qualify a commitment to action. This document attempts to provide a definition of that term so that common expectations may be realistically set.
    
draft-farrell-lpwan-lora-overview-01.txt
 LoRaWAN Overview
 
 draft-farrell-lpwan-lora-overview-01.txt
 Date: 28/10/2016
 Authors: Stephen Farrell, Alper Yegin
 Working Group: Individual Submissions (none)
 Formats: xml txt
Low Power Wide Area Networks (LPWAN) are wireless technologies covering different Internet of Things (IoT) applications. The common characteristics for LPWANs are large coverage, low bandwidth, small packet and application layer data sizes and long battery life operation. One of these technologies is LoRaWAN developed by the LoRa Alliance. LoRaWAN targets key requirements of the Internet of things such as secure bi-directional communication, mobility and localization services. This memo is an informational overview of LoRaWAN and gives the principal characteristics of this technology in order to help with the IETF work for providing IPv6 connectivity over LoRaWAN along with other LPWANs.
    
draft-femmreali-sfc-offpath-signaling-03.txt
 Off-Path Signaling Protocol for Service Function Chaining
 
 draft-femmreali-sfc-offpath-signaling-03.txt
 Date: 01/12/2016
 Authors: Mauro Femminella, Gianluca Reali, Dario Valocchi
 Working Group: Individual Submissions (none)
 Formats: txt
This document illustrates a reference protocol able to discover deployed instances of Service Functions (SFs), which can be located also off-path with respect to the IP datapath between flow source and flow destination. It is an application protocol organized in two layers: signaling transport, which deal lower layer signaling transport, and signaling application, which directly interfaces with the intended SF. Discovery of SFs is a primary step to for implementing Service Function Chaining (SFC).
    
draft-fenton-smtp-require-tls-03.txt
 SMTP Require TLS Option
 
 draft-fenton-smtp-require-tls-03.txt
 Date: 13/02/2017
 Authors: Jim Fenton
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
The SMTP STARTTLS option, used in negotiating transport-level encryption of SMTP connections, is not as useful from a security standpoint as it might be because of its opportunistic nature; message delivery is prioritized over security. This document describes a complementary SMTP service extension, REQUIRETLS. If the REQUIRETLS option is used when sending a message, it asserts a request on the part of the message sender to override the default negotiation of TLS, either by requiring that TLS be negotiated when the message is relayed, or by requesting that policy mechanisms such as SMTP STS and DANE be ignored when relaying a high priority message.
    
draft-fieau-cdni-https-delegation-01.txt
 HTTPS delegation in CDNI
 
 draft-fieau-cdni-https-delegation-01.txt
 Date: 13/03/2017
 Authors: Frederic Fieau, Stephan Emile, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document examines probable solutions for delegating encrypted content delivery within the context of CDN interconnection. The HTTPS delegation also expects delivering content without compromising security, integrity and user privacy.
    
draft-fieau-cdni-interfaces-https-delegation-00.txt
 CDNI interfaces update for HTTPS delegation
 
 draft-fieau-cdni-interfaces-https-delegation-00.txt
 Date: 13/03/2017
 Authors: Frederic Fieau, Stephan Emile, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
Content delivery includes one or more CDNs and in many instances involves cascaded delegation when handling encrypted data. The delivery of such content over HTTPS though raises credential management issues. Two models of HTTPS delegation can be considered: direct delegation, and "cascaded" delegation. While the first model of delegation is addressed by most of the work at the IETF, in the latter case, it is up to downstream CDN(s) delivering the content to an end-user to present legacy credentials of either the origin or of the upstream CDN which delegated the delivery to the aforementioned dCDN. This document presents updates needed in CDNI Control and Metadata interfaces to setup HTTPS delegation between an uCDN and dCDN.
    
draft-filsfils-spring-large-scale-interconnect-05.txt
 Interconnecting Millions Of Endpoints With Segment Routing
 
 draft-filsfils-spring-large-scale-interconnect-05.txt
 Date: 07/12/2016
 Authors: Clarence Filsfils, Dennis Cai, Stefano Previdi, Wim Henderickx, Dave Cooper, Tim Laberge, Steven Lin, Bruno Decraene, Luay Jalil, jefftant@gmail.com, Rob Shakir
 Working Group: Source Packet Routing in Networking (spring)
 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-00.txt
 Segment Routing Policy for Traffic Engineering
 
 draft-filsfils-spring-segment-routing-policy-00.txt
 Date: 18/02/2017
 Authors: Clarence Filsfils, Siva Sivabalan, Daniel Yoyer, Mohan Nanduri, Steven Lin, bogdanov@google.com, Martin Horneffer, Francois Clad, Dirk Steinberg, Bruno Decraene, Stephane Litkowski
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. 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-sr-recursing-info-03.txt
 Segment Routing Recursive Information
 
 draft-filsfils-spring-sr-recursing-info-03.txt
 Date: 17/10/2016
 Authors: Clarence Filsfils, Stefano Previdi, Peter Psenak, Les Ginsberg
 Working Group: Source Packet Routing in Networking (spring)
 Formats: txt
Segment Routing (SR) allows for a flexible definition of end-to-end paths within IGP topologies by encoding paths as sequences of topological sub-paths, called "segments". These segments are advertised by the link-state routing protocols (IS-IS and OSPF). There are use cases where it is desirable to utilize a SID associated with a given node in order to transport traffic destined to different local services supported by such node. This document defines the mechanism to do so and illustrates it.
    
draft-filsfils-spring-srv6-network-programming-00.txt
 SRv6 Network Programming
 
 draft-filsfils-spring-srv6-network-programming-00.txt
 Date: 09/03/2017
 Authors: Clarence Filsfils, 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, Arthi Ayyangar, Satish Mynam, Ahmed Bashandy, Kamran Raza, Darren Dukes, Francois Clad, Pablo Camarillo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the SRv6 network programming concept and its most basic functions.
    
draft-fioccola-ippm-alt-mark-active-01.txt
 Alternate Marking Extension to Active Measurement Protocol
 
 draft-fioccola-ippm-alt-mark-active-01.txt
 Date: 13/03/2017
 Authors: Giuseppe Fioccola, Alexander Clemm, Stewart Bryant, Mauro Cociglio, Mouli Chandramouli, Alessandro Capello
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how to extend the existing Active Measurement Protocol, in order to implement alternate marking methodology detailed in [I-D.ietf-ippm-alt-mark]. The extension for Two-Way Active Measurement Protocol (TWAMP) RFC 5357 [RFC5357] and One-way Active Measurement Protocol (OWAMP) RFC 4656 [RFC4656] will be considered. RFC6374 [RFC6374] Use Case is also reported. This proposal defines a simplified mechanism with benefits to the metric precision and computational load. Hybrid measurements are also enabled.
    
draft-flanagan-7322bis-00.txt
 RFC Style Guide
 
 draft-flanagan-7322bis-00.txt
 Date: 10/03/2017
 Authors: Heather Flanagan, RFC Editor
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-flinck-mobile-throughput-guidance-04.txt
 Mobile Throughput Guidance Inband Signaling Protocol
 
 draft-flinck-mobile-throughput-guidance-04.txt
 Date: 13/03/2017
 Authors: Ankur Jain, Andreas Terzis, Hannu Flinck, Nurit Sprecher, Swaminathan Arunachalam, Kevin Smith, Vijay Devarapalli, Roni Yanai
 Working Group: Individual Submissions (none)
 Formats: txt
The bandwidth available for end user devices in cellular networks can vary by an order of magnitude over a few seconds due to changes in the underlying radio channel conditions, as device mobility and changes in system load as other devices enter and leave the network. Furthermore, packets losses are not always signs of congestion. The Transmission Control Protocol (TCP) can have difficulties adapting to these rapidly varying conditions leading to inefficient use of a cellular network's resources and degraded application performance. Problem statement, requirements and the architecture for a solution is documented in [Req_Arch_MTG_Exposure]. This document proposes a mechanism and protocol elements that allow the cellular network to provide near real-time information on capacity available to the TCP server. This "Throughput Guidance" (TG) information would indicate the throughput estimated to be available at the radio downlink interface (between the Radio Access Network (RAN) and the mobile device (UE)). TCP server can use this TG information to ensure high network utilization and high service delivery performance. The document describes the applicability of the proposed mechanism for video delivery over cellular networks; it also presents test results from live operator's environment.
    
draft-fluhrer-qr-ikev2-03.txt
 Postquantum Preshared Keys for IKEv2
 
 draft-fluhrer-qr-ikev2-03.txt
 Date: 28/10/2016
 Authors: Scott Fluhrer, David McGrew, Panos Kampanakis
 Working Group: IP Security Maintenance and Extensions (ipsecme)
 Formats: txt xml
This document describes an extension of IKEv2 to allow it to be resistant to a Quantum Computer, by using preshared keys
    
draft-foschiano-erspan-03.txt
 Cisco Systems' Encapsulated Remote Switch Port Analyzer (ERSPAN)
 
 draft-foschiano-erspan-03.txt
 Date: 22/02/2017
 Authors: Marco Foschiano, Kalyan Ghosh, Munish Mehta
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an IP-based packet capture format that can be used to transport exact copies of packets to a network probe to analyze and characterize the operational load and protocol distribution of a network as well as to detect anomalies such as network-based worms or viruses. This replication and transport mechanism operates over one or multiple switch or router ports whose traffic can be mirrored and forwarded to a destination device in charge of traffic analysis and reporting.
    
draft-francois-dots-ipv6-signal-option-01.txt
 IPv6 DOTS Signal Option
 
 draft-francois-dots-ipv6-signal-option-01.txt
 Date: 31/10/2016
 Authors: Jerome Francois, Abdelkader Lahmadi, Marco Davids, Giovane Moura
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an optional fall-back opportunistic method that employs the IPv6 Hop-by-Hop options extension header type. It allows a DOTS client to send a signaling message over a congested network due to a DDoS attack by ''tagging'' bypassing outgoing IPv6 packets to reach a DOTS server or gateway.
    
draft-francois-rtgwg-segment-routing-uloop-01.txt
 Loop avoidance using Segment Routing
 
 draft-francois-rtgwg-segment-routing-uloop-01.txt
 Date: 14/12/2016
 Authors: Pierre Francois, Clarence Filsfils, Ahmed Bashandy, Stephane Litkowski
 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-fregly-regext-rdap-search-regex-00.txt
 Registration Data Access Protocol (RDAP) Search Using POSIX Regular Expressions
 
 draft-fregly-regext-rdap-search-regex-00.txt
 Date: 31/10/2016
 Authors: afregly@verisign.com, Swapneel Sheth, Scott Hollenbeck
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Registration Data Access Protocol (RDAP) provides limited search functionality based on pattern matching. This document describes an RDAP query extension that provides additional search functionality using POSIX extended regular expressions.
    
draft-freytag-lager-variant-rules-04.txt
 Variant Rules
 
 draft-freytag-lager-variant-rules-04.txt
 Date: 13/03/2017
 Authors: Asmus Freytag
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
Rules for validating identifier labels and alternate representations of those labels (variants) are known as "Label Generation Rulesets" (LGRs); they are used for the implementation of identifier systems such as Internationalized Domain Names (IDNs). This document describes ways of designing Label Generation Rulesets (LGRs) that support variant labels. In designing LGRs, it is important to ensure that the label generation rules are consistent and well-behaved in the presence of variants. The design decisions can then be expressed using the an XML representation of LGRs that is defined in RFC7940.
    
draft-fu-dots-ipfix-tcp-tracking-00.txt
 IP Flow Information Export (IPFIX) Information Elements Extension for TCP Connection Tracking
 
 draft-fu-dots-ipfix-tcp-tracking-00.txt
 Date: 13/03/2017
 Authors: Tianfu Fu, Chong Zhou, Hui Zheng
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes several new TCP connection related Information Elements (IEs) for the IP Flow Information Export (IPFIX) protocol. The new Information Elements can be used to export certain characteristics regarding a TCP connection. Through massive gathering of such characteristics, it can help build an image of the TCP traffics passing through a network. The image will facilitate the detection of anomaly TCP traffic, especially attacks targeting at TCP.
    
draft-fu-pce-ip-link-transport-service-mapping-01.txt
 A YANG Model for IP Link and Transport Service Mapping
 
 draft-fu-pce-ip-link-transport-service-mapping-01.txt
 Date: 29/10/2016
 Authors: Pengcheng FU, Jianzhong FU, Ruiquan Jing
 Working Group: Individual Submissions (none)
 Formats: txt
IP+optical is a cross-layer collaboration technology for unified management of IP and optical networks. Based on framework proposed in [ACTN-FWK][I-D.ietf-teas-actn-framework], this draft presents specific information about the IP+optical solution: hierarchical controllers + disabled GMPLS UNIs. This solution does not involve UNI tunnel objects. Therefore, the mapping between IP links and transport services is key point of this solution. This draft provides a YANG model for the RESTCONF/NETCONF protocol. This YANG module defines NBIs for the IP+optical super controller.
    
draft-fu-pce-vnt-protection-group-01.txt
 A YANG Model for VNT (IP Link) Protection Group
 
 draft-fu-pce-vnt-protection-group-01.txt
 Date: 29/10/2016
 Authors: Pengcheng FU, Jianzhong FU, Ruiquan Jing
 Working Group: Individual Submissions (none)
 Formats: txt
IP+optical is a cross-layer collaboration technology for unified management of IP and optical networks. Based on framework proposed in [ACTN- FWK][I-D.ietf-teas-actn-framework], this draft presents specific information about the IP+optical solution: hierarchical controllers + disabled GMPLS UNIs. This solution does not involve UNI tunnel objects. The system uses loose-coupled dual-controllers to implement cross- layer collaborative path calculation on the virtual network topology (VNT), where the VNT provides the E2E cross-pathcalculation bridging function. The VNT needs to be defined as a YANG model for configuration management. This draft provides a YANG model for the RESTCONF/NETCONF protocol. This YANG module defines NBIs for the IP+optical super controller.
    
draft-fujimoto-urn-onem2m-00.txt
 A Uniform Resource Name (URN) Namespace for the oneM2M Partnership Project (oneM2M)
 
 draft-fujimoto-urn-onem2m-00.txt
 Date: 14/11/2016
 Authors:
 Working Group: Individual Submissions (none)
 Formats: txt
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-resolver-update-00.txt
 Updating Resolver Algorithm
 
 draft-fujiwara-dnsop-resolver-update-00.txt
 Date: 31/10/2016
 Authors: Kazunori Fujiwara
 Working Group: Domain Name System Operations (dnsop)
 Formats: txt
Parent side NS RRSet and glue records are all information to access servers for child zone. However, they may be overwritten by child zone data (zone apex NS RRSet and other A/AAAA RRSets). The overwrite makes name resolution unstable and induces vulnerabilities. RFC 2181 section 5.4.1 specifies trustworthiness of DNS data. And it is deemed that that all cached data (authoritative data, non- authoritative data, referrals and glue records) are merged into one. Resolvers may answer non-authoritative data, referrals and glue records that should not be returned. This document proposes updating resolver algorithm that separates the cache to "authoritative data cache" and "delegation cache". The former is used to answer stub resolvers, and the latter is used to iterate zones.
    
draft-fuldseth-netvc-thor-03.txt
 Thor Video Codec
 
 draft-fuldseth-netvc-thor-03.txt
 Date: 31/10/2016
 Authors: Arild Fuldseth, Gisle Bjontegaard, Steinar Midtskogen, Thomas Davies, Mo Zanaty
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides a high-level description of the Thor video codec. Thor is designed to achieve high compression efficiency with moderate complexity, using the well-known hybrid video coding approach of motion-compensated prediction and transform coding.
    
draft-galimbe-ccamp-iv-yang-02.txt
 A YANG model to manage the optical optical parameters for in a WDM network
 
 draft-galimbe-ccamp-iv-yang-02.txt
 Date: 13/03/2017
 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-01.txt
 Autonomic Slice Networking–Requirements and Reference Model
 
 draft-galis-anima-autonomic-slice-networking-01.txt
 Date: 31/10/2016
 Authors: A. Galis, Kiran Makhijani, Delei Yu
 Working Group: Individual Submissions (none)
 Formats: xml 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-pce-pm-07.txt
 PCEP Extensions for Reporting MPLS-TE LSP Performance Measurements with Stateful PCE
 
 draft-gandhi-pce-pm-07.txt
 Date: 12/03/2017
 Authors: Rakesh Gandhi, Bin Wen, Colby Barth, Dhruv Dhody
 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.
    
draft-gandhishah-teas-assoc-corouted-bidir-04.txt
 Fast Reroute Procedures For Associated Bidirectional Label Switched Paths (LSPs)
 
 draft-gandhishah-teas-assoc-corouted-bidir-04.txt
 Date: 10/03/2017
 Authors: Rakesh Gandhi, Himanshu Shah, Jeremy Whittaker
 Working Group: Individual Submissions (none)
 Formats: txt
Resource Reservation Protocol (RSVP) association signaling can be used to bind two unidirectional LSPs into an associated bidirectional LSP. When an associated bidirectional LSP is co-routed, the reverse LSP follows the same path as its forward LSP. This document describes Fast Reroute (FRR) procedures for both single-sided and double-sided provisioned associated bidirectional LSPs. The FRR procedures are applicable to co-routed and non co-routed LSPs. For co-routed LSPs, the FRR procedures can ensure that traffic flows on co-routed paths in the forward and reverse directions after a failure event.
    
draft-gao-alto-fcs-01.txt
 ALTO Extension: Flow-based Cost Query
 
 draft-gao-alto-fcs-01.txt
 Date: 13/03/2017
 Authors: Kai Gao, J. Zhang, Junzhuo Wang, Qiao Xiang, Yang Yang
 Working Group: Individual Submissions (none)
 Formats: txt
The emergence of new networking datapath capabilities has substantially increased the flexibility of networking. For example, OpenFlow has emerged as a major southbound protocol for Software- Defined Networking, and OpenFlow allows flexible routing beyond simple destination-based routing. In this document, we define a new extention to ALTO, namely the Flow Cost Service, for ALTO clients in an OpenFlow-enabled network to query ALTO network information.
    
draft-garcia-core-app-layer-sec-with-dtls-record-00.txt
 Application Layer Security for CoAP using the (D)TLS Record Layer
 
 draft-garcia-core-app-layer-sec-with-dtls-record-00.txt
 Date: 06/12/2016
 Authors: Dan Garcia, Sara Garcia, Rafael Lopez
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document briefly describes an idea to provide Application-Layer Security for CoAP using (D)TLS Record Layer, assuming it is operative in two CoAP endpoints.
    
draft-garcia-radext-radius-lorawan-02.txt
 LoRaWAN Authentication in RADIUS
 
 draft-garcia-radext-radius-lorawan-02.txt
 Date: 31/10/2016
 Authors: Dan Garcia, Rafael Lopez, Arunprabhu Kandasamy, Alexander Pelov
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a proposal for adding LoRaWAN support in RADIUS. The purpose is to integrate the LoRaWAN network join procedure with an Authentication, Authorization and Accounting (AAA) infrastructure based on RADIUS.
    
draft-gdmb-netslices-intro-and-ps-02.txt
 Network Slicing - Introductory Document and Revised Problem Statement
 
 draft-gdmb-netslices-intro-and-ps-02.txt
 Date: 14/02/2017
 Authors: A. Galis, Jie Dong, kiran.makhijani@huawei.com, Stewart Bryant, Mohamed Boucadair, Pedro Martinez-Julia
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces Network Slicing problems and the motivation for new work areas. It represents an initial revision of the Network Slicing problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem. It complements and brings together the silo efforts being carried out in several other IETF working groups to achieve certain aspects of Network Slicing functions and operations.
    
draft-geng-detnet-info-distribution-00.txt
 IGP-TE Extensions for DetNet Information Distribution
 
 draft-geng-detnet-info-distribution-00.txt
 Date: 13/03/2017
 Authors: Xuesong Geng, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt
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-netslices-architecture-00.txt
 Network Slicing Architecture
 
 draft-geng-netslices-architecture-00.txt
 Date: 13/03/2017
 Authors: 4c 67, Stewart Bryant, Jie Dong
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the overall architecture of network slicing. Base on the general architecture, basic concepts of network slicing and examples of network slicing instances are introduced for clarification purposes. Some architectural considerations about the data plane, control plane, management and orchestration of network slicing are described to give a general view of network slicing implementation principles. This also helps to identify the gaps in existing IETF works relating to network slicing.
    
draft-geng-nfvrg-distributed-nfv-00.txt
 Distributed NFV in Scattered Premises
 
 draft-geng-nfvrg-distributed-nfv-00.txt
 Date: 06/03/2017
 Authors: 4c 67
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces the distributed NFV (D-NFV) concept based on potential implementation in scattered locations including customer edge devices and transport network equipments. The motivation of pushing NFV entities from conventional centralized infrastructures to distributed promises is discussed, which are driven by the requirements of high flexibility, low end-to-end latency and faster time-to-market in future network. To better understand the D-NFV concept, examples of D-NFV implementation is introduced. Potential use cases are also described as references for readers. Gaps have also been recognized in the documents in terms of the investigation of appropriate virtualization technologies used in the D-NFV and corresponding management and orchestration challenges.
    
draft-gerdes-ace-dtls-authorize-01.txt
 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
 
 draft-gerdes-ace-dtls-authorize-01.txt
 Date: 13/03/2017
 Authors: Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz
 Working Group: Individual Submissions (none)
 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. 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-ggalimbe-ccamp-flex-if-lmp-01.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-01.txt
 Date: 13/03/2017
 Authors: Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze, Dieter Beller
 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-00.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-00.txt
 Date: 13/03/2017
 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. This document extends the GMPLS Lambda label format in accordance and extending the parameters defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its extensions.
    
draft-ghedini-tls-certificate-compression-00.txt
 Transport Layer Security (TLS) Certificate Compression
 
 draft-ghedini-tls-certificate-compression-00.txt
 Date: 01/03/2017
 Authors: Alessandro Ghedini, Victor Vasiliev
 Working Group: Individual Submissions (none)
 Formats: xml txt
In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted. This document describes how certificate chains can be compressed to reduce the amount of data transmitted and avoid some round trips.
    
draft-ginsberg-isis-te-app-00.txt
 IS-IS TE Attributes per application
 
 draft-ginsberg-isis-te-app-00.txt
 Date: 27/02/2017
 Authors: Les Ginsberg, Peter Psenak, Stefano Previdi, Wim Henderickx
 Working Group: Individual Submissions (none)
 Formats: txt xml
Existing traffic engineering related link attribute advertisements have been defined and are used in RSVP-TE deployments. In cases where multiple applications wish to make use of these link attributes the current advertisements do not support application specific values for a given attribute nor do they support indication of which applications are using the advertised value for a given link. This draft introduces new link attribute advertisements which address both of these shortcomings. It also discusses backwards compatibility issues and how to minimize duplicate advertisements in the presence of routers which do not support the extensions defined in this document.
    
draft-gjessing-taps-minset-04.txt
 A Minimal Set of Transport Services for TAPS Systems
 
 draft-gjessing-taps-minset-04.txt
 Date: 13/03/2017
 Authors: Stein Gjessing, Michael Welzl
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft recommends a minimal set of IETF Transport Services offered by end systems supporting TAPS, and gives guidance on choosing among the available mechanisms and protocols. It is based on the set of transport features given in the TAPS document draft-ietf-taps-transports-usage-03.
    
draft-goldbe-vrf-00.txt
 Verifiable Random Functions (VRFs)
 
 draft-goldbe-vrf-00.txt
 Date: 13/03/2017
 Authors: Sharon Goldberg, Dimitrios Papadopoulos, Jan Vcelak
 Working Group: Individual Submissions (none)
 Formats: txt xml
A Verifiable Random Function (VRF) is the public-key version of a keyed cryptographic hash. Only the holder of the private key can compute the hash, but anyone with public key can verify the correctness of the hash. VRFs are useful for preventing enumeration of hash-based data structures. This document specifies several VRF constructions that are secure in the cryptographic random oracle model. One VRF uses RSA and the other VRF uses Eliptic Curves (EC).
    
draft-gomez-6lo-blemesh-02.txt
 IPv6 Mesh over Bluetooth(R) Low Energy using IPSP
 
 draft-gomez-6lo-blemesh-02.txt
 Date: 31/10/2016
 Authors: Carles Gomez, Seyed Darroudi, Teemu Savolainen
 Working Group: Individual Submissions (none)
 Formats: txt xml
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable IPv6 over Bluetooth low energy networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies the mechanisms needed to enable IPv6 over mesh networks composed of Bluetooth low energy links established by using the Bluetooth Internet Protocol Support Profile.
    
draft-gomez-6lo-optimized-fragmentation-header-00.txt
 Optimized 6LoWPAN Fragmentation Header
 
 draft-gomez-6lo-optimized-fragmentation-header-00.txt
 Date: 23/10/2016
 Authors: Carles Gomez, Josep Paradells, Jon Crowcroft
 Working Group: Individual Submissions (none)
 Formats: xml txt
RFC 4944 specifies 6LoWPAN fragmentation, in order to support the IPv6 MTU requirement over IEEE 802.15.4-2003 networks. The 6LoWPAN fragmentation header format comprises a 4-byte format for the first fragment, and a 5-byte format for subsequent fragments. This specification defines a more efficient 3-byte, optimized 6LoWPAN fragmentation header for all fragments.
    
draft-gomez-lpwan-fragmentation-header-03.txt
 LPWAN Fragmentation Header
 
 draft-gomez-lpwan-fragmentation-header-03.txt
 Date: 23/10/2016
 Authors: Carles Gomez, Josep Paradells, Jon Crowcroft
 Working Group: Individual Submissions (none)
 Formats: xml txt
LPWAN technologies are characterized by a very limited data unit and/ or payload size, often one order of magnitude below the one in IEEE 802.15.4. However, many such technologies do not support layer 2 fragmentation. The 6LoWPAN fragmentation header defined in RFC 4944 represents very high overhead for LPWAN technologies, and it even does not support transporting IPv6 datagrams that require fragmentation over layer 2 technologies of a maximum payload size below 13 bytes. This specification defines an optimized fragmentation header for LPWAN.
    
draft-gomez-lwig-tcp-constrained-node-networks-02.txt
 TCP over Constrained-Node Networks
 
 draft-gomez-lwig-tcp-constrained-node-networks-02.txt
 Date: 10/03/2017
 Authors: Carles Gomez, Jon Crowcroft
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides a profile for the Transmission Control Protocol (TCP) over Constrained-Node Networks (CNNs). The overarching goal is to offer simple measures to allow for lightweight TCP implementation and suitable operation in such environments.
    
draft-gont-6man-address-usage-recommendations-02.txt
 IPv6 Address Usage Recommendations
 
 draft-gont-6man-address-usage-recommendations-02.txt
 Date: 13/03/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. It analyzes what properties are desirable for some popular scenarios, and provides advice regarding the configuration and usage of such addresses.
    
draft-gont-6man-non-stable-iids-01.txt
 Recommendation on Temporary IPv6 Interface Identifiers
 
 draft-gont-6man-non-stable-iids-01.txt
 Date: 13/03/2017
 Authors: Fernando Gont, Christian Huitema, Guillermo Gont, Madelen Corbo
 Working Group: Individual Submissions (none)
 Formats: txt
This document clarifies the stability requirements for IPv6 addresses, and provides recommendations regarding the generation of Temporary addresses. Finally, it formally updates RFC4941 such that nodes are allowed to configure only temporary addresses.
    
draft-gont-v6ops-host-configuration-01.txt
 On the Dynamic/Automatic Configuration of IPv6 Hosts
 
 draft-gont-v6ops-host-configuration-01.txt
 Date: 13/03/2017
 Authors: Fernando Gont, Gert Doering, Madelen Corbo, Guillermo Gont
 Working Group: Individual Submissions (none)
 Formats: txt
IPv6 has two different mechanisms for dynamic/automatic host configuration: SLAAC and DHCPv6. These two mechanisms allow for the configuration of IPv6 addresses and a number of network parameters. While there is overlap in the parameters that can be configured via these two protocols, different implementations support only subsets of such parameters with either mechanism, or have no support for DHCPv6 at all. This document analyzes a problem that arises from this situation, and mandates that all host implementations support RFC 6105 (DNS options for SLAAC) and the stateless DHCPv6 functionality in RFC 3315.
    
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-03.txt
 Extensible Provisioning Protocol (EPP) Internationalized Domain Name (IDN) Table Mapping
 
 draft-gould-idn-table-03.txt
 Date: 29/09/2016
 Authors: James Gould, Francisco Obispo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an Extensible Provisioning Protocol (EPP) mapping for getting Internationalized Domain Name (IDN) Table information for the registration of IDNs, using the EPP domain name mapping, and optionally with the IDN mapping extension. An IDN Table defines the valid set of characters (code points) that can be used in a domain name. Code points may overlap across IDN Tables and the IDN Tables supported by the servers are up to server policy. The IDN Table information can be used to validate an IDN prior to registration, can be cached by the client for pre-validation, can be used to select the best IDN Table for the IDN, and can be used to know if and what IDN Table Identifier to pass in a domain create.
    
draft-gould-regext-dataset-00.txt
 Data Set File Format
 
 draft-gould-regext-dataset-00.txt
 Date: 08/02/2017
 Authors: James Gould
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a Data Set File (DSF) format that can be used to define and pass bulk data between a client and a server. This format is extensible to pass any set of simple data types in a set of records contained in the body of the file. The file format also supports storing the result of processing the data set that MAY be generated by the server and returned to the client. The file format consists of an XML definition header and a Comma-Separated Values (CSV) data section delimited by "-----BEGIN DATA SET-----" and "----- END DATA SET-----" lines. The XML definition header defines the format of the CSV data section, contains additional meta-data, and optionally includes a digital signature to identify the source and ensure that the data has not been tampered with between the parties (source, client, and server). The interface (manual or automated) that is used to submit the file and receive the result file is not defined within this document.
    
draft-gredler-idr-bgplu-epe-08.txt
 Egress Peer Engineering using BGP-LU
 
 draft-gredler-idr-bgplu-epe-08.txt
 Date: 13/03/2017
 Authors: Hannes Gredler, Kaliraj Vairavakkalai, Chandrasekar R, Balaji Rajagopalan, Ebben Aries, Luyuan Fang
 Working Group: Individual Submissions (none)
 Formats: txt xml
The MPLS source routing paradigm provides path control for both intra- and inter- Autonomous System (AS) traffic. RSVP-TE is utilized for intra-AS path control. This documents outlines how MPLS routers may use the BGP labeled unicast protocol (BGP-LU) for doing traffic-engineering on inter-AS links.
    
draft-green-tls-static-dh-in-tls13-00.txt
 Data Center use of Static Diffie-Hellman in TLS 1.3
 
 draft-green-tls-static-dh-in-tls13-00.txt
 Date: 13/11/2016
 Authors: Matthew Green
 Working Group: Individual Submissions (none)
 Formats: txt
Unlike earlier versions of TLS, current drafts of TLS 1.3 have instead adopted ephemeral-mode Diffie-Hellman and elliptic-curve Diffie-Hellman as the primary cryptographic key exchange mechanism used in TLS. This document describes an optional configuration for TLS servers that allows for the use of a static Diffie-Hellman secret for all TLS connections made to the server. Passive monitoring of TLS connections can be enabled by installing a corresponding copy of this key in each monitoring device.
    
draft-greevenbosch-appsawg-cbor-cddl-10.txt
 CBOR data definition language (CDDL): a notational convention to express CBOR data structures
 
 draft-greevenbosch-appsawg-cbor-cddl-10.txt
 Date: 13/03/2017
 Authors: Henk Birkholz, Christoph Vigano, Carsten Bormann
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
This document proposes a notational convention to express CBOR data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR.
    
draft-grinnemo-taps-he-02.txt
 Happy Eyeballs for Transport Selection
 
 draft-grinnemo-taps-he-02.txt
 Date: 13/03/2017
 Authors: Karl-Johan Grinnemo, Anna Brunstrom, Per Hurtig, Naeem Khademi, Zdravko Bozakov
 Working Group: Individual Submissions (none)
 Formats: txt xml
Ideally, network applications should be able to select an appropriate transport solution from among available transport solutions. However, at present, there is no agreed-upon way to do this. In fact, there is not even an agreed-upon way for a source end host to determine if there is support for a particular transport along a network path. This draft addresses these issues, by proposing a Happy Eyeballs framework. The proposed Happy Eyeballs framework enables the selection of a transport solution that according to application requirements, pre-set policies, and estimated network conditions is the most appropriate one. Additionally, the proposed framework makes it possible for an application to find out whether a particular transport is supported along a network connection towards a specific destination or not.
    
draft-groves-coap-webrtcdc-01.txt
 A WebRTC Data Channel Transport for the Constrained Application Protocol (CoAP)
 
 draft-groves-coap-webrtcdc-01.txt
 Date: 17/10/2016
 Authors: Christian Groves, Weiwei Yang
 Working Group: Individual Submissions (none)
 Formats: xml txt
The WebRTC framework defines a generic transport service allowing WEB-browsers and other endpoints to exchange generic data from peer to peer utilizing a Stream Control Transmission Protocol (SCTP) transport. This service is known as Web Real Time Communication WebRTC data channels (WebRTC DC). The use of WebRTC DCs for the Constrained Application Protocol (CoAP) allows WebRTC enabled devices to exchange CoAP data between peers in a secure reliable manner.
    
draft-groves-core-bas-01.txt
 Binding Attribute Scope
 
 draft-groves-core-bas-01.txt
 Date: 13/03/2017
 Authors: Christian Groves, Weiwei Yang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies an additional CoAP binding attribute that allows binding attributes to be scoped to an item (sub-resource) in a collection resource. This allows synchronisation of multiple resources in a collection based on the value of one resource.
    
draft-groves-core-obsattr-00.txt
 Additional CoAP Binding and Observe Attributes
 
 draft-groves-core-obsattr-00.txt
 Date: 20/02/2017
 Authors: Christian Groves, Weiwei Yang
 Working Group: Individual Submissions (none)
 Formats: xml txt
[I-D.ietf-core-dynlink] defines five CoAP Observaton attributes (minimum period, maximum period, band step, less than and greater than) to control when notifications are sent. These attributes are insufficient for some use cases. This document specifies additional attributes allowing for notification bands, initialization values, band step, sample number window and sample time window to allow for a wider range of use cases.
    
draft-groves-core-rfc6690up-00.txt
 Addition of organisation prefix to RFC6690 IANA CoRE parameters registration
 
 draft-groves-core-rfc6690up-00.txt
 Date: 17/10/2016
 Authors: Christian Groves, Weiwei Yang
 Working Group: Individual Submissions (none)
 Formats: xml txt
[RFC6690] defines the resource type 'rt' and interface description 'if' link attributes and defines procedures for registering values. Currently each 'rt' and 'if' attribute value must be registered with IANA. This specification updates the process to enable organisation prefixes to be registered allowing organisations to manage their own namespace within a certain set of rules.
    
draft-groves-core-senml-bto-00.txt
 SenML Base Time Offset Attribute
 
 draft-groves-core-senml-bto-00.txt
 Date: 17/10/2016
 Authors: Christian Groves, Weiwei Yang
 Working Group: Individual Submissions (none)
 Formats: xml txt
SenML [I-D.ietf-core-senml] defines a base time attribute and time value which is used to determine the time when a value is recorded. In some applications a SenML package will contain a series of records related to a constant sample time interval, e.g. once every 60 seconds. This means that the time attribute will be required for each record. This document defines a new "time offset" base attribute that allows a sender to include the time for the sample interval between records. If the "time offset" base attribute is used the sender will not send the time attribute for each record, minimising message and storage size.
    
draft-groves-core-senml-options-00.txt
 SenML Options
 
 draft-groves-core-senml-options-00.txt
 Date: 09/03/2017
 Authors: Christian Groves, Weiwei Yang
 Working Group: Individual Submissions (none)
 Formats: xml txt
SenML [I-D.ietf-core-senml] defines an initial set of base and regular attributes which are tied to a particular version of SenML. SenML also allows the definition of additional attributes by extending the syntax with a new label. Allowing the extension of attributes brings the problem of how do endpoints negotiate whether the new attribute can be used or not? This document discusses the issue and proposes some potential solutions to this issue.
    
draft-grozev-perc-double-rtx-00.txt
 Using RTX with Privacy Enhanced RTP Conferencing (PERC)
 
 draft-grozev-perc-double-rtx-00.txt
 Date: 28/03/2017
 Authors: Boris Grozev, Emil Ivov
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the use of the RTX format for RTP packet retransmission in the context of a PERC (Privacy Enhanced RTP Conferenceing) conference.
    
draft-grozev-perc-ssrc-00.txt
 Allowing Synchronisation Source (SSRC) and Timestamp Rewriting in Privacy Enhanced RTP Conferencing (PERC)
 
 draft-grozev-perc-ssrc-00.txt
 Date: 28/03/2017
 Authors: Boris Grozev, Emil Ivov, Alexandre Gouaillard
 Working Group: Individual Submissions (none)
 Formats: xml txt
Privacy Enhanced RTP Conferenceing allows middle boxes (MDs) to overwrite a certain set of fields in RTP packets, as long as they preserve their original values in the Original Header Block (OHB). This draft discusses the option of extending the OHB so that it would also include the RTP timestamp and Synchornization Source identifier (SSRC) within the set of fields an SSRC can modify.
    
draft-gu-nfvrg-cloud-bng-architecture-00.txt
 Control and User Plane Seperation Architecture of Cloud based BNG
 
 draft-gu-nfvrg-cloud-bng-architecture-00.txt
 Date: 28/02/2017
 Authors: Rong Gu, Shujun Hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the architecture of Clond-based BNG devices with control plane (CP) and user plane (UP) seperation. Both BNG-CP and BNG-UP are core components for fixed broadband services and deployed seperately at different network layer.
    
draft-gu-sdnrg-network-management-consideration-02.txt
 SDN network management consideration
 
 draft-gu-sdnrg-network-management-consideration-02.txt
 Date: 29/10/2016
 Authors: Rong Gu, Ruixue Wang, Zhuangyan
 Working Group: Individual Submissions (none)
 Formats: txt
This draft introduces consideration about SDN network management after the deployment of SDN and NFV in cloud datacenters. The content of SDN network management and some specific technique are included from the network administrator's point of view.
    
draft-gu-sfc-yang-oam-00.txt
 YANG Data Model for SFC Operations,Administration,and Maintenance (OAM)
 
 draft-gu-sfc-yang-oam-00.txt
 Date: 08/01/2017
 Authors: Gu Rong, Liang Xia, Zitao Wang, Deepak Kumar, Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines YANG data model for Service Function Chaining (SFC Operations, Administration, and Maintenance). It derives from the basic YANG data model for Layer independent OAM Management defined in [I-D.ietf-lime-yang-connectionless-oam] with SFC technology specifics. It includes SFC OAM related configuration and state data.
    
draft-guballa-tls-terminology-05.txt
 Terminology related to TLS and DTLS
 
 draft-guballa-tls-terminology-05.txt
 Date: 04/10/2016
 Authors: Jens Guballa, Juergen Stoetzer-Bradler, He Bing
 Working Group: Individual Submissions (none)
 Formats: txt
Purpose of this RFC is to provide a central place of all key terms as used by the various RFCs on protocols TLS and DTLS.
    
draft-gulkohegde-routing-planes-using-sr-00.txt
 Separating Routing Planes using Segment Routing
 
 draft-gulkohegde-routing-planes-using-sr-00.txt
 Date: 13/03/2017
 Authors: Shraddha Hegde, arkadiy.gulko@thomsonreuters.com
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
Many network deployments arrange the network topologies in two or more planes. The traffic generally uses one of the planes and fails over to the other plane when there are link or node failure. Certain applications require the traffic to be strictly restricted to a particular plane and should not failover to the other plane. This document proposes a solution for the strict planar routing using Segment Routing.
    
draft-gulkohegde-spring-routing-planes-using-sr-00.txt
 Separating Routing Planes using Segment Routing
 
 draft-gulkohegde-spring-routing-planes-using-sr-00.txt
 Date: 28/03/2017
 Authors: Shraddha Hegde, arkadiy.gulko@thomsonreuters.com
 Working Group: Individual Submissions (none)
 Formats: txt xml
Many network deployments arrange the network topologies in two or more planes. The traffic generally uses one of the planes and fails over to the other plane when there are link or node failure. Certain applications require the traffic to be strictly restricted to a particular plane and should not failover to the other plane. This document proposes a solution for the strict planar routing using Segment Routing.
    
draft-gundogan-icnrg-pub-iot-00.txt
 Publish-Subscribe Deployment Option for NDN in the Constrained Internet of Things
 
 draft-gundogan-icnrg-pub-iot-00.txt
 Date: 13/03/2017
 Authors: Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-05.txt
 Simple Certificate Enrolment Protocol
 
 draft-gutmann-scep-05.txt
 Date: 24/11/2016
 Authors: Peter Gutmann
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-07.txt
 TLS 1.2 Update for Long-term Support
 
 draft-gutmann-tls-lts-07.txt
 Date: 05/02/2017
 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-idr-extended-experimental-01.txt
 Extended Experimental Path Attributes for BGP
 
 draft-haas-idr-extended-experimental-01.txt
 Date: 01/03/2017
 Authors: Jeffrey Haas
 Working Group: Individual Submissions (none)
 Formats: xml txt
BGP's primary feature extension mechanism, Optional-Transitive Path Attributes, has proven to be a successful mechanism to permit BGP to be extended. In order to ease various issues during the development of new BGP features, this document proposes an extended experimental Path Attribute to carry prototype features.
    
draft-haberman-ntpwg-mode-6-cmds-02.txt
 Control Messages Protocol for Use with Network Time Protocol Version 4
 
 draft-haberman-ntpwg-mode-6-cmds-02.txt
 Date: 17/10/2016
 Authors: David Mills, Brian Haberman
 Working Group: Network Time Protocol (ntp)
 Formats: txt
This document describes the structure of the control messages used with the Network Time Protocol. These control messages can be used to monitor and control the Network Time Protocol application running on any IP network attached computer. The information in this document was originally described in Appendix B of RFC 1305. The goal of this document is to provide a historic description of the control messages.
    
draft-hall-iasa20-workshops-report-00.txt
 Report from the IASA 2.0 Virtual Workshops
 
 draft-hall-iasa20-workshops-report-00.txt
 Date: 13/03/2017
 Authors: Joseph Hall, Jean Mahoney
 Working Group: Individual Submissions (none)
 Formats: txt xml
This is the Workshop Report for the IETF Administrative Support Activity 2.0 (IASA 2.0) Virtual Workshops, held on 28 February 2017 at 1100 UT and 1600 UT. The original IETF Administrative Support Activity (IASA) was created ten years ago, and since has been subject to some reflection. In the intervening years, there has been considerable change in the necessary tasks of IETF administration and in the world around the IETF, and in how the IETF raises funds and finances its work. The IASA 2.0 process seeks to address which administrative arrangements will best support the IETF going forward.
    
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-iccrg-arvr-transport-problem-01.txt
 Problem Statement: Transport Support for Augmented and Virtual Reality Applications
 
 draft-han-iccrg-arvr-transport-problem-01.txt
 Date: 12/03/2017
 Authors: Lin Han, Kevin Smith
 Working Group: Individual Submissions (none)
 Formats: txt
As emerging technology, Augmented Reality (AR) and Virtual Reality (VR) bring up a lot of challenges to technologies such as information display, image processing, fast computing and networking. This document will analyze the requirements of AR and VR to networking, especially to transport protocol.
    
draft-han-netmod-intf-ext-ppp-yang-02.txt
 Yang Data Model for PPP Protocol
 
 draft-han-netmod-intf-ext-ppp-yang-02.txt
 Date: 27/02/2017
 Authors: Hansance Han, Xianghua Gu, Hua Lv, James Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage PPP.
    
draft-hao-jpake-05.txt
 J-PAKE: Password Authenticated Key Exchange by Juggling
 
 draft-hao-jpake-05.txt
 Date: 14/11/2016
 Authors: Feng Hao
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a Password Authenticated Key Exchange by Juggling (J-PAKE) protocol. This protocol allows the establishment of a secure end-to-end communication channel between two remote parties over an insecure network solely based on a shared password, without requiring a Public Key Infrastructure (PKI) or any trusted third party.
    
draft-hao-rtgwg-ip-hard-pipes-02.txt
 Protocol Independent (Hardened) Bandwidth
 
 draft-hao-rtgwg-ip-hard-pipes-02.txt
 Date: 18/12/2016
 Authors: JiangTao Hao, Soh Hock, Loa Andersson, Gang Gai
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes Protocol Independent Bandwidth for IP Multicast a.k.a "IP Multicast Hard Pipes". A hard pipe has a dedicated bandwidth that can neither be exceeded or infringed upon. RFC 7625 described an implementation of MPLS hard pipes, this document discusses the hard pipe technology as applied to IP Multicast flows.
    
draft-hao-schnorr-05.txt
 Schnorr NIZK Proof: Non-interactive Zero Knowledge Proof for Discrete Logarithm
 
 draft-hao-schnorr-05.txt
 Date: 14/11/2016
 Authors: Feng Hao
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes Schnorr NIZK proof, a non-interactive variant of the three-pass Schnorr identification scheme. The Schnorr NIZK proof allows one to prove the knowledge of a discrete logarithm without leaking any information about its value. It can serve as a useful building block for many cryptographic protocols to ensure the participants follow the protocol specification honestly. This document specifies the Schnorr NIZK proof in both the finite field and the elliptic curve settings.
    
draft-hardaker-rfc5011-security-considerations-04.txt
 Security Considerations for RFC5011 Publishers
 
 draft-hardaker-rfc5011-security-considerations-04.txt
 Date: 17/02/2017
 Authors: Wesley Hardaker, Warren Kumari
 Working Group: Domain Name System Operations (dnsop)
 Formats: xml txt
This document describes the math behind the minimum time-length that a DNS zone publisher must wait before using a new DNSKEY to sign records when supporting the RFC5011 rollover strategies.
    
draft-hardie-arc-pointers-00.txt
 Alternative Context Resolution Pointers
 
 draft-hardie-arc-pointers-00.txt
 Date: 28/10/2016
 Authors: Ted Hardie
 Working Group: Individual Submissions (none)
 Formats: txt
In RFC 2826, the IAB set out the benefits of a globally unique public name space. As alternative contexts of resolution emerge, such as those implied by RFC 7686, maintaining a single namespace for the Internet requires a method to indicate the context of resolution for a name. This document proposes a registry for such alternative resolution contexts as well as a set of pointer resource record types useful for allowing conformant resolvers which query for the name in the DNS to be redirected to the appropriate alternative resolution context.
    
draft-hardie-path-signals-00.txt
 Path signals
 
 draft-hardie-path-signals-00.txt
 Date: 28/10/2016
 Authors: Ted Hardie
 Working Group: Individual Submissions (none)
 Formats: txt
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 discusses the nature of the signals as they are seen by on-path elements and reflects on best practices for transports which encrypt their state mechanics.
    
draft-hardie-privsec-metadata-insertion-08.txt
 Design considerations for Metadata Insertion
 
 draft-hardie-privsec-metadata-insertion-08.txt
 Date: 27/03/2017
 Authors: Ted Hardie
 Working Group: Security Area (sec)
 Formats: txt
The IAB has published RFC7624 in response to several revelations of pervasive attack on Internet communications. This document considers the implications of protocol designs which associate metadata with encrypted flows. In particular, it asserts that designs which do so by explicit actions at the host are preferable to designs in which middleboxes insert them.
    
draft-hardjono-oauth-decentralized-00.txt
 Decentralized Service Architecture for OAuth2.0
 
 draft-hardjono-oauth-decentralized-00.txt
 Date: 01/02/2017
 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, 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. Each OAuth2.0 Nodes is assumed to have the capability to provide AS-services, RS-services and Client-services.
    
draft-hares-deprecate-atomic-aggregate-00.txt
 Decprecate Atomic Aggregate
 
 draft-hares-deprecate-atomic-aggregate-00.txt
 Date: 13/03/2017
 Authors: Susan Hares
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document deprecates the support for the BGP well-know discretionary attribute ATOMIC_AGGREGATE specified in RFC4271. It proposes the changes to RFC4271 to remove its support.
    
draft-hares-i2nsf-capability-data-model-01.txt
 I2NSF Capability YANG Data Model
 
 draft-hares-i2nsf-capability-data-model-01.txt
 Date: 12/03/2017
 Authors: Susan Hares, Robert Moskowitz, Liang Xia, Jaehoon Jeong, Jin-Yong Kim
 Working Group: Individual Submissions (none)
 Formats: 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 via an I2NSF security controller.
    
draft-hares-i2nsf-capability-yang-01.txt
 I2NSF Capability Yang Model
 
 draft-hares-i2nsf-capability-yang-01.txt
 Date: 05/10/2016
 Authors: Susan Hares, Robert Moskowitz, Liang Xia
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document defines a yang model that enables a I2NSF controller to control various network security functions in Network security devices.
    
draft-hares-i2rs-yang-sec-consider-00.txt
 I2RS Revision to Yang Module Security Considerations Section
 
 draft-hares-i2rs-yang-sec-consider-00.txt
 Date: 19/01/2017
 Authors: Susan Hares
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document suggests changes to the yang security considerations section for yang module draft supporting the I2RS protocol security requirements.
    
draft-hares-idr-bgp-registries-01.txt
 BGP Regisries by IDR and other BGP WGs
 
 draft-hares-idr-bgp-registries-01.txt
 Date: 13/03/2017
 Authors: Susan Hares
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
The BGP Registries at IANA were set up as one of the earliest IANA registries. Over time, the registries have become denoted as requiring "standards action", "early allocation", "FCFS (first-come, first served)", "vendor specific", and "IETF review". This draft proposes that certain BGP registries that are labelled "standards action", "early allocation", or "IETF Review" add to these registration actions a "Expert Review. It also proposes that the chairs of BGP Protocol related WG groups be part of the review team. The intent is that these chairs will be responsible for bringing questionable allocations to their workings attention. The BGP relate working groups are currently the IDR, BESS, SIDROPS, and GROW, but other working groups like SPRING might be added.
    
draft-hares-netconf-i2rs-netconf-01.txt
 NETCONF Changes to Support I2RS Protocol
 
 draft-hares-netconf-i2rs-netconf-01.txt
 Date: 12/03/2017
 Authors: Susan Hares, amit.dass@ericsson.com
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document describes a NETCONF capabiilty to support the Interface to Routing system (I2RS) protocol requirements for I2RS protocol version 1. The I2RS protocol is a re-use higher layer protocol which defines extensions to other protocols (NETCONF and RESTCONf) and extensions to the Yang Data Modeling language. The I2RS protocol supports ephemeral state datastores as control plane datastores. Initial versions of this document contain descriptions of the ephemeral datastore. Future versions may move this description to NETMOD datastore description documents.
    
draft-hares-netconf-i2rs-protocol-00.txt
 NETCONF Changes to Support I2RS Protocol
 
 draft-hares-netconf-i2rs-protocol-00.txt
 Date: 15/11/2016
 Authors: Susan Hares, amit.dass@ericsson.com
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This document describes a NETCONF capabiilty to support the Interface to Routing system (I2RS) protocol requirements for I2RS protocol version 1. The I2RS protocol is a re-use higher layer protocol which defines extensions to other protocols (NETCONF and RESTCONf) and extensions to the Yang Data Modeling language. The I2RS protocol supports ephemeral state datastores as control plane datastores. Initial versions of this document contain descriptions of the ephemeral datastore. Future versions may move this description to NETMOD datastore description documents.
    
draft-hares-netconf-i2rs-restconf-02.txt
 RESTCONF Changes to Support I2RS Protocol
 
 draft-hares-netconf-i2rs-restconf-02.txt
 Date: 29/03/2017
 Authors: Susan Hares, amit.dass@ericsson.com
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This document describes two RESTCONF optional capabilities (i2rs- control plane capability, ephemeral state capabilities) that are needed to support the I2RS protocol needs. The purpose of this draft is to kick-start the discussions with I2RS Working Group and NETCONF WG on these two capabilities.
    
draft-hares-netmod-i2rs-yang-04.txt
 Yang for I2RS Protocol
 
 draft-hares-netmod-i2rs-yang-04.txt
 Date: 11/03/2017
 Authors: Susan Hares, amit.dass@ericsson.com
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document requests yang language additions for the data models that exist as part of the I2RS control plane datastore. One of these additions is the ability to mark a portion of the model as having ephemeral state.
    
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-owe-07.txt
 Opportunistic Wireless Encryption
 
 draft-harkins-owe-07.txt
 Date: 01/02/2017
 Authors: Dan Harkins, Warren Kumari
 Working Group: Security Area (sec)
 Formats: txt
This memo specifies an extension to IEEE Std 802.11 to provide for opportunistic (unauthenticated) encryption to the wireless media. [ Ed note: Text inside square brackets ([]) is additional background information, answers to frequently asked questions, general musings, etc. They will be removed before publication. This document is being collaborated on in Github at: https://github.com/wkumari/draft- harkins-owe. The authors (gratefully) accept pull requests. ]
    
draft-harkins-pkex-03.txt
 Public Key Exchange
 
 draft-harkins-pkex-03.txt
 Date: 02/01/2017
 Authors: Dan Harkins
 Working Group: Individual Submissions (none)
 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-salted-eap-pwd-08.txt
 Adding Support for Salted Password Databases to EAP-pwd
 
 draft-harkins-salted-eap-pwd-08.txt
 Date: 23/11/2016
 Authors: Dan Harkins
 Working Group: Individual Submissions (none)
 Formats: txt
EAP-pwd is an EAP method that uses a shared password for authentication using a technique that is resistant to dictionary attack. It included support for raw keys and [RFC2759]-style double hashing of a password but did not include support for salted passwords. There are many existing databases of salted passwords and it is desirable to allow their use with EAP-pwd.
    
draft-harkins-tls-dragonfly-01.txt
 Secure Password Ciphersuites for Transport Layer Security (TLS)
 
 draft-harkins-tls-dragonfly-01.txt
 Date: 28/02/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-harris-estab-wscale-00.txt
 WSCALE options in established TCP connections
 
 draft-harris-estab-wscale-00.txt
 Date: 31/10/2016
 Authors: Jeremy Harris
 Working Group: Individual Submissions (none)
 Formats: xml txt
The TCP Window Scale option modifies the interpretation of packets in a flow but is transmitted only at the start of the connection. As such there is a problem for observability and fault-finding, since a packet capture by a third party may miss the start of a relevant connection. This document describes the use of TCP options to provide the scale values during a connection.
    
draft-hartke-core-apps-07.txt
 CoRE Application Descriptions
 
 draft-hartke-core-apps-07.txt
 Date: 12/02/2017
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The interfaces of RESTful, hypermedia-driven Web applications consist of reusable components such as Internet media types and link relation types. This document proposes CoRE Application Descriptions, a convention for application designers to describe the programmable interfaces of their applications in a structured way so that other parties can easily develop interoperable clients and servers or reuse the components in their own applications.
    
draft-hartke-core-e2e-security-reqs-02.txt
 Requirements for CoAP End-To-End Security
 
 draft-hartke-core-e2e-security-reqs-02.txt
 Date: 06/01/2017
 Authors: Goeran Selander, Francesca Palombini, Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyses threats to CoAP message exchanges traversing proxies and derives the security requirements for mitigating those threats.
    
draft-hartke-core-pending-00.txt
 The 'Pending' Response Code for the Constrained Application Protocol (CoAP)
 
 draft-hartke-core-pending-00.txt
 Date: 27/02/2017
 Authors: Peter Van der Stok, Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a new CoAP response code, 2.06 Pending. A CoAP server can use this response code to signal that it has accepted the 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. A 2.06 response can include status information and indicate a location where the result will become available.
    
draft-hartke-t2trg-cbor-forms-00.txt
 CBOR-encoded Form Data
 
 draft-hartke-t2trg-cbor-forms-00.txt
 Date: 31/10/2016
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a media type to encode form data in CBOR format.
    
draft-hartke-t2trg-coral-02.txt
 The Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-02.txt
 Date: 13/03/2017
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The Constrained RESTful Application Language (CoRAL) is a compact, binary representation format for building RESTful, hypermedia-driven applications that run in constrained environments.
    
draft-hartke-t2trg-data-hub-00.txt
 Thing-to-Thing Data Hub
 
 draft-hartke-t2trg-data-hub-00.txt
 Date: 13/11/2016
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
A Thing-to-Thing Data Hub is a RESTful, hypermedia-driven Web application that can be used in Thing-to-Thing communication to share information such as thing descriptions, configurations, resource descriptions or sleep schedules at a central location.
    
draft-haynes-sacm-ecp-02.txt
 Endpoint Compliance Profile
 
 draft-haynes-sacm-ecp-02.txt
 Date: 10/03/2017
 Authors: Daniel Haynes, Jessica Fitzgerald-McKay, Lisa Lorenzin
 Working Group: Security Automation and Continuous Monitoring (sacm)
 Formats: txt pdf xml
This document specifies the Endpoint Compliance Profile, a high-level specification that describes a specific combination and application of NEA and TNC protocols and interfaces specifically designed to support ongoing assessment of endpoint posture and the controlled exposure of collected posture information to appropriate security applications. This document is a subset of the Trusted Computing Group's Endpoint Compliance Profile Version 1.0 specification.
    
draft-hegde-isis-advertising-te-protocols-02.txt
 Advertising TE protocols in IS-IS
 
 draft-hegde-isis-advertising-te-protocols-02.txt
 Date: 13/03/2017
 Authors: Shraddha Hegde, Chris Bowers, Paul Mattes, Mohan Nanduri, Spencer Giacalone, Imtiyaz Mohammad
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document defines a mechanism to indicate which traffic engineering protocols are enabled on a link in IS-IS. It does so by introducing a new traffic-engineering protocol sub-TLV for TLV-22. This document also describes mechanisms to address backward compatibility issues for implementations that have not yet been upgraded to software that understands this new sub-TLV.
    
draft-hegde-ospf-advertising-te-protocols-00.txt
 Advertising TE protocols in OSPF
 
 draft-hegde-ospf-advertising-te-protocols-00.txt
 Date: 31/10/2016
 Authors: Shraddha Hegde, Chris Bowers
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a mechanism to indicate which traffic engineering protocols are enabled on a link in OSPF. It does so by introducing a new Traffic-Engineering Protocol sub-TLV for the Link TLV in the OSPFv2 TE Opaque LSA. This document also describes mechanisms to address backward compatibility issues for routers that have not yet been upgraded to software that understands this new sub- TLV.
    
draft-herbert-gue-extensions-01.txt
 Extensions for Generic UDP Encapsulation
 
 draft-herbert-gue-extensions-01.txt
 Date: 28/10/2016
 Authors: Tom Herbert, Lucy Yong, Fred Templin
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines a set of the fundamental optional extensions for Generic UDP Encapsulation (GUE). The extensions defined in this specification are the security option, payload transform option, checksum option, fragmentation option, and the remote checksum offload option.
    
draft-herbert-nvo3-ila-04.txt
 Identifier-locator addressing for IPv6
 
 draft-herbert-nvo3-ila-04.txt
 Date: 13/03/2017
 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-hesmans-mptcp-socket-01.txt
 A socket API to control Multipath TCP
 
 draft-hesmans-mptcp-socket-01.txt
 Date: 09/01/2017
 Authors: benjamin.hesmans@uclouvain.be, Olivier Bonaventure
 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-hinden-6man-rfc2464bis-02.txt
 Transmission of IPv6 Packets over Ethernet Networks
 
 draft-hinden-6man-rfc2464bis-02.txt
 Date: 13/03/2017
 Authors: Matt Crawford, Robert Hinden
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the frame format for transmission of IPv6 packets and the method of forming IPv6 link-local addresses and statelessly autoconfigured addresses on Ethernet networks. It also specifies the content of the Source/Target Link-layer Address option used in Router Solicitation, Router Advertisement, Neighbor Solicitation, Neighbor Advertisement and Redirect messages when those messages are transmitted on an Ethernet. This document replaces RFC 2464 "Transmission of IPv6 Packets over Ethernet Networks", which will become historic.
    
draft-hodges-webauthn-registries-00.txt
 Registries for Web Authentication (WebAuthn)
 
 draft-hodges-webauthn-registries-00.txt
 Date: 27/03/2017
 Authors: Jeff Hodges, Giridhar Mandyam, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines IANA registries for W3C Web Authentication attestation statement formats and extension identifiers.
    
draft-hoehlhubmer-https-addon-07.txt
 Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol
 
 draft-hoehlhubmer-https-addon-07.txt
 Date: 25/11/2013
 Authors: Walter Hoehlhubmer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations.
    
draft-hoehrmann-cp-collation-01.txt
 The i;codepoint collation
 
 draft-hoehrmann-cp-collation-01.txt
 Date: 14/09/2010
 Authors: Bjoern Hoehrmann
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations.
    
draft-hoffman-dns-in-json-11.txt
 Representing DNS Messages in JSON
 
 draft-hoffman-dns-in-json-11.txt
 Date: 11/03/2017
 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.
    
draft-hoffman-dns-over-http-01.txt
 DNS Queries over HTTPS
 
 draft-hoffman-dns-over-http-01.txt
 Date: 15/10/2016
 Authors: Paul Hoffman, Joe Hildebrand
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how to make DNS queries and get DNS responses over HTTPS. The main driver for this document is to allow clients who want to send DNS queries over HTTP transport to be able to do in a secure and interoperable fashion, regardless of the format of the responses. Comments on this draft can be sent to the dnsoverhttp mailing list at https://www.ietf.org/mailman/listinfo/dnsoverhttp .
    
draft-hohendorf-secure-sctp-23.txt
 Secure SCTP
 
 draft-hohendorf-secure-sctp-23.txt
 Date: 22/01/2017
 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-object-tag-01.txt
 Registration Data Access Protocol (RDAP) Object Tagging
 
 draft-hollenbeck-regext-rdap-object-tag-01.txt
 Date: 22/11/2016
 Authors: Scott Hollenbeck, Andrew Newton
 Working Group: Individual Submissions (none)
 Formats: txt
The Registration Data Access Protocol (RDAP) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries. The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries. This limitation exists because the identifiers associated with these query types are typically unstructured. This document describes an operational practice that can be used to add structure to RDAP identifiers that makes it possible to identify the authoritative server for additional RDAP queries.
    
draft-hollenbeck-regext-rdap-openid-02.txt
 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect
 
 draft-hollenbeck-regext-rdap-openid-02.txt
 Date: 02/12/2016
 Authors: Scott Hollenbeck
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-hommes-alto-blockchain-02.txt
 ALTO for the blockchain
 
 draft-hommes-alto-blockchain-02.txt
 Date: 05/01/2017
 Authors: Stefan Hommes, Beltran Fiz, R State, Anton Zuenko, Richard Caetano, Vijay Gurbani
 Working Group: Individual Submissions (none)
 Formats: txt xml
With the inception of the Bitcoin cryptocurrency, the underlying concept of the blockchain has now attracted a large number of application scenarios. Due to the decentralised nature of a typical blockchain service, a reliable communication between the different nodes is a mandatory requirement. RFC7285 describes the idea of using Application-Layer Traffic Optimization (ALTO) that is used to improve the communication in peer-to-peer networks. This document describes the benefits of using ALTO in the context of a blockchain network, and highlights the improvements for a private, consortium and public blockchain.
    
draft-honeywell-ctp-02.txt
 Cloud Tunneling Protocol (CTP)
 
 draft-honeywell-ctp-02.txt
 Date: 14/11/2016
 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-6lo-use-cases-03.txt
 IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
 
 draft-hong-6lo-use-cases-03.txt
 Date: 30/10/2016
 Authors: Yong-Geun Hong, Carles Gomez
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of IPv6 over constrained node networks (6lo) and use cases. It describes the practical deployment scenarios of 6lo technologies with the consideration of 6lo link layer technologies and identifies the requirements. 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, LTE MTC, and IEEE 802.15.4e(6tisch) are widely used at constrained node networks for typical services. Based on these link layer technologies, IPv6 over networks of resource-constrained nodes has various and practical use cases. To efficiently implement typical services, the applicability and consideration of several design space dimensions are described.
    
draft-hong-icnrg-nrs-requirements-00.txt
 Requirements for Name Resolution Service in ICN
 
 draft-hong-icnrg-nrs-requirements-00.txt
 Date: 29/09/2016
 Authors: jhong@etri.re.kr, Taewan You, Yong-Geun Hong
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the motivation and requirements for Name Resolution Service (NRS) in ICN. The NRS in ICN is to translate object names into routing hints such as locators, where names are location-independent and locators are network addresses.
    
draft-hou-6lo-plc-00.txt
 Transmission of IPv6 Packets over PLC Networks
 
 draft-hou-6lo-plc-00.txt
 Date: 12/03/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. With the inherent advantage of existing electricity infrastructure, PLC is expanding deployments all over the world, indicating 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, including current standards such as IEEE 1901.2 and ITU-T G.9903. This document describes how IPv6 packets are transported over constrained PLC networks.
    
draft-hou-roll-rpl-parent-selection-00.txt
 Optimization of Parent-node Selection in RPL-based Networks
 
 draft-hou-roll-rpl-parent-selection-00.txt
 Date: 12/03/2017
 Authors: Jianqiang Hou, JADHAV RAHUL, Zhenhui Luo
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the problems in the DODAG construction of RPL-based network including "Thundering Herd" problem and Randomly Unbalanced Networking. The corresponding optimization methods are proposed to improve balancing the selection of parent nodes.
    
draft-housley-cms-mts-hash-sig-06.txt
 Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS)
 
 draft-housley-cms-mts-hash-sig-06.txt
 Date: 02/03/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-lamps-cms-sha3-hash-00.txt
 Use of the SHA3 One-way Hash Functions in the Cryptographic Message Syntax (CMS)
 
 draft-housley-lamps-cms-sha3-hash-00.txt
 Date: 27/03/2017
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the conventions for using the four one-way hash functions in the SHA3 family with the Cryptographic Message Syntax (CMS).
    
draft-housley-rfc5280-i18n-update-00.txt
 Internationalization Updates to RFC 5280
 
 draft-housley-rfc5280-i18n-update-00.txt
 Date: 05/01/2017
 Authors: Russ Housley
 Working Group: Individual Submissions (none)
 Formats: txt
These updates to RFC 5280 provide clarity on the handling of Internationalized Domain Names (IDNs) and Internationalized Email Addresses in X.509 Certificates.
    
draft-hu-bier-oam-yang-00.txt
 YANG Data Model for BIER OAM
 
 draft-hu-bier-oam-yang-00.txt
 Date: 05/12/2016
 Authors: fangwei hu, Ran Chen, Gu Rong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines YANG data model for Bit Index Explicit Replication (BIER) Operations, Administration, and Maintenance (OAM). It extends from the basic YANG data model for Layer independent OAM Management defined in [I-D.ietf-lime-yang-connectionless-oam] with BIER technology specifics. It includes BIER OAM related configuration and state.
    
draft-hu-pce-auxiliary-connections-00.txt
 PCE auxiliary connections
 
 draft-hu-pce-auxiliary-connections-00.txt
 Date: 12/12/2016
 Authors: fangwei hu, Ran Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides a method to establish auxiliary connections between PCE and PCC to improve the reliability of the connection of PCE and PCC. The real-time sample data and some state report flow are suggestion to transport by take use of the auxiliary connection.
    
draft-huang-ace-hiding-communication-00.txt
 Subliminal Channel Hiding Communication for Constrained-Node Networks
 
 draft-huang-ace-hiding-communication-00.txt
 Date: 22/02/2017
 Authors: QingQing Huang, Min Wei, Hao Wang, ShuaiYong Li, Ping Wang, Yong Li
 Working Group: Individual Submissions (none)
 Formats: txt pdf
Due to the computation and storage limitations of constrained-node networks, it is costly to apply those security mechanisms based on public key algorithm. This document proposed a subliminal channel hiding communication method, which can provide message authentication service and protect the transmission of the sensitive data.
    
draft-huang-bmwg-virtual-network-performance-02.txt
 Benchmarking Methodology for Virtualization Network Performance
 
 draft-huang-bmwg-virtual-network-performance-02.txt
 Date: 10/03/2017
 Authors: Lu Huang, Gu Rong, Bob Mandeville, Brooks Hickman
 Working Group: Individual Submissions (none)
 Formats: xml txt
As the virtual network has been widely established in IDC, the performance of virtual network has become a valuable consideration to the IDC managers. This draft introduces a benchmarking methodology for virtualization network performance based on virtual switch.
    
draft-huang-fvn-use-cases-00.txt
 Problem Statement and Use Cases for Video Cooperation Transport
 
 draft-huang-fvn-use-cases-00.txt
 Date: 31/10/2016
 Authors: Rachel Huang, Jianjie You
 Working Group: Individual Submissions (none)
 Formats: txt
IP video traffic represents a large fraction of Internet traffic. Current infrastructures are not prepared to deal with the increasing amount of video traffic. How to transmit video traffic efficiently poses traffic management challenges to both network operators and Internet applications. This document provides use cases where network operator and Internet application can be cooperative to improve video transmission efficiency, based on the fundamental traffic characteristics (e.g. frame priority, adaptive bit rate, etc.).
    
draft-huang-nvo3-vxlan-extension-for-vbras-00.txt
 VxLAN Extension Requirement for Signaling Exchange Between Control and User Plane of vBras
 
 draft-huang-nvo3-vxlan-extension-for-vbras-00.txt
 Date: 01/03/2017
 Authors: Lu Huang, Shujun Hu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document briefly describes the architecture of control plane and user plane separated BRAS and the VxLAN extension requirement for Signaling Exchange between control plane and user plane. It also describes some possible solutions.
    
draft-hunt-idevent-distribution-01.txt
 SET Token Distribution and Subscription Management Profile
 
 draft-hunt-idevent-distribution-01.txt
 Date: 29/09/2016
 Authors: Phil Hunt, Marius Scurtescu, Morteza Ansari
 Working Group: Security Events (secevent)
 Formats: txt xml
The specification defines how a subscriber to a feed of security events (SETs) may query for, subscribe and receive SETs from a security event feed. The specification defines a single mandatory- to-implement method using HTTP Post to deliver events to registered subscribers and a registry for new methods.
    
draft-hunt-secevent-distribution-01.txt
 SET Token Delivery Using HTTP
 
 draft-hunt-secevent-distribution-01.txt
 Date: 09/03/2017
 Authors: Phil Hunt, Marius Scurtescu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification defines how a series of security event tokens (SETs) may be delivered to a previously registered receiver using HTTP over TLS. The specification defines the metadata the an Event Transmitter uses to describe the Event Receiver's HTTP endpoint and the SET token delivery configuration. The specification defines how the Event Receiver may check the current configuration metadata and delivery status using HTTP GET over TLS. The specification also defines how delivery can be assured subject to the SET Token Receiver's need for assurance.
    
draft-huque-dane-client-cert-03.txt
 TLS Client Authentication via DANE TLSA records
 
 draft-huque-dane-client-cert-03.txt
 Date: 19/02/2017
 Authors: Shumon Huque, Viktor Dukhovni
 Working Group: Individual Submissions (none)
 Formats: txt
The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish Transport Layer Security (TLS) server certificates or public keys in the DNS. This document updates RFC 6698 and RFC 7671. It describes how to additionally use the TLSA record to publish client certificates or public keys, and also the rules and considerations for using them with TLS.
    
draft-huque-tls-dane-clientid-01.txt
 TLS Extension for DANE Client Identity
 
 draft-huque-tls-dane-clientid-01.txt
 Date: 19/02/2017
 Authors: Shumon Huque, Viktor Dukhovni
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a TLS and DTLS extension to convey a DNS- Based Authentication of Named Entities (DANE) Client Identity to a TLS or DTLS server. This is useful for applications that perform TLS client authentication via DANE TLSA records.
    
draft-hutton-mmusic-opportunistic-negotiation-00.txt
 Negotiating SRTP and RTCP Feedback using the RTP/AVP Profile
 
 draft-hutton-mmusic-opportunistic-negotiation-00.txt
 Date: 23/01/2017
 Authors: Andrew Hutton, Roland Jesske, Alan Johnston, Gonzalo Salgueiro, Bernard Aboba
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document describes how the use of the Secure Real-time transport protocol (SRTP) [RFC3711]. can be negotiated using the AVP (Audio Video Profile) defined in [RFC3551]. Such a mechanism is used to provide a means for encrypted media to be used in environments where support for encryption is not known in advance, and not required. The same mechanism is also applied to negotiation of the Extended RTP Profile for Real-time Transport Control Protocol Based Feedback (RTP/ AVPF) [RFC4585].
    
draft-hy-nvo3-gue-4-nvo-04.txt
 Generic UDP Encapsulation (GUE) for Network Virtualization Overlay
 
 draft-hy-nvo3-gue-4-nvo-04.txt
 Date: 28/10/2016
 Authors: Lucy Yong, Tom Herbert, Osama Zia
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes network virtualization overlay encapsulation scheme by use of Generic UDP Encapsulation (GUE) [GUE]. It allocates one GUE optional flag and defines a 32 bit field for Virtual Network Identifier (VNID).
    
draft-hyun-i2nsf-nsf-triggered-steering-02.txt
 NSF-triggered Traffic Steering Framework
 
 draft-hyun-i2nsf-nsf-triggered-steering-02.txt
 Date: 13/03/2017
 Authors: Sangwon Hyun, Jaehoon Jeong, SangUk Woo, yunsuk@imtl.skku.ac.kr, Park Jung-Soo
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an architecture of the Interface to Network Security Functions (I2NSF) framework which enables traffic steering between Network Security Functions (NSFs) for security policy enforcement. Such traffic steering enables the composite inspection of network traffic by steering the traffic through multiple types of security functions according to the information model for the NSF- facing interface in the I2NSF framework. This document explains the additional components integrated into the I2NSF framework and their functionalities to achieve NSF-triggered traffic steering. It also describes representative use cases to address major benefits from the proposed architecture.
    
draft-hyun-i2nsf-registration-interface-dm-00.txt
 Registration Interface YANG Data Model for Interface to Network Security Functions
 
 draft-hyun-i2nsf-registration-interface-dm-00.txt
 Date: 13/03/2017
 Authors: Sangwon Hyun, Jaehoon Jeong, yunsuk@imtl.skku.ac.kr, SangUk Woo, Susan Hares
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG data model for the Registration Interface between Security Controller and Developer's Management System in the Interface to Network Security Functions (I2NSF) framework. The data model is required for the instance registration of Network Security Functions (NSFs) and the dynamic life cycle management of NSF instances.
    
draft-hyun-i2nsf-registration-interface-im-01.txt
 Registration Interface Information Model for Interface to Network Security Functions
 
 draft-hyun-i2nsf-registration-interface-im-01.txt
 Date: 13/03/2017
 Authors: Sangwon Hyun, Jaehoon Jeong, SangUk Woo, yunsuk@imtl.skku.ac.kr, Park Jung-Soo
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an information model for Interface to Network Security Functions (I2NSF) Registration Interface between Security Controller and Developer's Management System. The information model is required for Network Security Function (NSF) instance registration and the dynamic life cycle management of NSF instances. 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-hyun-i2nsf-sfc-enabled-i2nsf-01.txt
 Service Function Chaining-Enabled I2NSF Architecture
 
 draft-hyun-i2nsf-sfc-enabled-i2nsf-01.txt
 Date: 05/10/2016
 Authors: Sangwon Hyun, SangUk Woo, yunsuk@imtl.skku.ac.kr, Jaehoon Jeong, Park Jung-Soo
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an architecture of the I2NSF framework which enables traffic steering between NSFs for security policy enforcement. Such traffic steering enables composite inspection of network traffic by steering the traffic through multiple types of security functions according to the information model for the NSF facing interface in the I2NSF framework. This document explains the additional components integrated into the I2NSF framework and their functionalities to achieve NSF-triggered traffic steering. It also describes representative use cases to address major benefits from the proposed architecture.
    
draft-iab-iotsi-workshop-01.txt
 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
 
 draft-iab-iotsi-workshop-01.txt
 Date: 14/11/2016
 Authors: Jaime Jimenez, Hannes Tschofenig, Dave Thaler
 Working Group: Internet Architecture Board (iab)
 Formats: txt
This document provides a summary of the 'Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)' [IOTSIAG], [IOTSIWS], which took place in Santa Clara, CA, on March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and standards developing organizations to accomplish interoperability at the application layer. This report summarizes the discussions and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors and the Internet Architecture Board (IAB), which organized the workshop.
    
draft-iab-iotsu-workshop-01.txt
 Report from the Internet of Things (IoT) Software Update (IoTSU) Workshop 2016
 
 draft-iab-iotsu-workshop-01.txt
 Date: 03/02/2017
 Authors: Hannes Tschofenig, Stephen Farrell
 Working Group: Internet Architecture Board (iab)
 Formats: txt xml
This document provides a summary of the 'Workshop on Internet of Things (IoT) Software Update (IOTSU)' which took place at Trinity College Dublin, Ireland on the 13th and 14th of June, 2016. The main goal of the workshop was to foster a discussion on requirements, challenges and solutions for bringing software and firmware updates to IoT devices. This report summarizes the discussions and lists recommendations to the standards community.
    
draft-iab-privsec-confidentiality-mitigations-08.txt
 Confidentiality in the Face of Pervasive Surveillance
 
 draft-iab-privsec-confidentiality-mitigations-08.txt
 Date: 27/10/2016
 Authors: Ted Hardie
 Working Group: Internet Architecture Board (iab)
 Formats: txt
The IAB has published [RFC7624] in response to several revelations of pervasive attack on Internet communications. This document surveys the most plausible mitigations to those threats currently available to the designers of Internet protocols.
    
draft-iab-protocol-transitions-08.txt
 Planning for Protocol Adoption and Subsequent Transitions
 
 draft-iab-protocol-transitions-08.txt
 Date: 08/03/2017
 Authors: Dave Thaler
 Working Group: Internet Architecture Board (iab)
 Formats: txt
Over the many years since the introduction of the Internet Protocol, we have seen a number of transitions throughout the protocol stack, such as deploying a new protocol, or updating or replacing an existing protocol. Many protocols and technologies were not designed to enable smooth transition to alternatives or to easily deploy extensions, and thus some transitions, such as the introduction of IPv6, have been difficult. This document attempts to summarize some basic principles to enable future transitions, and also summarizes what makes for a good transition plan.
    
draft-iab-rfc-preservation-04.txt
 Digital Preservation Considerations for the RFC Series
 
 draft-iab-rfc-preservation-04.txt
 Date: 28/02/2017
 Authors: Heather Flanagan
 Working Group: Internet Architecture Board (iab)
 Formats: txt xml
The RFC Editor is both the publisher and the archivist for the RFC Series. This document applies specifically to the archivist role of the RFC Editor. It provides guidance on when and how to preserve RFCs, and the tools required to view or re-create RFCs as necessary. This document also highlights where gaps are in the current process, and where compromises are suggested to balance cost with ideal best practice.
    
draft-iab-web-pki-problems-05.txt
 Improving the Public Key Infrastructure (PKI) for the World Wide Web
 
 draft-iab-web-pki-problems-05.txt
 Date: 31/10/2016
 Authors: Russ Housley, Karen O'Donoghue
 Working Group: Internet Architecture Board (iab)
 Formats: xml txt
The Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI) is a vital component of trust in the Internet. In recent years, there have been a number of improvements made to this infrastructure, including improved certificate status checking, automation, and transparency of governance. However, additional improvements are necessary. This document identifies continuing areas of concern and provides recommendations to the Internet community for additional improvements, moving toward a more robust and secure Web PKI.
    
draft-idr-bgp-route-refresh-options-02.txt
 Extension to BGP's Route Refresh Message
 
 draft-idr-bgp-route-refresh-options-02.txt
 Date: 06/03/2017
 Authors: Keyur Patel, Aamod Vyavaharkar, Niloofar Fazlollahi, Tony Przygienda
 Working Group: Individual Submissions (none)
 Formats: txt xml
[RFC2918] defines a route refresh capability to be exchanged between BGP speakers. BGP speakers that support this capability are advertising that they can resend the entire BGP Adj-RIB-Out on receipt of a refresh request. By supporting this capability, BGP speakers are more flexible in applying any inbound routing policy changes as they no longer have to store received routes in their unchanged form or reset the session when an inbound routing policy change occurs. The route refresh capability is advertised per AFI, SAFI combination. There are newer AFI, SAFI types that have been introduced to BGP that support a variety of route types (e.g. IPv4/MVPN, L2VPN/EVPN). Currently, there is no way to request a subset of routes in a Route Refresh message for a given AFI, SAFI. This draft defines route refresh capability extensions that help BGP speakers to request a subset of routes for a given address family. This is expected to reduce the amount of update traffic being generated by route refresh requests as well as lessen the burden on the router servicing such requests.
    
draft-idr-bgp-rt-oscillation-01.txt
 Persistent Route Oscillation in BGP Constrained Route Distribution
 
 draft-idr-bgp-rt-oscillation-01.txt
 Date: 13/03/2017
 Authors: Dongling Duan, Jakob Heitz, Keyur Patel, Jeffrey Haas
 Working Group: Individual Submissions (none)
 Formats: txt xml
RFC4684 defines Multi-Protocol BGP (MP-BGP) procedures that allow BGP speakers to exchange Route Target reachability information (RT- Constrain) to restrict the propagation of Virtual Private Network (VPN) routes. In network scenarios where hierarchical route reflection (RR) is used, the existing RT-Constrain mechanism may result in persistent route oscillations within RRs. This document describes the problem and proposes a solution.
    
draft-ietf-6lo-6lobac-08.txt
 Transmission of IPv6 over MS/TP Networks
 
 draft-ietf-6lo-6lobac-08.txt
 Date: 13/03/2017
 Authors: Kerry Lynn, Jerry Martocci, Carl Neilson, Stuart Donaldson
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt
Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer and is used primarily in building automation networks. This specification defines the frame format for transmission of IPv6 packets and the method of forming link-local and statelessly autoconfigured IPv6 addresses on MS/TP networks.
    
draft-ietf-6lo-ap-nd-00.txt
 Address Protected Neighbor Discovery for Low-power and Lossy Networks
 
 draft-ietf-6lo-ap-nd-00.txt
 Date: 13/11/2016
 Authors: Behcet Sarikaya, Pascal Thubert, Mohit Sethi
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This document defines an extension to 6LoWPAN Neighbor Discovery. This extension is designed for low-power and lossy network environments and it supports multi-hop operation. Nodes supporting this extension compute a Cryptographically Unique Interface ID and associate it with one or more of their Registered Addresses. The Cryptographic ID (Crypto-ID) uniquely identifies the owner of the Registered Address. It is used in place of the EUI-64 address that is specified in RFC 6775. Once an address is registered with a Cryptographic ID, only the owner of that ID can modify the state information of the Registered Address in the 6LR and 6LBR.
    
draft-ietf-6lo-backbone-router-03.txt
 IPv6 Backbone Router
 
 draft-ietf-6lo-backbone-router-03.txt
 Date: 11/01/2017
 Authors: Pascal Thubert
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This specification proposes an update to IPv6 Neighbor Discovery, to enhance the operation of IPv6 over wireless links that exhibit lossy multicast support, and enable a large degree of scalability by splitting the broadcast domains. A higher speed backbone federates multiple wireless links to form a large MultiLink Subnet. Backbone Routers acting as Layer-3 Access Point route packets to registered nodes, where an classical Layer-2 Access Point would bridge. Conversely, wireless nodes register or are proxy-registered to the Backbone Router to setup routing services in a fashion that is essentially similar to a classical Layer-2 association.
    
draft-ietf-6lo-blemesh-01.txt
 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
 
 draft-ietf-6lo-blemesh-01.txt
 Date: 11/03/2017
 Authors: Carles Gomez, Seyed Darroudi, Teemu Savolainen
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable IPv6 over Bluetooth low energy networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies the mechanisms needed to enable IPv6 over mesh networks composed of Bluetooth low energy links established by using the Bluetooth Internet Protocol Support Profile.
    
draft-ietf-6lo-dect-ule-09.txt
 Transmission of IPv6 Packets over DECT Ultra Low Energy
 
 draft-ietf-6lo-dect-ule-09.txt
 Date: 15/12/2016
 Authors: Peter Mariager, Jens Petersen, Zach Shelby, Marco van de Logt, Dominique Barthel
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt pdf xml
Digital Enhanced Cordless Telecommunications (DECT) Ultra Low Energy (ULE) is a low power air interface technology that is defined by the DECT Forum and specified by ETSI. The DECT air interface technology has been used world-wide in communication devices for more than 20 years, primarily carrying voice for cordless telephony but has also been deployed for data centric services. The DECT Ultra Low Energy is a recent addition to the DECT interface primarily intended for low-bandwidth, low-power applications such as sensor devices, smart meters, home automation etc. As the DECT Ultra Low Energy interface inherits many of the capabilities from DECT, it benefits from long range, interference free operation, world wide reserved frequency band, low silicon prices and maturity. There is an added value in the ability to communicate with IPv6 over DECT ULE such as for Internet of Things applications. This document describes how IPv6 is transported over DECT ULE using 6LoWPAN techniques.
    
draft-ietf-6lo-nfc-06.txt
 Transmission of IPv6 Packets over Near Field Communication
 
 draft-ietf-6lo-nfc-06.txt
 Date: 07/03/2017
 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-01.txt
 An Update to 6LoWPAN ND
 
 draft-ietf-6lo-rfc6775-update-01.txt
 Date: 11/01/2017
 Authors: Pascal Thubert, Erik Nordmark, Samita Chakrabarti
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This specification updates 6LoWPAN Neighbor Discovery (RFC6775), to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, and provide enhancements to the registration capabilities, in particular for the registration to a backbone router for proxy ND operations.
    
draft-ietf-6lo-use-cases-01.txt
 IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
 
 draft-ietf-6lo-use-cases-01.txt
 Date: 13/03/2017
 Authors: Yong-Geun Hong, Carles Gomez, Abdur Sangi, Take Aanstoot
 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 use cases. It describes the practical deployment scenarios of 6lo technologies with the consideration of 6lo link layer technologies and identifies the requirements. 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, LTE MTC, PLC (IEEE 1901), and IEEE 802.15.4e(6tisch) are widely used at constrained node networks for typical services. Based on these link layer technologies, IPv6 over networks of resource-constrained nodes has various and practical use cases. To efficiently implement typical services, the applicability and consideration of several design space dimensions are described.
    
draft-ietf-6man-ipv6-mibs-obsolete-02.txt
 Republishing the IPV6-specific MIB modules as obsolete
 
 draft-ietf-6man-ipv6-mibs-obsolete-02.txt
 Date: 13/11/2016
 Authors: Bill Fenner
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
In 2005, the IPv6 MIB update group published updated versions of the IP-MIB, UDP-MIB, TCP-MIB and IP-FORWARD-MIB modules, which use the InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the same table. This document contains versions of the obsoleted IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB and IPV6-UDP-MIB modules, for the purpose of updating MIB module repositories.
    
draft-ietf-6man-maxra-02.txt
 Support for adjustable maximum router lifetimes per-link
 
 draft-ietf-6man-maxra-02.txt
 Date: 09/03/2017
 Authors: Suresh Krishnan, Jouni Korhonen, Samita Chakrabarti, Erik Nordmark, Andrew Yourtchenko
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
The neighbor discovery protocol specifies the maximum time allowed between sending unsolicited multicast Router Advertisements from a router interface as well as the maximum router lifetime. It also allows the limits to be overridden by link-layer specific documents. This document allows for overriding these values on a per-link basis.
    
draft-ietf-6man-rfc1981bis-04.txt
 Path MTU Discovery for IP version 6
 
 draft-ietf-6man-rfc1981bis-04.txt
 Date: 31/01/2017
 Authors: Jack <>, Stephen <>, Jeffrey <>, Robert Hinden
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
This document describes Path MTU Discovery for IP version 6. It is largely derived from RFC 1191, which describes Path MTU Discovery for IP version 4. It obsoletes RFC1981.
    
draft-ietf-6man-rfc2460bis-08.txt
 Internet Protocol,Version 6 (IPv6) Specification
 
 draft-ietf-6man-rfc2460bis-08.txt
 Date: 15/11/2016
 Authors: Steve Deering, Robert Hinden
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC2460
    
draft-ietf-6man-rfc4291bis-07.txt
 IP Version 6 Addressing Architecture
 
 draft-ietf-6man-rfc4291bis-07.txt
 Date: 31/01/2017
 Authors: Robert Hinden, Stephen <>
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
This specification defines the addressing architecture of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressing model, text representations of IPv6 addresses, definition of IPv6 unicast addresses, anycast addresses, and multicast addresses, and an IPv6 node's required addresses. This document obsoletes RFC 4291, "IP Version 6 Addressing Architecture".
    
draft-ietf-6man-rs-refresh-02.txt
 IPv6 Neighbor Discovery Optional RS/RA Refresh
 
 draft-ietf-6man-rs-refresh-02.txt
 Date: 31/10/2016
 Authors: Erik Nordmark, Andrew Yourtchenko, Suresh Krishnan
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
IPv6 Neighbor Discovery relies on periodic multicast Router Advertisement messages to update timer values and to distribute new information (such as new prefixes) to hosts. On some links the use of periodic multicast messages to all host becomes expensive, and in some cases it results in hosts waking up frequently. Many implementations of RFC 4861 also use multicast for solicited Router Advertisement messages, even though that behavior is optional. This specification provides an optional mechanism for hosts and routers where instead of periodic multicast Router Advertisements the hosts are instructed (by the routers) to use Router Solicitations to request refreshed Router Advertisements. This mechanism is enabled by configuring the router to include a new option in the Router Advertisement in order to allow the network administrator to choose host behavior based on whether periodic multicast are more efficient on their link or not. The routers can also tell whether the hosts are capable of the new behavior through a new flag in the Router Solicitations.
    
draft-ietf-6man-segment-routing-header-06.txt
 IPv6 Segment Routing Header (SRH)
 
 draft-ietf-6man-segment-routing-header-06.txt
 Date: 13/03/2017
 Authors: Stefano Previdi, Clarence Filsfils, Kamran Raza, John Leddy, Brian Field, daniel.voyer@bell.ca, daniel.bernier@bell.ca, Satoru Matsushima, Ida Leung, J. Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk Steinberg, Robert Raszuk
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
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 to enforce 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 draft describes the Segment Routing Extension Header Type and how it is used by SR capable nodes.
    
draft-ietf-6tisch-6top-protocol-04.txt
 6top Protocol (6P)
 
 draft-ietf-6tisch-6top-protocol-04.txt
 Date: 29/03/2017
 Authors: Qin Wang, Xavier Vilajosana, Thomas Watteyne
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This document defines the 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 Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. Several SFs can be defined, each identified by a different 6top Scheduling Function Identifier (SFID). This document lists the requirements for an SF, but leaves the definition of the SF out of scope. Different SFs are expected to be defined in future companion specifications.
    
draft-ietf-6tisch-6top-sf0-03.txt
 6TiSCH 6top Scheduling Function Zero (SF0)
 
 draft-ietf-6tisch-6top-sf0-03.txt
 Date: 13/03/2017
 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 "Scheduling Function Zero" (SF0). SF0 dynamically adapts the number of allocated 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. SF0 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-11.txt
 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4
 
 draft-ietf-6tisch-architecture-11.txt
 Date: 27/01/2017
 Authors: Pascal Thubert
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This document describes a network architecture that provides low- latency, low-jitter and high-reliability packet delivery. It combines a high speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of LowPower wireless deterministic applications.
    
draft-ietf-6tisch-dtsecurity-secure-join-01.txt
 6tisch Secure Join protocol
 
 draft-ietf-6tisch-dtsecurity-secure-join-01.txt
 Date: 25/02/2017
 Authors: Michael Richardson
 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-21.txt
 Minimal 6TiSCH Configuration
 
 draft-ietf-6tisch-minimal-21.txt
 Date: 20/02/2017
 Authors: Xavier Vilajosana, Kris Pister, Thomas Watteyne
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This document describes a minimal mode of operation for an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Network. This minimal mode of operation specifies the baseline set of protocols that need to be supported, recommended configurations and modes of operation sufficient to enable a 6TiSCH functional network. 6TiSCH provides IPv6 connectivity over a Time Synchronized Channel Hopping (TSCH) mesh composed of IEEE Std 802.15.4 TSCH links. This minimal mode uses a collection of protocols with the respective configurations, including the 6LoWPAN framework, enabling interoperable IPv6 connectivity over IEEE Std 802.15.4 TSCH. This minimal configuration provides the necessary bandwidth for network and security bootstrap, and defines the proper link between the IETF protocols that interface to IEEE Std 802.15.4 TSCH. This minimal mode of operation should be implemented by all 6TiSCH compliant devices.
    
draft-ietf-6tisch-minimal-security-02.txt
 Minimal Security Framework for 6TiSCH
 
 draft-ietf-6tisch-minimal-security-02.txt
 Date: 12/03/2017
 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 mechanisms required to support secure enrollment of a pledge, a device being added to an IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) network. It assumes that the pledge has been provisioned with a credential that is relevant to the deployment - the "one-touch" scenario. The goal of this configuration is to set link-layer keys, and to establish a secure end-to-end session between each pledge and the join registrar who may use that to further configure the pledge. Additional security behaviors and mechanisms may be added on top of this minimal framework.
    
draft-ietf-6tisch-terminology-08.txt
 Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e
 
 draft-ietf-6tisch-terminology-08.txt
 Date: 16/12/2016
 Authors: Maria Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
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-05.txt
 An architecture for authorization in constrained environments
 
 draft-ietf-ace-actors-05.txt
 Date: 06/03/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-03.txt
 CBOR Web Token (CWT)
 
 draft-ietf-ace-cbor-web-token-03.txt
 Date: 02/03/2017
 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. CWT is a profile of the JSON Web Token (JWT) that is optimized for constrained devices. 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.
    
draft-ietf-ace-oauth-authz-06.txt
 Authentication and Authorization for Constrained Environments (ACE)
 
 draft-ietf-ace-oauth-authz-06.txt
 Date: 13/03/2017
 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. 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-acme-acme-06.txt
 Automatic Certificate Management Environment (ACME)
 
 draft-ietf-acme-acme-06.txt
 Date: 13/03/2017
 Authors: Richard Barnes, Jacob Hoffman-Andrews, James Kasten
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
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.
    
draft-ietf-acme-caa-01.txt
 CAA Record Extensions for Account URI and ACME Method Binding
 
 draft-ietf-acme-caa-01.txt
 Date: 04/02/2017
 Authors: Hugo Landau
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
The CAA DNS record allows a domain to communicate issuance policy to CAs, but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be required.
    
draft-ietf-alto-cost-calendar-01.txt
 ALTO Cost Calendar
 
 draft-ietf-alto-cost-calendar-01.txt
 Date: 13/02/2017
 Authors: Sabine Randriamasy, Yang Yang, Wenson 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 costs enabling an ALTO Server to provide "Cost Calendars". These capabilities are applicable to time-sensitive ALTO metrics. 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-04.txt
 ALTO Incremental Updates Using Server-Sent Events (SSE)
 
 draft-ietf-alto-incr-update-sse-04.txt
 Date: 12/03/2017
 Authors: Wendy Roome, Y. Yang
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: xml txt
The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information to client applications so that clients may make informed decisions. To that end, an ALTO Server provides Network and Cost Maps. Using those maps, an ALTO Client can determine the costs between endpoints. However, the ALTO protocol does not define a mechanism to allow an ALTO client to obtain updates to those maps, other than by periodically re-fetching them. Because the maps may be large (potentially tens of megabytes), and because only parts of the maps may change frequently (especially Cost Maps), that can be extremely inefficient. Therefore this document presents a mechanism to allow an ALTO Server to provide updates to ALTO Clients. Updates can be both immediate, in that the server can send updates as soon as they are available, and incremental, in that if only a small section of a map changes, the server can send just the changes.
    
draft-ietf-alto-multi-cost-07.txt
 Multi-Cost ALTO
 
 draft-ietf-alto-multi-cost-07.txt
 Date: 10/03/2017
 Authors: Sabine Randriamasy, Wendy Roome, Nico Schwan
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The ALTO (Application Layer-Traffic Optimization) Protocol ([RFC7285]) defines several services that return various metrics describing the costs between network endpoints. An ALTO Server may offer a variety of cost metrics, based on latency,bandwidth, hop count, jitter, or whatever else the ALTO Server deems useful. For example, when downloading a file that is mirrored on several sites, a user application may consider more than one metric, perhaps trading bandwidth for latency to determine the most efficient mirror site. While the base ALTO Protocol allows an ALTO Client to use more than one cost metric, to do so, the Client must request each metric separately. This document defines a new service that allows a Client to retrieve several cost metrics with one request, which is considerably more efficient. In addition, this document extends the ALTO constraint tests to allow a user to specify an arbitrary logical combination of tests on several cost metrics.
    
draft-ietf-alto-performance-metrics-01.txt
 ALTO Performance Cost Metrics
 
 draft-ietf-alto-performance-metrics-01.txt
 Date: 03/03/2017
 Authors: Qin Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: xml txt
Cost Metric is a basic concept in Application-Layer Traffic Optimization (ALTO). It is used in both the Cost Map Service and the Endpoint Cost Service. Different applications may benefit from different Cost Metrics. For example, a Resource Consumer may prefer Resource Providers that offers 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-anima-autonomic-control-plane-06.txt
 An Autonomic Control Plane
 
 draft-ietf-anima-autonomic-control-plane-06.txt
 Date: 27/03/2017
 Authors: Michael Behringer, Toerless Eckert, Steinthor Bjarnason
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines an "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 communications over a network that is not configured, or mis-configured.
    
draft-ietf-anima-bootstrapping-keyinfra-05.txt
 Bootstrapping Remote Secure Key Infrastructures (BRSKI)
 
 draft-ietf-anima-bootstrapping-keyinfra-05.txt
 Date: 13/03/2017
 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 vendor installed X.509 certificate, in combination with a vendor's authorizing service, both online the Internet, 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-10.txt
 A Generic Autonomic Signaling Protocol (GRASP)
 
 draft-ietf-anima-grasp-10.txt
 Date: 09/03/2017
 Authors: Carsten Bormann, Brian Carpenter, Bing Liu
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
This document establishes requirements for a signaling protocol that enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings with them. The document then defines a general protocol for discovery, synchronization and negotiation, while the technical objectives for specific scenarios are to be described in separate documents. An Appendix briefly discusses existing protocols with comparable features.
    
draft-ietf-anima-prefix-management-03.txt
 Autonomic IPv6 Edge Prefix Management in Large-scale Networks
 
 draft-ietf-anima-prefix-management-03.txt
 Date: 09/03/2017
 Authors: Sheng Jiang, Zongpeng Du, Brian Carpenter, Qiong Sun
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
This document describes an autonomic solution for IPv6 prefix management at the edge of large-scale ISP networks. 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-03.txt
 A Reference Model for Autonomic Networking
 
 draft-ietf-anima-reference-model-03.txt
 Date: 13/03/2017
 Authors: Michael Behringer, Brian Carpenter, Toerless Eckert, Laurent Ciavaglia, Peloso Pierre, Bing Liu, Jeferson Nobre, John Strassner
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
This document describes a reference model for Autonomic Networking. The goal is to define how the various elements in an autonomic context work 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-ietf-anima-stable-connectivity-02.txt
 Using Autonomic Control Plane for Stable Connectivity of Network OAM
 
 draft-ietf-anima-stable-connectivity-02.txt
 Date: 07/02/2017
 Authors: Toerless Eckert, Michael Behringer
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
OAM (Operations, Administration and Management) processes for data networks are often subject to the problem of circular dependencies when relying on network connectivity of the network to be managed for the OAM operations itself. Provisioning during device/network bring up tends to be far less easy to automate than service provisioning later on, changes in core network functions impacting reachability can not be automated either 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 the autonomic control plane (ACP) in Autonomic Networks (AN). to provide stable and secure connectivity for those OAM processes.
    
draft-ietf-anima-voucher-02.txt
 Voucher Profile for Bootstrapping Protocols
 
 draft-ietf-anima-voucher-02.txt
 Date: 15/03/2017
 Authors: Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". The voucher artifact is a YANG-defined JSON document that has been signed using a PKCS#7 structure. The voucher artifact is generated by the pledge's manufacture or delegate (i.e. the MASA). This document only defines the voucher artifact, leaving it to other documents to describe specialized protocols for accessing it.
    
draft-ietf-aqm-codel-07.txt
 Controlled Delay Active Queue Management
 
 draft-ietf-aqm-codel-07.txt
 Date: 12/03/2017
 Authors: Kathleen Nichols, Van Jacobson, Andrew McGregor, Janardhan Iyengar
 Working Group: Active Queue Management and Packet Scheduling (aqm)
 Formats: txt xml
This document describes a general framework called CoDel (Controlled Delay) that controls bufferbloat-generated excess delay in modern networking environments. CoDel consists of an estimator, a setpoint, and a control loop. It requires no configuration in normal Internet deployments.
    
draft-ietf-aqm-fq-codel-06.txt
 The FlowQueue-CoDel Packet Scheduler and Active Queue Management Algorithm
 
 draft-ietf-aqm-fq-codel-06.txt
 Date: 18/03/2016
 Authors: Toke Hoeiland-Joergensen, Paul McKenney, dave.taht@gmail.com, Jim Gettys, Eric Dumazet
 Working Group: Active Queue Management and Packet Scheduling (aqm)
 Formats: xml txt
This memo presents the FQ-CoDel hybrid packet scheduler/Active Queue Management algorithm, a powerful tool for fighting bufferbloat and reducing latency. FQ-CoDel mixes packets from multiple flows and reduces the impact of head of line blocking from bursty traffic. It provides isolation for low-rate traffic such as DNS, web, and videoconferencing traffic. It improves utilisation across the networking fabric, especially for bidirectional traffic, by keeping queue lengths short; and it can be implemented in a memory- and CPU-efficient fashion across a wide range of hardware.
    
draft-ietf-avtcore-aria-sdes-02.txt
 The Addition of SRTP crypto suites based on the ARIA algorithms to the SDP Security Descriptions
 
 draft-ietf-avtcore-aria-sdes-02.txt
 Date: 13/11/2016
 Authors: Woo-Hwan Kim, Jungkeun Lee, Je Park, Daesung Kwon, Dong-Chan Kim
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt pdf
This document defines SRTP crypto suites based on the ARIA block cipher algorithm for use with the Session Description Protocol (SDP) security descriptions.
    
draft-ietf-avtcore-aria-srtp-09.txt
 The ARIA Algorithm and Its Use with the Secure Real-time Transport Protocol(SRTP)
 
 draft-ietf-avtcore-aria-srtp-09.txt
 Date: 25/11/2015
 Authors: Woo-Hwan Kim, Jungkeun Lee, Je-Hong Park, Daesung Kwon
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt
This document defines the use of the ARIA block cipher algorithm within the Secure Real-time Transport Protocol (SRTP). It details two modes of operation (CTR, GCM) and a SRTP Key Derivation Function for ARIA. Additionally, this document defines DTLS-SRTP protection profiles and MIKEY parameter sets for the use with ARIA.
    
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-rfc5285-bis-08.txt
 A General Mechanism for RTP Header Extensions
 
 draft-ietf-avtcore-rfc5285-bis-08.txt
 Date: 27/02/2017
 Authors: Roni Even, David Singer, HariKishan Desineni
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt pdf
This document provides a general mechanism to use the header extension feature of RTP (the Real-Time Transport Protocol). It provides the option to use a small number of small extensions in each RTP packet, where the universe of possible extensions is large and registration is de-centralized. The actual extensions in use in a session are signaled in the setup information for that session. This document obsoletes RFC5285.
    
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-04.txt
 Frame Marking RTP Header Extension
 
 draft-ietf-avtext-framemarking-04.txt
 Date: 13/03/2017
 Authors: Espen Berger, Suhas Nandakumar, Mo Zanaty
 Working Group: Audio/Video Transport Extensions (avtext)
 Formats: xml txt
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-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-avtext-splicing-notification-09.txt
 RTP/RTCP extension for RTP Splicing Notification
 
 draft-ietf-avtext-splicing-notification-09.txt
 Date: 03/08/2016
 Authors: Jinwei Xia, Roni Even, Rachel Huang, Deng Lingli
 Working Group: Audio/Video Transport Extensions (avtext)
 Formats: txt
Content splicing is a process that replaces the content of a main multimedia stream with other multimedia content, and delivers the substitutive multimedia content to the receivers for a period of time. The splicer is designed to handle RTP splicing and needs to know when to start and end the splicing. This memo defines two RTP/RTCP extensions to indicate the splicing related information to the splicer: an RTP header extension that conveys the information in-band and an RTCP packet that conveys the information out-of-band.
    
draft-ietf-babel-applicability-01.txt
 Applicability of the Babel routing protocol
 
 draft-ietf-babel-applicability-01.txt
 Date: 05/01/2017
 Authors: Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
This document describes some application areas where the Babel routing protocol (RFC 6126) has been found to be useful.
    
draft-ietf-babel-rfc6126bis-01.txt
 The Babel Routing Protocol
 
 draft-ietf-babel-rfc6126bis-01.txt
 Date: 31/01/2017
 Authors: Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks.
    
draft-ietf-behave-ipfix-nat-logging-13.txt
 IPFIX Information Elements for logging NAT Events
 
 draft-ietf-behave-ipfix-nat-logging-13.txt
 Date: 09/01/2017
 Authors: Senthil Sivakumar, Reinaldo Penno
 Working Group: Individual Submissions (none)
 Formats: xml txt
Network operators require NAT devices to log events like creation and deletion of translations and information about the resources that the NAT device is managing. The logs are essential in many cases to identify an attacker or a host that was used to launch malicious attacks and for various other purposes of accounting. Since there is no standard way of logging this information, different NAT devices log the information using proprietary formats and hence it is difficult to expect a consistent behavior. The lack of a consistent way to log the data makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the formats for logging of NAT events.
    
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-02.txt
 Updated processing of control flags for BGP VPLS
 
 draft-ietf-bess-bgp-vpls-control-flags-02.txt
 Date: 09/01/2017
 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-evpn-ac-df-00.txt
 AC-Influenced Designated Forwarder Election for EVPN
 
 draft-ietf-bess-evpn-ac-df-00.txt
 Date: 11/10/2016
 Authors: Jorge Rabadan, Kiran Nagaraj, Senthil Sathappan, Vinod Prabhu, Wim Henderickx, Autumn Liu, Wen Lin
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The Designated Forwarder (DF) in EVPN networks is the PE responsible for sending multicast, broadcast and unknown unicast traffic to a multi-homed CE, on a given Ethernet Tag on a particular Ethernet Segment (ES). The DF is selected based on the list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network. While PE node or link failures trigger the DF re-election for a given , individual Attachment Circuit (AC) or MAC-VRF failures do not trigger such DF re-election and the traffic may therefore be permanently impacted, even though there is an alternative path. This document improves the DF election algorithm so that the AC status can influence the result of the election and this type of "logical" failures can be protected too.
    
draft-ietf-bess-evpn-bum-procedure-updates-01.txt
 Updates on EVPN BUM Procedures
 
 draft-ietf-bess-evpn-bum-procedure-updates-01.txt
 Date: 14/12/2016
 Authors: Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel
 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-01.txt
 A new Designated Forwarder Election for the EVPN
 
 draft-ietf-bess-evpn-df-election-01.txt
 Date: 07/10/2016
 Authors: satyamoh@cisco.com, Keyur Patel, Ali Sajassi, John Drake, Tony Przygienda
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes an improved EVPN Designated Forwarder Election (DF) algorithm which can be used to enhance operational experience in terms of convergence speed and robustness over a WAN deploying EVPN
    
draft-ietf-bess-evpn-etree-09.txt
 E-TREE Support in EVPN & PBB-EVPN
 
 draft-ietf-bess-evpn-etree-09.txt
 Date: 13/01/2017
 Authors: Ali Sajassi, Samer Salam, John Drake, Jim Uttaro, Sami Boutros, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The Metro Ethernet Forum (MEF) has defined a rooted-multipoint Ethernet service known as Ethernet Tree (E-Tree). A solution framework for supporting this service in MPLS networks is proposed in and RFC called "A Framework for E-Tree Service over MPLS Network". This document discusses how those functional requirements can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more efficient implementation of these functions. This document makes use of the most significant bit of the scope governed by the IANA registry created by RFC7385, and hence updates that RFC accordingly.
    
draft-ietf-bess-evpn-igmp-mld-proxy-00.txt
 IGMP and MLD Proxy for EVPN
 
 draft-ietf-bess-evpn-igmp-mld-proxy-00.txt
 Date: 27/03/2017
 Authors: Ali Sajassi, Samir Thoria, Keyur Patel, Derek Yeung, John Drake, Wen Lin
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Ethernet Virtual Private Network (EVPN) solution [RFC 7432] is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services, and in service provider (SP) applications for next generation virtual private LAN services. This draft describes how to support efficiently endpoints running IGMP for the above services over an EVPN network by incorporating IGMP proxy procedures on EVPN PEs.
    
draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt
 Integrated Routing and Bridging in EVPN
 
 draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt
 Date: 10/02/2017
 Authors: Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan, Lucy Yong
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
EVPN provides an extensible and flexible multi-homing VPN solution for intra-subnet connectivity among hosts/VMs over an MPLS/IP network. However, there are scenarios in which inter-subnet forwarding among hosts/VMs across different IP subnets is required, while maintaining the multi-homing capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements.
    
draft-ietf-bess-evpn-optimized-ir-01.txt
 Optimized Ingress Replication solution for EVPN
 
 draft-ietf-bess-evpn-optimized-ir-01.txt
 Date: 15/02/2017
 Authors: Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Ali Sajassi, Aldrin Isaac
 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-overlay-08.txt
 A Network Virtualization Overlay Solution using EVPN
 
 draft-ietf-bess-evpn-overlay-08.txt
 Date: 27/03/2017
 Authors: Ali Sajassi, John Drake, Nabil Bitar, Ravi Shekhar, Jim Uttaro, Wim Henderickx
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes how Ethernet VPN (EVPN) can be used as an Network Virtualization Overlay (NVO) solution and explores the various tunnel encapsulation options over IP and their impact on the EVPN control-plane and procedures. In particular, the following encapsulation options are analyzed: VXLAN, NVGRE, and MPLS over GRE.
    
draft-ietf-bess-evpn-prefix-advertisement-04.txt
 IP Prefix Advertisement in EVPN
 
 draft-ietf-bess-evpn-prefix-advertisement-04.txt
 Date: 12/02/2017
 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 IP/MPLS and/or an NVO-based network. In NVO 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 may not support their own 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-01.txt
 Operational Aspects of Proxy-ARP/ND in EVPN Networks
 
 draft-ietf-bess-evpn-proxy-arp-nd-01.txt
 Date: 03/10/2016
 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-04.txt
 Usage and applicability of BGP MPLS based Ethernet VPN
 
 draft-ietf-bess-evpn-usage-04.txt
 Date: 13/03/2017
 Authors: Jorge Rabadan, Senad Palislamovic, Wim Henderickx, Ali Sajassi, Keyur Patel, Aldrin Isaac
 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 will be explained on the example scenario, analyzing the benefits and trade-offs of each option. Along with [RFC7432], this document is intended to provide a simplified guide for the deployment of EVPN in Service Provider networks.
    
draft-ietf-bess-evpn-vpws-11.txt
 VPWS support in EVPN
 
 draft-ietf-bess-evpn-vpws-11.txt
 Date: 12/03/2017
 Authors: Sami Boutros, Ali Sajassi, Samer Salam, John Drake, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes how EVPN can be used to support Virtual Private Wire Service (VPWS) in MPLS/IP networks. EVPN enables the following characteristics for VPWS: single-active as well as all- active multi-homing with flow-based load-balancing, eliminates the need for traditional way of Pseudowire (PW) signaling, and provides fast protection convergence upon node or link failure.
    
draft-ietf-bess-evpn-yang-02.txt
 Yang Data Model for EVPN
 
 draft-ietf-bess-evpn-yang-02.txt
 Date: 13/03/2017
 Authors: Patrice Brissette, Ali Sajassi, Himanshu Shah, Zhenbin Li, Kishore Tiruveedhula, Iftekhar Hussain, 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. Any "add-on" features such as EVPN IRB, EVPN overlay, etc. are for future investigation. This document mainly focuses on EVPN and Ethernet-Segment instance framework.
    
draft-ietf-bess-fat-pw-bgp-02.txt
 Extensions to BGP Signaled Pseudowires to support Flow-Aware Transport Labels
 
 draft-ietf-bess-fat-pw-bgp-02.txt
 Date: 27/03/2017
 Authors: Keyur Patel, Sami Boutros, Jose Liste, Bin Wen, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
[RFC6391] describes a mechanism that uses an additional label (Flow Label) in the MPLS label stack that allows Label Switch Routers to balance flows within Pseudowires at a finer granularity than the individual Pseudowires across the Equal Cost Multiple Paths (ECMPs) that exists within the Packet Switched Network (PSN). Furthermore,[RFC6391] defines the LDP protocol extensions required to synchronize the flow label states between the ingress and egress PEs when using the signaling procedures defined in the [RFC4447]. This draft defines protocol extensions required to synchronize flow label states among PEs when using the BGP-based signaling procedures defined in [RFC4761]. These protocol extensions are equally applicable to point-to-point L2VPNs defined in [RFC6624].
    
draft-ietf-bess-l2l3-vpn-mcast-mib-06.txt
 L2L3 VPN Multicast MIB
 
 draft-ietf-bess-l2l3-vpn-mcast-mib-06.txt
 Date: 20/02/2017
 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 common managed objects used by other MIB modules which are designed for monitoring and/or configuring both Layer 2 and Layer 3 Virtual Private Networks (VPN) that support multicast.
    
draft-ietf-bess-l2vpn-yang-05.txt
 YANG Data Model for MPLS-based L2VPN
 
 draft-ietf-bess-l2vpn-yang-05.txt
 Date: 13/03/2017
 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.
    
draft-ietf-bess-mvpn-expl-track-01.txt
 Explicit Tracking with Wild Card Routes in Multicast VPN
 
 draft-ietf-bess-mvpn-expl-track-01.txt
 Date: 12/12/2016
 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 RFC6625.
    
draft-ietf-bess-mvpn-fast-failover-02.txt
 Multicast VPN fast upstream failover
 
 draft-ietf-bess-mvpn-fast-failover-02.txt
 Date: 13/03/2017
 Authors: Thomas Morin, Robert Kebler
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertized toward a standby upstream PE.
    
draft-ietf-bess-mvpn-mib-03.txt
 MPLS/BGP Layer 3 VPN Multicast Management Information Base
 
 draft-ietf-bess-mvpn-mib-03.txt
 Date: 01/03/2017
 Authors: Zhaohui Zhang, Saud Asif, Andy Green, Sameer Gulrajani, Pradeep Jain, Hiroshi Tsunoda
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor MVPN, Multicast in MultiProtocol Label Switching/Border Gateway Protocol (MPLS/BGP) IP Virtual Private Networks (VPNs) on a router.
    
draft-ietf-bess-nsh-bgp-control-plane-00.txt
 BGP Control Plane for NSH SFC
 
 draft-ietf-bess-nsh-bgp-control-plane-00.txt
 Date: 27/03/2017
 Authors: Adrian Farrel, John Drake, Eric Rosen, Jim Uttaro, Luay Jalil
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt xml
This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC AFI/SAFI with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header. This document adopts the SFC architecture described in RFC 7665.
    
draft-ietf-bess-service-chaining-02.txt
 Service Chaining using Virtual Networks with BGP VPNs
 
 draft-ietf-bess-service-chaining-02.txt
 Date: 31/10/2016
 Authors: Rex Fernando, Stuart Mackie, Dhananjaya Rao, Bruno Rijsman, Maria Napierala, Thomas Morin
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain.
    
draft-ietf-bfcpbis-bfcp-websocket-15.txt
 The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)
 
 draft-ietf-bfcpbis-bfcp-websocket-15.txt
 Date: 08/02/2017
 Authors: Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo Salgueiro, Ram R
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies the use of Binary Floor Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliable transport mechanism between BFCP entities in new scenarios.
    
draft-ietf-bfcpbis-rfc4582bis-16.txt
 The Binary Floor Control Protocol (BFCP)
 
 draft-ietf-bfcpbis-rfc4582bis-16.txt
 Date: 13/11/2015
 Authors: Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16.
    
draft-ietf-bfcpbis-sdp-ws-uri-09.txt
 Session Description Protocol (SDP) WebSocket Connection URI Attribute
 
 draft-ietf-bfcpbis-sdp-ws-uri-09.txt
 Date: 06/02/2017
 Authors: Ram R, Gonzalo Salgueiro
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
The WebSocket protocol enables bidirectional real-time communication between clients and servers in web-based applications. This document specifies extensions to Session Description Protocol (SDP) for application protocols using WebSocket as a transport.
    
draft-ietf-bfd-multipoint-09.txt
 BFD for Multipoint Networks
 
 draft-ietf-bfd-multipoint-09.txt
 Date: 12/10/2016
 Authors: Dave Katz, David Ward, Juniper Networks
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org.
    
draft-ietf-bfd-multipoint-active-tail-03.txt
 BFD Multipoint Active Tails.
 
 draft-ietf-bfd-multipoint-active-tail-03.txt
 Date: 13/10/2016
 Authors: Dave Katz, David Ward, Juniper Networks
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document describes active tail extensions to the Bidirectional Forwarding Detection (BFD) protocol for multipoint and multicast networks. Comments on this draft should be directed to rtg- bfd@ietf.org.
    
draft-ietf-bfd-optimizing-authentication-02.txt
 Optimizing BFD Authentication
 
 draft-ietf-bfd-optimizing-authentication-02.txt
 Date: 03/01/2017
 Authors: Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: xml txt
This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD [RFC5880].
    
draft-ietf-bfd-yang-05.txt
 Yang Data Model for Bidirectional Forwarding Detection (BFD)
 
 draft-ietf-bfd-yang-05.txt
 Date: 10/03/2017
 Authors: Reshad Rahman, Lianshu Zheng, Juniper Networks, Mahesh Jethanandani, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD).
    
draft-ietf-bier-architecture-05.txt
 Multicast using Bit Index Explicit Replication
 
 draft-ietf-bier-architecture-05.txt
 Date: 28/10/2016
 Authors: IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Tony Przygienda, Sam Aldrin
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
This document specifies a new architecture for the forwarding of multicast data packets. It provides optimal forwarding of multicast packets through a "multicast domain". However, it does not require a protocol for explicitly building multicast distribution trees, nor does it require intermediate nodes to maintain any per-flow state. This architecture is known as "Bit Index Explicit Replication" (BIER). When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. Elimination of the per- flow state and the explicit tree-building protocols results in a considerable simplification.
    
draft-ietf-bier-bgp-ls-bier-ext-00.txt
 BGP Link-State extensions for BIER
 
 draft-ietf-bier-bgp-ls-bier-ext-00.txt
 Date: 18/01/2017
 Authors: Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document specifies extensions to the BGP Link-state address- family in order to advertising BIER information.
    
draft-ietf-bier-bier-yang-01.txt
 YANG Data Model for BIER Protocol
 
 draft-ietf-bier-bier-yang-01.txt
 Date: 21/01/2017
 Authors: Ran Chen, fangwei hu, Zheng Zhang, dai.xianxian@zte.com.cn, Mahesh Sivakumar
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
This document defines a YANG data model for BIER configuration and operation.
    
draft-ietf-bier-idr-extensions-02.txt
 BGP Extensions for BIER
 
 draft-ietf-bier-idr-extensions-02.txt
 Date: 17/01/2017
 Authors: Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt xml
Bit Index Explicit Replication (BIER) is a new multicast forwarding architecture which doesn't require an explicit tree-building protocol and doesn't require intermediate routers to maintain any multicast state. BIER is applicable in a multi-tenant data center network environment for efficient delivery of Broadcast, Unknown-unicast and Multicast (BUM) traffic while eliminating the need for maintaining a huge amount of multicast state in the underlay. This document describes BGP extensions for advertising the BIER-specific information. These extensions are applicable in those multi-tenant data centers where BGP instead of IGP is deployed as an underlay for network reachability advertisement. These extensions may also be applicable in other scenarios.
    
draft-ietf-bier-isis-extensions-04.txt
 BIER support via ISIS
 
 draft-ietf-bier-isis-extensions-04.txt
 Date: 27/03/2017
 Authors: Les Ginsberg, Tony Przygienda, Sam Aldrin, Zhaohui Zhang
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
Specification of an ISIS extension to support BIER domains and sub- domains.
    
draft-ietf-bier-mpls-encapsulation-06.txt
 Encapsulation for Bit Index Explicit Replication in MPLS and non-MPLS Networks
 
 draft-ietf-bier-mpls-encapsulation-06.txt
 Date: 09/12/2016
 Authors: IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Jeff Tantsura, Sam Aldrin, Israel Meilik
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. When a multicast data packet enters the domain, the ingress router determines the set of egress routers to which the packet needs to be sent. The ingress router then encapsulates the packet in a BIER header. The BIER header contains a bitstring in which each bit represents exactly one egress router in the domain; to forward the packet to a given set of egress routers, the bits corresponding to those routers are set in the BIER header. The details of the encapsulation depend on the type of network used to realize the multicast domain. This document specifies a BIER encapsulation that can be used in an MPLS network, or with slight differences, in a non-MPLS network.
    
draft-ietf-bier-mvpn-05.txt
 Multicast VPN Using BIER
 
 draft-ietf-bier-mvpn-05.txt
 Date: 10/01/2017
 Authors: Eric Rosen, Mahesh Sivakumar, Sam Aldrin, Andrew Dolganow, Tony Przygienda
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a Service Provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over an SP backbone network.
    
draft-ietf-bier-oam-requirements-03.txt
 Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer
 
 draft-ietf-bier-oam-requirements-03.txt
 Date: 17/01/2017
 Authors: Gregory Mirsky, Erik Nordmark, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Lianshu Zheng, Mach Chen, Nobo Akiya, Santosh Pallagatti
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
This document describes a list of functional requirement toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network.
    
draft-ietf-bier-ospf-bier-extensions-05.txt
 OSPF Extensions for BIER
 
 draft-ietf-bier-ospf-bier-extensions-05.txt
 Date: 13/03/2017
 Authors: Peter Psenak, Nagendra Kumar, IJsbrand Wijnands, Andrew Dolganow, Tony Przygienda, Zhaohui Zhang, Sam Aldrin
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the OSPF protocol extension required for BIER with MPLS encapsulation.
    
draft-ietf-bier-path-mtu-discovery-01.txt
 Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer
 
 draft-ietf-bier-path-mtu-discovery-01.txt
 Date: 17/01/2017
 Authors: Gregory Mirsky, Tony Przygienda, Andrew Dolganow
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer.
    
draft-ietf-bier-ping-01.txt
 BIER Ping and Trace
 
 draft-ietf-bier-ping-01.txt
 Date: 17/01/2017
 Authors: Nagendra Kumar, Carlos Pignataro, Nobo Akiya, Lianshu Zheng, Mach Chen, Gregory Mirsky
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes the mechanism and basic BIER OAM packet format that can be used to perform failure detection and isolation on BIER data plane.
    
draft-ietf-bier-pmmm-oam-01.txt
 Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer
 
 draft-ietf-bier-pmmm-oam-01.txt
 Date: 24/01/2017
 Authors: Gregory Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt xml
This document describes a passive performance measurement method for multicast service over Bit Index Explicit Replication (BIER) domain.
    
draft-ietf-bier-use-cases-04.txt
 BIER Use Cases
 
 draft-ietf-bier-use-cases-04.txt
 Date: 08/01/2017
 Authors: Nagendra Kumar, Rajiv Asati, Mach Chen, Xiaohu Xu, Andrew Dolganow, Tony Przygienda, arkadiy.gulko@thomsonreuters.com, Dom Robinson, Vishal Arya, Caitlin Bestler
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes some of the use-cases for BIER.
    
draft-ietf-bmwg-dcbench-methodology-03.txt
 Data Center Benchmarking Methodology
 
 draft-ietf-bmwg-dcbench-methodology-03.txt
 Date: 30/12/2016
 Authors: Lucien Avramov, jhrapp@gmail.com
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
The purpose of this informational document is to establish test and evaluation methodology and measurement techniques for physical network equipment in the data center.
    
draft-ietf-bmwg-dcbench-terminology-06.txt
 Data Center Benchmarking Terminology
 
 draft-ietf-bmwg-dcbench-terminology-06.txt
 Date: 30/12/2016
 Authors: Lucien Avramov, jhrapp@gmail.com
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
The purpose of this informational document is to establish definitions, discussion and measurement techniques for data center benchmarking. Also, it is to introduce new terminologies applicable to data center performance evaluations. The purpose of this document is not to define the test methodology, but rather establish the important concepts when one is interested in benchmarking network switches and routers in the data center.
    
draft-ietf-bmwg-ipv6-nd-06.txt
 Benchmarking The Neighbor Discovery Protocol
 
 draft-ietf-bmwg-ipv6-nd-06.txt
 Date: 02/03/2017
 Authors: William Cerveny, Ron Bonica, Reji Thomas
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt xml
This document provides benchmarking procedures for Neighbor Discovery Protocol (NDP). It also proposes metrics by which an NDP implementation's scaling capabilities can be measured.
    
draft-ietf-bmwg-ipv6-tran-tech-benchmarking-05.txt
 Benchmarking Methodology for IPv6 Transition Technologies
 
 draft-ietf-bmwg-ipv6-tran-tech-benchmarking-05.txt
 Date: 29/03/2017
 Authors: Marius Georgescu, Liviu Pislaru, Gabor Lencse
 Working Group: Benchmarking Methodology (bmwg)
 Formats: