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: Individual Submissions (none)
 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-ospf-admin-tags-05.txt
 Extensions to OSPF for Advertising Prefix/Link Administrative Tags
 
 draft-acee-ospf-admin-tags-05.txt
 Date: 12/09/2016
 Authors: Acee Lindem, Peter Psenak
 Working Group: Individual Submissions (none)
 Formats: txt
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to associate tags with prefixes and links. Previously, OSPFv2 and OSPFv3 were relegated to a single tag for AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may advertised for all types of prefixes and links. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. The ISIS protocol supports a similar mechanism that is described in RFC 5130.
    
draft-acee-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-adid-urn-03.txt
 Advertising Digital Identification (Ad-ID) URN Namespace Definition
 
 draft-adid-urn-03.txt
 Date: 17/01/2017
 Authors: jwold@ad-id.org
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
Advertising Digital Identification (Ad-ID) Identifiers are used identifying Advertising Assets across all media platforms. This document defines the formal Uniform Resource Name (URN) Namespace Identifier (NID) "adid" for Ad-ID Identifiers.
    
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-adpkja-dnsop-special-names-problem-06.txt
 Problem Statement for the Reservation of Special-Use Domain Names using RFC6761
 
 draft-adpkja-dnsop-special-names-problem-06.txt
 Date: 10/09/2016
 Authors: Geoff Huston, Peter Koch, Alain Durand, Warren Kumari
 Working Group: Individual Submissions (none)
 Formats: txt xml
The dominant protocol for name resolution on the Internet is the Domain Name System (DNS). However, other protocols exist that are fundamentally different from the DNS, and may or may not share the same namespace. When an end-user triggers resolution of a name on a system that supports multiple, different protocols or resolution mechanisms, it is desirable that the protocol used is unambiguous, and that requests intended for one protocol are not inadvertently answered using another protocol. RFC 6761 introduced a framework by which a particular domain name could be acknowledged as being special. Various challenges have become apparent with this application of the guidance provided in RFC 6761. This document focuses solely on documenting the specific challenges created by RFC 6761 in the form of a problem statement in order to facilitate further discussions of potential solutions. In particular, it refrains from proposing or promoting any solution. Also, the current document does not focus on other general issues related to the use of special use domain names.
    
draft-agv-rtgwg-spring-segment-routing-mrt-03.txt
 Maximally Redundant Trees in Segment Routing
 
 draft-agv-rtgwg-spring-segment-routing-mrt-03.txt
 Date: 29/08/2016
 Authors: anil.ietf@gmail.com, Gaurav Agrawal, Vinod KumarS, Chris Bowers
 Working Group: Individual Submissions (none)
 Formats: xml txt
[RFC7812] defines an architecture for IP/LDP Fast Reroute using Maximally Redundant Trees (MRT-FRR). This document extends the use of MRT to provide link and node protection for networks that use segment routing. This document makes use of the inherent support in segment routing for associating segments with different algorithms for computing next hops to reach prefixes. It assigns new Segment Routing Algorithms values corresponding to the MRT-Red and MRT-Blue next-hop computations defined in [RFC7811].
    
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-akagiri-dmarc-virtual-verification-01.txt
 DMARC verification without record definitions
 
 draft-akagiri-dmarc-virtual-verification-01.txt
 Date: 21/09/2016
 Authors: Genki Yasutaka, Takehito Akagiri, Masaki Kase, Kouji Okada, Kaoru Maeda
 Working Group: Individual Submissions (none)
 Formats: txt
While DMARC is a powerful architecture to protect email users from malicious email activities, its deployment is still a work in progress. To encourage further adoption of DMARC, in this draft we propose an incremental deployment procedure.
    
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-allan-spring-mpls-multicast-framework-02.txt
 A Framework for Computed Multicast applied to MPLS based Segment Routing
 
 draft-allan-spring-mpls-multicast-framework-02.txt
 Date: 15/09/2016
 Authors: Dave Allan, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a multicast solution for Segment Routing with MPLS data plane. It is consistent with the Segment Routing architecture in that an IGP is augmented to distribute information in addition to the link state. In this solution it is multicast group membership information sufficient to synchronize state in a given network domain. Computation is employed to determine the topology of any loosely specified multicast distribution tree.
    
draft-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-anderson-v6ops-v4v6-xlat-prefix-02.txt
 Local-use IPv4/IPv6 Translation Prefix
 
 draft-anderson-v6ops-v4v6-xlat-prefix-02.txt
 Date: 08/09/2016
 Authors: Tore Anderson
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document reserves the IPv6 prefix 64:ff9b:1::/48 for local use with IPv4/IPv6 translation mechanisms. It updates RFC6890 in order to reflect this reservation.
    
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-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-01.txt
 High-level VNF Descriptors using NEMO
 
 draft-aranda-nfvrg-recursive-vnf-01.txt
 Date: 13/10/2016
 Authors: Pedro Aranda, Diego Lopez, Stefano Salsano
 Working Group: Individual Submissions (none)
 Formats: txt xml
Current efforts in the scope of Network Function Virtualisation(NFV) propose YAML-based descriptors for Virtual Network Functions (VNFs) and for their composition in Network Services (NS) These descriptors are human-readable but hardly understandable by humans. On the other hand, there has been an effort proposed to the IETF to define a human-readable (and understandable) representation for networks, known as NEMO. In this draft, we propose a simple extension to NEMO to accommodate VNF Descriptors (VNFDs) in a similar manner as inline assembly is integrated in higher-level programming languages. This approach enables the creation of recursive VNF forwarding graphs in Service Descriptors, practically making them recursive.
    
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-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-asaeda-icnrg-contrace-01.txt
 Contrace: Traceroute Facility for Content-Centric Network
 
 draft-asaeda-icnrg-contrace-01.txt
 Date: 15/11/2016
 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 forwarding 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.
    
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-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-01.txt
 Control and Monitoring Differentiated Service Code Point in Two-Way Active Measurement Protocol (TWAMP)
 
 draft-bailmir-ippm-twamp-dscp-ctrl-mon-01.txt
 Date: 24/08/2016
 Authors: Steve Baillargeon, Gregory Mirsky
 Working Group: Individual Submissions (none)
 Formats: 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-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-00.txt
 Path Computation Element Communication Protocol Extensions for Associated Bidirectional Label Switched Paths (LSPs)
 
 draft-barth-pce-association-bidir-00.txt
 Date: 27/10/2016
 Authors: Colby Barth, Rakesh Gandhi, Bin Wen
 Working Group: Individual Submissions (none)
 Formats: txt
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The stateful PCE extensions allow stateful control of Multi-Protocol Label Switching (MPLS) Traffic Engineering (TE) Label Switched Paths (LSPs) using PCEP. This document defines Path Computation Element Communication Protocol (PCEP) extensions for binding two reverse unidirectional RSVP-TE LSPs into an Associated Bidirectional Label Switched Path (LSP).
    
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-04.txt
 Special-Purpose IP Address Registries
 
 draft-bchv-rfc6890bis-04.txt
 Date: 09/02/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-bergmann-bier-ccast-02.txt
 Constrained-Cast: Source-Routed Multicast for RPL
 
 draft-bergmann-bier-ccast-02.txt
 Date: 05/10/2016
 Authors: Olaf Bergmann, Carsten Bormann, Stefanie Gerdes, Hao Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines a protocol for forwarding multicast traffic in a constrained node network employing the RPL routing protocol in non-storing mode.
    
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-06.txt
 An IPv6 Distributed Client Mobility Management approach using existing mechanisms
 
 draft-bernardos-dmm-cmip-06.txt
 Date: 12/09/2016
 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-07.txt
 A PMIPv6-based solution for Distributed Mobility Management
 
 draft-bernardos-dmm-pmip-07.txt
 Date: 12/09/2016
 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-01.txt
 Multi-domain Network Virtualization
 
 draft-bernardos-nfvrg-multidomain-01.txt
 Date: 31/10/2016
 Authors: Carlos Bernardos, Luis Contreras, Ishan Vaishnavi
 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-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-01.txt
 Packet Loss measurement Model
 
 draft-bhaprasud-ippm-pm-01.txt
 Date: 27/01/2017
 Authors: Praveen Ananthasankaran
 Working Group: Individual Submissions (none)
 Formats: txt
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-03.txt
 Time-Based Uni-Directional Attestation
 
 draft-birkholz-tuda-03.txt
 Date: 09/01/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-04.txt
 Asynchronous Management Architecture
 
 draft-birrane-dtn-ama-04.txt
 Date: 30/10/2016
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the motivation, desirable properties, system model, roles/responsibilities, and component models associated with 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 human-in-the-loop operations centers with synchronous feedback in the context of administrative 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-02.txt
 Secondary Certificate Authentication in HTTP/2
 
 draft-bishop-httpbis-http2-additional-certs-02.txt
 Date: 31/10/2016
 Authors: Mike Bishop, 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 a how TLS exported authenticators [I-D.draft- 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-bonica-intarea-eping-02.txt
 Extended Ping (Xping)
 
 draft-bonica-intarea-eping-02.txt
 Date: 06/10/2016
 Authors: Ron Bonica, Reji Thomas
 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 and Extended Echo Reply. Both ICMP messages are defined herein.
    
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-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-09.txt
 An MPTCP Option for Network-Assisted MPTCP
 
 draft-boucadair-mptcp-plain-mode-09.txt
 Date: 27/10/2016
 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 an MPTCP option that is used in the context of Network-Assisted MPTCP: MP_CONVERT.
    
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-bowbakova-rtgwg-enterprise-pa-multihoming-01.txt
 Enterprise Multihoming using Provider-Assigned Addresses without Network Prefix Translation: Requirements and Solution
 
 draft-bowbakova-rtgwg-enterprise-pa-multihoming-01.txt
 Date: 31/10/2016
 Authors: Fred Baker, Chris Bowers, J. Linkova
 Working Group: Individual Submissions (none)
 Formats: txt xml
Connecting an enterprise site to multiple ISPs using provider- assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs. This document attempts to define a complete solution to this problem. It covers the behavior of routers to forward traffic taking into account source address, and it covers the behavior of host to select appropriate source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this documents also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator .
    
draft-bradley-oauth-jwt-encoded-state-06.txt
 Encoding claims in the OAuth 2 state parameter using a JWT
 
 draft-bradley-oauth-jwt-encoded-state-06.txt
 Date: 11/01/2017
 Authors: John Bradley, Torsten Lodderstedt, Hans Zandbelt
 Working Group: Individual Submissions (none)
 Formats: txt pdf 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-11.txt
 Intellectual Property Rights in IETF Technology
 
 draft-bradner-rfc3979bis-11.txt
 Date: 25/01/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 memo 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 memo replaces section 10 of RFC 2026 and 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-00.txt
 Low Latency,Low Loss,Scalable Throughput (L4S) Internet Service: Architecture
 
 draft-briscoe-tsvwg-l4s-arch-00.txt
 Date: 31/10/2016
 Authors: Bob Briscoe, Koen De Schepper, Marcelo Bagnulo
 Working Group: Individual Submissions (none)
 Formats: txt
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-02.txt
 Data Formats for In-situ OAM
 
 draft-brockners-inband-oam-data-02.txt
 Date: 31/10/2016
 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 (OAM) 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 types and data formats for in-situ OAM data records. In-situ OAM data records can be embedded into a variety of transports such as NSH, Segment Routing, VXLAN-GPE, native IPv6 (via extension header), or IPv4. In-situ OAM is to complement current out-of-band OAM mechanisms based on ICMP or other types of probe packets.
    
draft-brockners-inband-oam-requirements-02.txt
 Requirements for In-situ OAM
 
 draft-brockners-inband-oam-requirements-02.txt
 Date: 31/10/2016
 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-02.txt
 Encapsulations for In-situ OAM Data
 
 draft-brockners-inband-oam-transport-02.txt
 Date: 31/10/2016
 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 (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 records 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-02.txt
 Proof of Transit
 
 draft-brockners-proof-of-transit-02.txt
 Date: 31/10/2016
 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-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-framework-02.txt
 Synonymous Flow Label Framework
 
 draft-bryant-mpls-sfl-framework-02.txt
 Date: 10/10/2016
 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-00.txt
 Synchronisation of Network Parameters
 
 draft-bryant-rtgwg-param-sync-00.txt
 Date: 13/10/2016
 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 parameter. The document also defines the solution to one specific case: the agreement of a common convergence timer value for use in network convergence.
    
draft-busibel-teas-yang-path-computation-01.txt
 Yang model for requesting Path Computation
 
 draft-busibel-teas-yang-path-computation-01.txt
 Date: 15/11/2016
 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: pdf txt
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 for a YANG model to request path computation.
    
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-04.txt
 Using Remote Invalidation With RPC-Over-RDMA Transports
 
 draft-cel-nfsv4-reminv-design-04.txt
 Date: 21/09/2016
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: xml txt
Remote Invalidation relieves RDMA requesters/initiators of some of the burden of preparing memory to be accessed remotely, thus reducing the latency of transactions that require the use of RDMA Read and Write operations. This document considers how to introduce Remote Invalidation to RPC-over-RDMA transport protocols.
    
draft-cel-nfsv4-rpcrdma-cm-pvt-msg-00.txt
 RDMA Connection Manager Private Messages For RPC-Over-RDMA Version One
 
 draft-cel-nfsv4-rpcrdma-cm-pvt-msg-00.txt
 Date: 29/09/2016
 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. Such messages indicate peer support for Remote Invalidation and larger-than-default inline thresholds, but can be extended. The Private Data message format defined in this document is experimental only.
    
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-chattopadhyay-sdnrg-multi-party-sdn-trust-03.txt
 Multi-party Multi-Domain Trust Architecture Recommendations for SDN Deployment in Carrier Network
 
 draft-chattopadhyay-sdnrg-multi-party-sdn-trust-03.txt
 Date: 21/09/2016
 Authors: saurabhchattopadhya@hcl.com, Kaushik Datta
 Working Group: Individual Submissions (none)
 Formats: txt
This draft analyzes the complexities involved in setting up the certification infrastructure for multi-tenant, multi-domain SDN adopted network environment. There are certain architectural options available to address these complexities, and the same have been consolidated and analyzed in the draft. However, there are certain implementation level challenges that create difficulties to operationalize these options. And these challenges have been recognized in the draft and further translated into requirements for setting up an operational framework suitable for managing certificate chains for SDN integrated environment. Finally, a next level of assessment has been carried out to consolidate contemporary work happening in different Work Groups and their likely coverage over identified operational framework requirements.
    
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-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-ipid-pm-01.txt
 Using IPID for Performance Monitoring in VxLAN Network
 
 draft-chen-nvo3-ipid-pm-01.txt
 Date: 19/09/2016
 Authors: Hao Chen
 Working Group: Individual Submissions (none)
 Formats: txt
IP Identification(IPID)is a field in IP header primarily used to uniquely identify the group of fragments of a single IP packet. The value of IPID field in a packet from a specific traffic flow or source IP address keeps increasing until wrapped-around. This document specifies a method by carefully examining IPID value to monitor the performance of VxLAN network. In this memo packet loss measurement is mainly considered. This method requires no extra hardware support, which means it is compatible with most of the deployed routers or switches. Such a mechanism is applicable to IPv4 network and potential useful in overlay network with different data encapsulation.
    
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-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-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-01.txt
 Connections and Accesses for Hierarchical PCE
 
 draft-chen-pce-h-connect-access-01.txt
 Date: 31/10/2016
 Authors: Huaimo Chen, Mehmet Toy, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) to distribute information about connections and access points for supporting a hierarchical PCE system.
    
draft-chen-pce-h-discovery-01.txt
 Hierarchical PCE Discovery
 
 draft-chen-pce-h-discovery-01.txt
 Date: 31/10/2016
 Authors: Huaimo Chen, Mehmet Toy, Lei Liu, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) to discover parent child relations and the information on 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-01.txt
 Native PCE TED
 
 draft-chen-pce-pcc-ted-01.txt
 Date: 08/01/2017
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to advertise the information about the links 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-rdns-urn-07.txt
 A Uniform Resource Name (URN) Namespace for Enterprise YANG Modules
 
 draft-chen-rdns-urn-07.txt
 Date: 19/09/2016
 Authors: I. Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Namespace Identifier (NID) for Uniform Resource Namespace (URN) resources to uniquely identify enterprise YANG modules. This document defines a single top level "rdns" Namespace identifier (NID), with which organizations and enterprises can define Uniform Resource Name (URN) Namespaces to uniquely identify enterprise YANG modules.
    
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-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-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-clemm-netmod-mount-05.txt
 Mounting YANG-Defined Information from Remote Datastores
 
 draft-clemm-netmod-mount-05.txt
 Date: 19/09/2016
 Authors: Alexander Clemm, Jan Medved, Eric Voit
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces capabilities that allow YANG datastores to reference and incorporate information from remote datastores. This is accomplished by extending YANG with the ability to define mount points that reference data nodes in another YANG subtree, by subsequently allowing those data nodes to be accessed by client applications as if part of an alternative data hierarchy, and by providing the necessary means to manage and administer those mount points. Two flavors are defined: Alias-Mount allows to mount local subtrees, while Peer-Mount allows subtrees to reside on and be authoritatively owned by a remote server. YANG-Mount facilitates the development of applications that need to access data that transcends individual network devices while improving network-wide object consistency, or that require an aliasing capability to be able to create overlay structures for YANG data.
    
draft-clw-rfc6434-bis-00.txt
 IPv6 Node Requirements
 
 draft-clw-rfc6434-bis-00.txt
 Date: 31/10/2016
 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. NB. This is a first -00 version of the update to RFC 6434. We have not yet edited original text from RFC 6434 apart from the author and acknowledgement texts, which carry forward from the older versions. We have indicated intended changes (additions, updates or deletion of text at a high level in the sections below with text delimited by **BIS ... ** comments, e.g. **BIS Add discussion of the impact of RFC xxxx ** **BIS Update reference of RFC 3484 and note new address selection implications** etc. These will become edits in future versions once the substance of the changes is agreed.
    
draft-cokus-sacm-oval-common-model-01.txt
 OVAL(R) Common Model
 
 draft-cokus-sacm-oval-common-model-01.txt
 Date: 07/09/2016
 Authors: Michael Cokus, Daniel Haynes, David Rothenberg, Juan Gonzalez
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
This document specifies Version 5.11.1 of the Common Model of the Open Vulnerability and Assessment Language (OVAL). It contains definitions of the constructs and enumerations that are used throughout the other core models in the OVAL Language both eliminating duplication and facilitating reuse.
    
draft-cokus-sacm-oval-results-model-01.txt
 OVAL(R) Results Model
 
 draft-cokus-sacm-oval-results-model-01.txt
 Date: 07/09/2016
 Authors: Michael Cokus, Daniel Haynes, David Rothenberg, Juan Gonzalez
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document specifies Version 5.11.1 of the OVAL Results Model which is used to express the results of an evaluation of a set of systems based on a set of OVAL Definitions and the target systems' OVAL System Characteristics.
    
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-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-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-rsvp-rmr-extension-01.txt
 RSVP Extensions for RMR
 
 draft-deshmukh-rsvp-rmr-extension-01.txt
 Date: 31/10/2016
 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-01.txt
 NTP Client Data Minimization
 
 draft-dfranke-ntp-data-minimization-01.txt
 Date: 29/10/2016
 Authors: Daniel Franke, Aanchal Malhotra
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-00.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-00.txt
 Date: 31/10/2016
 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 optical parameters characterising the 100G and above interfaces. 100G and above Transceivers support coherent transmission, different modulation format, multiple FEC algorithms not yet specified by ITU-T G.698.2 [ITU.G698.2] or any other ITU-T recommendation. The use cases and the state of the Coherent transceivers is well describe in draft-many-coherent-DWDM-if-control. The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of the multi-vendor IaDI optical link.
    
draft-dharinigert-ccamp-dwdm-if-lmp-02.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-02.txt
 Date: 29/10/2016
 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-01.txt
 Applicability of Path Computation Element (PCE) for Abstraction and Control of TE Networks (ACTN)
 
 draft-dhody-pce-applicability-actn-01.txt
 Date: 19/10/2016
 Authors: Dhruv Dhody, Young Lee, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-05.txt
 Path Computation Element communication Protocol extension for relationship between LSPs and Attributes or Policies
 
 draft-dhody-pce-association-attr-05.txt
 Date: 24/10/2016
 Authors: Dhruv Dhody, Wenson Wu
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-02.txt
 Experimental Codepoint Allocation for Path Computation Element communication Protocol (PCEP)
 
 draft-dhody-pce-pcep-exp-codepoints-02.txt
 Date: 08/12/2016
 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-10.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-10.txt
 Date: 28/08/2016
 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 RFC 6006 and RFC 7334 describes these mechanisms for intra and inter domain path computation via PCE(s). 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-03.txt
 Stateful Path Computation Element (PCE) Inter-domain Considerations
 
 draft-dhody-pce-stateful-pce-interdomain-03.txt
 Date: 27/12/2016
 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.
    
draft-dhody-pce-stateful-pce-lspdb-realtime-sync-01.txt
 Realtime Synchronization between Redundant Stateful PCEs.
 
 draft-dhody-pce-stateful-pce-lspdb-realtime-sync-01.txt
 Date: 27/12/2016
 Authors: Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Path Computation Element Communication Protocol (PCEP) provides mechanisms for Path Computation Elements (PCEs) to perform path computations in response to Path Computation Clients (PCCs) requests. The stateful PCE further extentds PCEP to enable stateful control of MPLS-TE and GMPLS Label Switched Paths (LSPs) via PCEP and maintaining of these LSPs at the stateful PCE. This document describes the mechanisms of realtime LSP Database (LSP-DB) synchronization between stateful PCEs.
    
draft-dhody-pce-stateful-pce-vendor-01.txt
 Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for stateful PCE.
 
 draft-dhody-pce-stateful-pce-vendor-01.txt
 Date: 25/09/2016
 Authors: Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: xml 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). 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-06.txt
 PCEP Extension for Distribution of Link-State and TE Information.
 
 draft-dhodylee-pce-pcep-ls-06.txt
 Date: 14/09/2016
 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-02.txt
 Hierarchical Stateful Path Computation Element (PCE).
 
 draft-dhodylee-pce-stateful-hpce-02.txt
 Date: 29/10/2016
 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-01.txt
 Issues Related to RPC-over-RDMA Internode Round Trips
 
 draft-dnoveck-nfsv4-rpcrdma-rtissues-01.txt
 Date: 03/09/2016
 Authors: David Noveck
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-dnoveck-nfsv4-rpcrdma-xcharext-03.txt
 RPC-over-RDMA Extension to Manage Transport Properties
 
 draft-dnoveck-nfsv4-rpcrdma-xcharext-03.txt
 Date: 24/09/2016
 Authors: David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies an extension RPC-over-RDMA Version Two. The extension enables endpoints of an RPC-over-RDMA connection to exchange information which can be used to optimize message transfer.
    
draft-dolson-plus-middlebox-benefits-02.txt
 Beneficial Functions of Middleboxes
 
 draft-dolson-plus-middlebox-benefits-02.txt
 Date: 15/02/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-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-nvo3-encap-00.txt
 NVO3 Encapsulation Considerations
 
 draft-dt-nvo3-encap-00.txt
 Date: 07/02/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-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-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-04.txt
 Additional XML Security Uniform Resource Identifiers (URIs)
 
 draft-eastlake-rfc6931bis-xmlsec-uris-04.txt
 Date: 26/09/2016
 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-04.txt
 TRILL: Link Security
 
 draft-eastlake-trill-link-security-04.txt
 Date: 03/10/2016
 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-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-emailreg-pradeep-kumar-xplorer-whois-01.txt
 Extensions to WHois service to allow query on email identities
 
 draft-emailreg-pradeep-kumar-xplorer-whois-01.txt
 Date: 08/09/2016
 Authors: pradeep xplorer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the need for a WHois email address service similar to the internet domainname WHois service. Theres a need for a registered email address as opposed to non-registered email address to fight internet SPAM, as well as encouraging email use for personal, commercial and all kinds of purposes.An internet user can have multiple email identities. This service implementation would also help deliver a Single SignON solution for WWW services.
    
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-11.txt
 NAT traversal for LISP
 
 draft-ermagan-lisp-nat-traversal-11.txt
 Date: 29/08/2016
 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-02.txt
 LISP Control Plane integration with NSH
 
 draft-ermagan-lisp-nsh-02.txt
 Date: 03/10/2016
 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-04.txt
 Fast Reroute for Node Protection in LDP-based LSPs
 
 draft-esale-mpls-ldp-node-frr-04.txt
 Date: 25/10/2016
 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-fairhurst-taps-transports-usage-udp-03.txt
 Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDP- Lite) Transport Protocols
 
 draft-fairhurst-taps-transports-usage-udp-03.txt
 Date: 05/10/2016
 Authors: Gorry Fairhurst, Tom Jones
 Working Group: Transport Services (taps)
 Formats: xml txt
This document describes how the User Datagram Protocol (UDP) and the Lightweight User Datagram Protocol (UDP-Lite) transport protocols expose services to applications and how an application can configure and use the features offered by the transport service. The document is intended as a contribution to the Transport Services (TAPS) working group to assist in analysis of the UDP and UDP-Lite transport interface.
    
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-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-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-02.txt
 LISP Distinguished Name Encoding
 
 draft-farinacci-lisp-name-encoding-02.txt
 Date: 05/10/2016
 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-11.txt
 LISP Traffic Engineering Use-Cases
 
 draft-farinacci-lisp-te-11.txt
 Date: 05/09/2016
 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-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-03.txt
 A Definition of the Term "Soon" for Use in Discussions with Working Group Chairs and Area Directors
 
 draft-farrel-soon-03.txt
 Date: 18/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-00.txt
 HTTPS delegation in CDNI
 
 draft-fieau-cdni-https-delegation-00.txt
 Date: 31/10/2016
 Authors: Frederic Fieau, Stephan Emile, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document examines probable solutions for delegating of encrypted content within the context of CDN interconnection. HTTPS delegation allows a delivering party, e.g. a CDN, to deliver content for and on- behalf of an origin server. The HTTPS delegation also expects delivering content without compromising security, integrity and privacy of the user. This document examines Internet Drafts that have been submitted along with their implementation status.
    
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-fisher-cloudassets-00.txt
 Cloud Assets
 
 draft-fisher-cloudassets-00.txt
 Date: 19/09/2016
 Authors: Todd Fisher, Peter Walsh
 Working Group: Individual Submissions (none)
 Formats: txt
There is no standardized method to describe assets used in a cloud such that they can be moved from one cloud to the next independent of the underlying architecture. This document defines Cloud Assets as a lightweight description of cloud resources and proposes a standardization of Cloud Assets into three major categories: Resource Assets, Component Assets, and Composite Assets.
    
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-02.txt
 Cisco Systems' Encapsulated Remote Switch Port Analyzer (ERSPAN)
 
 draft-foschiano-erspan-02.txt
 Date: 09/02/2017
 Authors: Marco Foschiano, 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-03.txt
 Variant Rules
 
 draft-freytag-lager-variant-rules-03.txt
 Date: 23/01/2017
 Authors: Asmus Freytag
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
This document gives guidance on designing well-behaved Label Generation Rulesets (LGRs) that support variant labels. Typical examples of labels and LGRs are IDNs and zone registration policies defining permissible IDN labels. Variant labels are labels that are either visually or semantically indistinguishable from an applied for label and are typically delegated together with the applied-for label, or permanently reserved. While RFC7940 defines the syntactical requirements for specifying the label generation rules for variant labels, additional considerations apply that ensure that the label generation rules are consistent and well-behaved in the presence of variants.
    
draft-fsc-softwire-dhcp4o6-saddr-opt-07.txt
 DHCPv4 over DHCPv6 Source Address Option
 
 draft-fsc-softwire-dhcp4o6-saddr-opt-07.txt
 Date: 01/02/2017
 Authors: Ian Farrer, Qi Sun, Yong Cui, Linhui Sun
 Working Group: Dynamic Host Configuration (dhc)
 Formats: xml txt
DHCPv4 over DHCPv6 [RFC7341] describes a mechanism for dynamically configuring IPv4 over an IPv6-only network. For DHCPv4 over DHCPv6 to function with some IPv4-over-IPv6 softwire mechanisms and deployment scenarios, the operator must learn the /128 IPv6 address that the client will use as the source of IPv4-in-IPv6 tunnel. This address, in conjunction with the IPv4 address and the Port Set ID allocated to the DHCP 4o6 client are used to create a binding table entry in the softwire tunnel concentrator. This memo defines two DHCPv6 options used to communicate the source tunnel IPv6 address between the DHCP 4o6 client and server. It also describes a method for configuring the client with the IPv6 address of the border router so that the softwire can be established. It is designed to work in conjunction with the IPv4 address allocation process.
    
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-fu-sidr-unexpected-scenarios-02.txt
 Scenarios of unexpected resource assignment in RPKI
 
 draft-fu-sidr-unexpected-scenarios-02.txt
 Date: 13/09/2016
 Authors: Yu Fu, Zhiwei Yan, Xiaowei Liu, Cuicui Wang
 Working Group: Individual Submissions (none)
 Formats: txt
There are some unexpected scenarios where a CA allocates resources to the sub-node caused by misoperation or malicious operation of CA in RPKI. Then some mechanisms may be needed to avoid these scenarios to happen. This document describes these scenarios and related experiments are presented.
    
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-01.txt
 A YANG model to manage the optical optical parameters for in a WDM network
 
 draft-galimbe-ccamp-iv-yang-01.txt
 Date: 31/10/2016
 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-04.txt
 PCEP Extensions for Reporting MPLS-TE LSP Performance Measurements
 
 draft-gandhi-pce-pm-04.txt
 Date: 16/11/2016
 Authors: Rakesh Gandhi, Bin Wen, Colby Barth, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt
In certain networks, network performance data such as packet loss, delay and delay variation (jitter) as well as bandwidth usage is a critical measure for Traffic Engineering (TE). This data provides operators the characteristics of their networks for performance evaluation that is required to ensure the Service Level Agreements (SLAs). Performance Measurement (PM) mechanisms can be employed to monitor these metrics for TE Label Switched Paths (LSPs) in real- time. This document describes Path Computation Element Protocol (PCEP) extensions for reporting such performance measurements to an Active Stateful PCE.
    
draft-gandhishah-teas-assoc-corouted-bidir-03.txt
 Fast Reroute Procedures For Associated Co-routed Bidirectional Label Switched Paths (LSPs)
 
 draft-gandhishah-teas-assoc-corouted-bidir-03.txt
 Date: 14/02/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. In packet transport networks, there are requirements where the reverse unidirectional LSP of an associated bidirectional LSP needs to follow the same path as its forward unidirectional LSP. In addition, the associated bidirectional LSP needs to maintain co-routed-ness even after a failure event in the network. This document describes fast reroute procedures for associated bidirectional LSPs that ensure the traffic flows on a co-routed path after a failure event for single-sided provisioning model.
    
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-geisler-optical-device-discovery-02.txt
 Optical Device Discovery
 
 draft-geisler-optical-device-discovery-02.txt
 Date: 26/08/2016
 Authors: Sarah Geisler, Fred Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces a method for Optical device discovery, by introducing a new multicast group for frames to be captured by optical nodes.
    
draft-gerdes-ace-dtls-authorize-00.txt
 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
 
 draft-gerdes-ace-dtls-authorize-00.txt
 Date: 31/10/2016
 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-00.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-00.txt
 Date: 29/10/2016
 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-gjessing-taps-minset-03.txt
 A Minimal Set of Transport Services for TAPS Systems
 
 draft-gjessing-taps-minset-03.txt
 Date: 31/10/2016
 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 services given in the TAPS document draft- ietf-taps-transports-usage-02.
    
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-01.txt
 TCP over Constrained-Node Networks
 
 draft-gomez-lwig-tcp-constrained-node-networks-01.txt
 Date: 31/10/2016
 Authors: Carles Gomez, Jon Crowcroft
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-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-07.txt
 Egress Peer Engineering using BGP-LU
 
 draft-gredler-idr-bgplu-epe-07.txt
 Date: 06/12/2016
 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-09.txt
 CBOR data definition language (CDDL): a notational convention to express CBOR data structures
 
 draft-greevenbosch-appsawg-cbor-cddl-09.txt
 Date: 21/09/2016
 Authors: Christoph Vigano, Henk Birkholz
 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-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-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-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-guan-dmm-gbu-00.txt
 PMIPv6 Group Binding Update for Internet of Things
 
 draft-guan-dmm-gbu-00.txt
 Date: 31/08/2016
 Authors: Jianfeng Guan, Ilsun You
 Working Group: Individual Submissions (none)
 Formats: txt
Internet of Things (IoT) has been booming with rapid increase of various wearable devices, vehicle embedded devices and so on, and providing the effective mobility management for these IoT devices becomes a challenge due to the different application scenarios as well as the limited energy and bandwidth. Lots of researchers have focused on this topic and proposed several solutions based on the combination of IoT features and traditional mobility management protocols, in which most of these schemes take the IoT devices as mobile networks and adopt the NEtwork MObility (NEMO) and its variants to provide the mobility support. However, these solutions are in face of the heavy signaling cost problem. Since IoT devices are generally combined to realize the complex functions, these devices may have the similar movement behaviors. This document, therefore specifies a PMIPv6-based group binding update method to reduce the singling cost and improve the scalability for these devices.
    
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-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-00.txt
 Extended Experimental Path Attributes for BGP
 
 draft-haas-idr-extended-experimental-00.txt
 Date: 30/10/2016
 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: Individual Submissions (none)
 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-hallambaker-json-web-service-03.txt
 JSON Web Service Binding Version 1.0
 
 draft-hallambaker-json-web-service-03.txt
 Date: 19/09/2016
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The JSON Web Binding (JWB) describes a standardized approach to implementing Web Services. Services are advertised using the DNS SRV and HTTP Well Known Service conventions. Messages may be authenticated or authenticated and encrypted at the message layer in addition to any transport and/or network layer security. Service messages are encoded in JSON using Internet time format for Date-Time fields and Base64urlencoding for binary objects. This document specifies Version 1.0 of JWB which uses HTTP/1.1 for transport. Use of the multiple stream capabilities of HTTP version 2 is outside the scope of this document.
    
draft-hallambaker-mesh-app-ssh-00.txt
 Mathematical Mesh: SSH Application
 
 draft-hallambaker-mesh-app-ssh-00.txt
 Date: 19/09/2016
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The use of the Mathematical Mesh to manage OpenSSH Keys is described.
    
draft-hallambaker-mesh-app-web-00.txt
 Mathematical Mesh: Web Application Binding
 
 draft-hallambaker-mesh-app-web-00.txt
 Date: 19/09/2016
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes the use of the Mesh to store Web application information.
    
draft-hallambaker-mesh-architecture-02.txt
 Mathematical Mesh: Architecture
 
 draft-hallambaker-mesh-architecture-02.txt
 Date: 19/09/2016
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described.
    
draft-hallambaker-mesh-developer-02.txt
 Mathematical Mesh: Developer's Guide
 
 draft-hallambaker-mesh-developer-02.txt
 Date: 19/09/2016
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes how to install and run the Mesh reference code and make use of the reference code in applications. It does not form a part of the Mesh specifications and is not normative.
    
draft-hallambaker-mesh-platform-00.txt
 Mathematical Mesh: Platform Configuration
 
 draft-hallambaker-mesh-platform-00.txt
 Date: 19/09/2016
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes how Mesh profiles are stored for application access on Windows, Linux and OSX platforms.
    
draft-hallambaker-mesh-recrypt-00.txt
 Mesh/Recrypt A New Approach to Messaging
 
 draft-hallambaker-mesh-recrypt-00.txt
 Date: 22/08/2016
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
A messaging infrastructure providing full end-to end security is presented. Unlike existing approaches such as S/MIME and OpenPGP, Mesh/Recrypt uses proxy re-encryption to preserve full end-to-end security with individual user and device keys in situations such as the user having multiple decryption devices and messages being set to mailing lists. This document shows the use of Mesh/Recrypt to address the principle use cases Mesh/Recrypt is designed to address. These include asynchronous messaging such as mail and controlled documents and synchronous messaging applications such as chat, voice and video.
    
draft-hallambaker-mesh-reference-03.txt
 Mathematical Mesh: Reference
 
 draft-hallambaker-mesh-reference-03.txt
 Date: 19/09/2016
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data.
    
draft-hallambaker-udf-04.txt
 Uniform Data Fingerprint (UDF)
 
 draft-hallambaker-udf-04.txt
 Date: 19/09/2016
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists.
    
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-netmod-intf-ext-ppp-yang-01.txt
 Yang Data Model for PPP Protocol
 
 draft-han-netmod-intf-ext-ppp-yang-01.txt
 Date: 23/11/2016
 Authors: Hansance Han, 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-hansbury-sacm-oval-info-model-mapping-03.txt
 OVAL and the SACM Information Model
 
 draft-hansbury-sacm-oval-info-model-mapping-03.txt
 Date: 07/09/2016
 Authors: mhansbury@mitre.org, Daniel Haynes, Juan Gonzalez
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
The OVAL community has spent more than ten years developing and employing the OVAL Language. During this time, the community has made a number of design decisions and learned a number of lessons that should be leveraged as the next-generation endpoint posture assessment standards are formulated. There are also a number of places where portions of the OVAL Language align with the SACM Information Model and could serve as a starting point for related work. Another output of the work executed under the OVAL project is a number of lessons that are applicable to the SACM work. These lessons include a clear separation of data collection and evaluation; a call to focus on ensuring both primary source vendors and third party security experts feel invited to the discussion and are empowered to leverage their unique domain knowledge; and to strive for simplicity and flexibility, where possible. In addition, the OVAL community has a set of clear recommendations with respect to which parts of OVAL should be used by SACM as a means to make best use of the efforts of those that have worked on and supported OVAL over the past ten years. Those recommendations are: o Use the OVAL System Characteristics Model to inform the development of a data model for representing endpoint posture attributes. o Use the OVAL Definitions Model to inform the development of data models for representing evaluation and collection guidance. o Do not use the OVAL Results Model to inform the development of a data model for representing evaluation results. Lastly, this document will discuss the OVAL submission, how it is expected to be used, and how it aligns with the SACM Vulnerability Assessment Scenario.
    
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: Individual Submissions (none)
 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-05.txt
 Design considerations for Metadata Insertion
 
 draft-hardie-privsec-metadata-insertion-05.txt
 Date: 20/01/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 of the end system 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-hardy-pdf-mime-04.txt
 The application/pdf Media Type
 
 draft-hardy-pdf-mime-04.txt
 Date: 04/09/2016
 Authors: Matthew Hardy, Larry Masinter, Dejan Markovic, Duff Johnson, Martin Bailey
 Working Group: Individual Submissions (none)
 Formats: txt pdf xml
The Portable Document Format (PDF) is an ISO standard (ISO 32000-1:2008) defining a final-form document representation language in use for document exchange, including on the Internet, since 1993. This document provides an overview of the PDF format and updates the media type registration of "application/pdf". It obsoletes RFC 3778.
    
draft-hares-i2nsf-capability-data-model-00.txt
 I2NSF Capability YANG Data Model
 
 draft-hares-i2nsf-capability-data-model-00.txt
 Date: 31/10/2016
 Authors: Susan Hares, Robert Moskowitz, Liang Xia, Jin-Yong Kim, Jaehoon Jeong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for capability that enables an I2NSF client to control various network security functions in network security devices via an I2NSF 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-netconf-i2rs-netconf-00.txt
 NETCONF Changes to Support I2RS Protocol
 
 draft-hares-netconf-i2rs-netconf-00.txt
 Date: 15/11/2016
 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-00.txt
 RESTCONF Changes to Support I2RS Protocol
 
 draft-hares-netconf-i2rs-restconf-00.txt
 Date: 15/11/2016
 Authors: Susan Hares, amit.dass@ericsson.com
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document describes a RETCONF additions 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-netmod-i2rs-yang-02.txt
 Yang for I2RS Protocol
 
 draft-hares-netmod-i2rs-yang-02.txt
 Date: 16/11/2016
 Authors: Susan Hares, amit.dass@ericsson.com
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document requests one yang model addition that will support ephemeral state and provides notes for the implementers who wish to implement ephemeral state for the I2RS Protocol. The purpose of this document is to provide implementers of ephemeral state with background and open issues that they should consider when implementing ephemeral state that satifies the I2RS protocol.
    
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-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-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-01.txt
 The Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-01.txt
 Date: 17/10/2016
 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-01.txt
 Endpoint Compliance Profile
 
 draft-haynes-sacm-ecp-01.txt
 Date: 07/09/2016
 Authors: Daniel Haynes, Jessica Fitzgerald-McKay, Lisa Lorenzin
 Working Group: Security Automation and Continuous Monitoring (sacm)
 Formats: xml pdf txt
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-haynes-sacm-oval-definitions-model-01.txt
 OVAL(R) Definitions Model
 
 draft-haynes-sacm-oval-definitions-model-01.txt
 Date: 07/09/2016
 Authors: Michael Cokus, Daniel Haynes, David Rothenberg, Juan Gonzalez
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document specifies Version 5.11.1 of the OVAL Definitions Model which defines an extensible framework for making assertions about a system that are based upon a collection of logical statements. Each logical statement defines a specific machine state by identifying the data set on the system to examine and describing the expected state of that system data.
    
draft-haynes-sacm-oval-processing-model-01.txt
 OVAL(R) Processing Model
 
 draft-haynes-sacm-oval-processing-model-01.txt
 Date: 07/09/2016
 Authors: Michael Cokus, Daniel Haynes, David Rothenberg, Juan Gonzalez
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document defines Version 5.11.1 of the OVAL processing model which describes, in detail, how the major components of the OVAL Language Data Model are used to produce OVAL Definitions, OVAL System Characteristics, and OVAL Results.
    
draft-haynes-sacm-oval-variables-model-01.txt
 OVAL(R) Variables Model
 
 draft-haynes-sacm-oval-variables-model-01.txt
 Date: 07/09/2016
 Authors: Michael Cokus, Daniel Haynes, David Rothenberg, Juan Gonzalez
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document specifies Version 5.11.1 of the OVAL Variables Model which contains constructs that allow for the specification of values for external_variables defined in content that was created using the OVAL Definitions Model. The OVAL Variables Model serves as a useful mechanism for parameterizing content based on the OVAL Definitions Model.
    
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-03.txt
 Identifier-locator addressing for IPv6
 
 draft-herbert-nvo3-ila-03.txt
 Date: 27/10/2016
 Authors: Tom Herbert
 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-01.txt
 Transmission of IPv6 Packets over Ethernet Networks
 
 draft-hinden-6man-rfc2464bis-01.txt
 Date: 09/01/2017
 Authors: Matt Crawford, Robert Hinden
 Working Group: Individual Submissions (none)
 Formats: txt
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-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-10.txt
 Representing DNS Messages in JSON
 
 draft-hoffman-dns-in-json-10.txt
 Date: 31/10/2016
 Authors: Paul Hoffman
 Working Group: Individual Submissions (none)
 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 standardized 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-holmberg-dispatch-mcptt-rp-namespace-05.txt
 IANA Registration of New Session Initiation Protocol (SIP) Resource- Priority Namespace for Mission Critical Push To Talk service
 
 draft-holmberg-dispatch-mcptt-rp-namespace-05.txt
 Date: 19/01/2017
 Authors: Christer Holmberg, Joergen Axell
 Working Group: Applications and Real-Time Area (art)
 Formats: txt xml
This document creates an additional Session Initiation Protocol (SIP) Resource-Priority namespace to meet the requirements of the 3GPP defined Mission Critical Push To Talk, and places this namespace in the IANA registry.
    
draft-homenet-redact-00.txt
 Redacting .home from HNCP
 
 draft-homenet-redact-00.txt
 Date: 26/08/2016
 Authors: Ted Lemon
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document updates the Home Networking Control Protocol, eliminating the recommendation for a default top-level name for local name resolution.
    
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-housley-cms-mts-hash-sig-05.txt
 Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the Cryptographic Message Syntax (CMS)
 
 draft-housley-cms-mts-hash-sig-05.txt
 Date: 19/12/2016
 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-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-howard-ipv6-ietf-00.txt
 IETF: End Work on IPv4
 
 draft-howard-ipv6-ietf-00.txt
 Date: 17/10/2016
 Authors: Lee Howard
 Working Group: Individual Submissions (none)
 Formats: txt xml
The IETF will stop working on IPv4, except where needed to mitigate documented security issues, to facilitate the transition to IPv6, or to enable IPv4 decommissioning.
    
draft-hr-idr-rfc5575bis-03.txt
 Dissemination of Flow Specification Rules
 
 draft-hr-idr-rfc5575bis-03.txt
 Date: 14/02/2017
 Authors: Susan Hares, Robert Raszuk, Danny McPherson, Christoph Loibl, Martin Bacher
 Working Group: Inter-Domain Routing (idr)
 Formats: txt xml pdf
This document updates RFC5575 which defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic flow specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix. This draft specifies IPv4 traffic flow specifications via a BGP NLRI which carries traffic flow specification filter, and an Extended community value which encodes actions a routing system can take if the packet matches the traffic flow filters. The flow filters and the actions are processed in a fixed order. Other drafts specify IPv6, MPLS addresses, L2VPN addresses, and NV03 encapsulation of IP addresses. This document updates RFC5575 to correct unclear specifications in the flow filters and to provide rules for actions which interfere (e.g. redirection of traffic and flow filtering). Applications which use the bgp flow specification are: 1) application which automate of inter-domain coordination of traffic filtering, such as what is required in order to mitigate (distributed) denial- of-service attacks; 2) application which control traffic filtering in the context of a BGP/MPLS VPN service, and 3) applications with centralized control of traffic in a SDN or NFV context. Some of deployments of these three applications can be handled by the strict ordering of the BGP NLRI traffic flow filters, and the strict actions encoded in the Extended Community Flow Specification actions.
    
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-flexe-framework-00.txt
 Framework and Requirements for GMPLS-based Control of Flexible Ethernet Network
 
 draft-huang-flexe-framework-00.txt
 Date: 31/08/2016
 Authors: Jing Huang, Qiwen Zhong
 Working Group: Individual Submissions (none)
 Formats: xml txt
This memo provides some background information of Flexible Ethernet (FlexE), and explain some terminologies and use cases, further derives the requirements to the GMPLS based control plane.
    
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-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-00.txt
 SET Token Distribution and Subscription Management Profile
 
 draft-hunt-secevent-distribution-00.txt
 Date: 07/02/2017
 Authors: Phil Hunt, Marius Scurtescu, Morteza Ansari
 Working Group: Individual Submissions (none)
 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-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-01.txt
 NSF-triggered Traffic Steering in I2NSF Framework
 
 draft-hyun-i2nsf-nsf-triggered-steering-01.txt
 Date: 13/11/2016
 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 framework for Interface to Network Security Functions (I2NSF) which enables traffic steering between Network Security Functions (NSFs) for security policy enforcement. Such traffic steering enables composite inspection of network traffic by steering the traffic through multiple types of NSFs 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-im-00.txt
 Registration Interface Information Model
 
 draft-hyun-i2nsf-registration-interface-im-00.txt
 Date: 31/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 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 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-carisreport-02.txt
 Coordinating Attack Response at Internet Scale (CARIS) Workshop Report
 
 draft-iab-carisreport-02.txt
 Date: 05/01/2017
 Authors: Kathleen Moriarty, Mat Ford
 Working Group: Internet Architecture Board (iab)
 Formats: xml txt
This report documents the discussions and conclusions from the Coordinating Attack Response at Internet Scale (CARIS) workshop that took place in Berlin, Germany on 18 June 2015. The purpose of this workshop was to improve mutual awareness, understanding, and coordination among the diverse participating organizations and their representatives. Note that this document is a report on the proceedings of the workshop. The views and positions documented in this report are those of the workshop participants and do not necessarily reflect IAB views and positions.
    
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-05.txt
 Out With the Old and In With the New: Planning for Protocol Transitions
 
 draft-iab-protocol-transitions-05.txt
 Date: 04/01/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 from one protocol or technology to another, throughout the protocol stack. 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-03.txt
 Digital Preservation Considerations for the RFC Series
 
 draft-iab-rfc-preservation-03.txt
 Date: 17/01/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-rzerc-02.txt
 IETF ICANN Root Zone Evolution Review Committee Appointment Procedures
 
 draft-iab-rzerc-02.txt
 Date: 10/02/2017
 Authors: Cindy Morgan
 Working Group: Internet Architecture Board (iab)
 Formats: txt xml
This memo outlines the process by which the IETF makes an appointment to the ICANN Root Zone Evolution Review Committee (RZERC).
    
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-01.txt
 Extension to BGP's Route Refresh Message
 
 draft-idr-bgp-route-refresh-options-01.txt
 Date: 14/11/2016
 Authors: Keyur Patel, Aamod Vyavaharkar, Niloofar Fazlollahi, Tony Przygienda
 Working Group: Individual Submissions (none)
 Formats: txt
[RFC2918] defines a route refresh capability to be exchanged between BGP speakers. BGP speakers that support this capability are advertising that they can resend the entire BGP Adj-RIB-Out on receipt of a refresh request. By supporting this capability, BGP speakers are more flexible in applying any inbound routing policy changes as they no longer have to store received routes in their unchanged form or reset the session when an inbound routing policy change occurs. The route refresh capability is advertised per AFI, SAFI combination. There are newer AFI, SAFI types that have been introduced to BGP that support a variety of route types (e.g. IPv4/MVPN, L2VPN/EVPN). Currently, there is no way to request a subset of routes in a Route Refresh message for a given AFI, SAFI. This draft defines route refresh capability extensions that help BGP speakers to request a subset of routes for a given address family. This is expected to reduce the amount of update traffic being generated by route refresh requests as well as lessen the burden on the router servicing such requests.
    
draft-ietf-6lo-6lobac-06.txt
 Transmission of IPv6 over MS/TP Networks
 
 draft-ietf-6lo-6lobac-06.txt
 Date: 31/10/2016
 Authors: Kerry Lynn, Jerry Martocci, Carl Neilson, Stuart Donaldson
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
Master-Slave/Token-Passing (MS/TP) is a medium access control method for the RS-485 physical layer, which is used extensively 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-00.txt
 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
 
 draft-ietf-6lo-blemesh-00.txt
 Date: 13/11/2016
 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-05.txt
 Transmission of IPv6 Packets over Near Field Communication
 
 draft-ietf-6lo-nfc-05.txt
 Date: 14/10/2016
 Authors: Younghwan Choi, Joo-Sang Youn, Yong-Geun Hong
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt
Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LowPAN techniques.
    
draft-ietf-6lo-privacy-considerations-04.txt
 Privacy Considerations for IPv6 Adaptation Layer Mechanisms
 
 draft-ietf-6lo-privacy-considerations-04.txt
 Date: 31/10/2016
 Authors: Dave Thaler
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt
This document discusses how a number of privacy threats apply to technologies designed for IPv6 over various link layer protocols, and provides advice to protocol designers on how to address such threats in adaptation layer specifications for IPv6 over such links.
    
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-00.txt
 IPv6 over Constrained Node Networks(6lo) Applicability & Use cases
 
 draft-ietf-6lo-use-cases-00.txt
 Date: 02/12/2016
 Authors: Yong-Geun Hong, Carles Gomez
 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, 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-default-iids-16.txt
 Recommendation on Stable IPv6 Interface Identifiers
 
 draft-ietf-6man-default-iids-16.txt
 Date: 28/09/2016
 Authors: Fernando Gont, Alissa Cooper, Dave Thaler, Shucheng LIU
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
This document changes the recommended default IID generation scheme for cases where SLAAC is used to generate a stable IPv6 address. It recommends using the mechanism specified in RFC7217 in such cases, and recommends against embedding stable link-layer addresses in IPv6 Interface Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491, RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338, RFC4391, RFC5072, and RFC5121. This document does not change any existing recommendations concerning the use of temporary addresses as specified in RFC 4941.
    
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-rdnss-rfc6106bis-16.txt
 IPv6 Router Advertisement Options for DNS Configuration
 
 draft-ietf-6man-rdnss-rfc6106bis-16.txt
 Date: 08/02/2017
 Authors: Jaehoon Jeong, Soohong Park, Luc Beloeil, Syam Madanapalli
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
This document specifies IPv6 Router Advertisement (RA) options (called DNS RA options) to allow IPv6 routers to advertise a list of DNS recursive server addresses and a DNS Search List to IPv6 hosts. This document, which obsoletes RFC 6106, defines a higher default value of the lifetime of the DNS RA options to reduce the likelihood of expiry of the options on links with a relatively high rate of packet loss.
    
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-05.txt
 IPv6 Segment Routing Header (SRH)
 
 draft-ietf-6man-segment-routing-header-05.txt
 Date: 01/02/2017
 Authors: Stefano Previdi, Clarence Filsfils, Brian Field, Ida Leung, J. Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun
 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-03.txt
 6top Protocol (6P)
 
 draft-ietf-6tisch-6top-protocol-03.txt
 Date: 31/10/2016
 Authors: Qin Wang, Xavier Vilajosana
 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 in a 6TiSCH network to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer of the IEEE802.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-02.txt
 6TiSCH 6top Scheduling Function Zero (SF0)
 
 draft-ietf-6tisch-6top-sf0-02.txt
 Date: 31/10/2016
 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-00.txt
 6tisch Secure Join protocol
 
 draft-ietf-6tisch-dtsecurity-secure-join-00.txt
 Date: 15/12/2016
 Authors: Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
Charter: The WG will continue working on securing the join process and making that fit within the constraints of high latency, low throughput and small frame sizes that characterize IEEE802.15.4 TSCH.
    
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-01.txt
 Minimal Security Framework for 6TiSCH
 
 draft-ietf-6tisch-minimal-security-01.txt
 Date: 02/02/2017
 Authors: Malisa Vucinic, Jonathan Simon, Kris Pister
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This draft describes the minimal mechanisms required to support secure initial configuration in a device being added to a 6TiSCH network. The goal of this configuration is to set link-layer keys, and to establish a secure session between each joining node and the JCE who may use that to further configure the joining device. 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-04.txt
 An architecture for authorization in constrained environments
 
 draft-ietf-ace-actors-04.txt
 Date: 03/09/2016
 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-02.txt
 CBOR Web Token (CWT)
 
 draft-ietf-ace-cbor-web-token-02.txt
 Date: 13/01/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-05.txt
 Authentication and Authorization for Constrained Environments (ACE)
 
 draft-ietf-ace-oauth-authz-05.txt
 Date: 06/02/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-05.txt
 Automatic Certificate Management Environment (ACME)
 
 draft-ietf-acme-acme-05.txt
 Date: 03/02/2017
 Authors: Richard Barnes, Jacob Hoffman-Andrews, James Kasten
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
Certificates in the Web's X.509 PKI (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 certificate 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-03.txt
 ALTO Incremental Updates Using Server-Sent Events (SSE)
 
 draft-ietf-alto-incr-update-sse-03.txt
 Date: 13/09/2016
 Authors: Wendy Roome, Y. Yang
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: xml pdf 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-04.txt
 Multi-Cost ALTO
 
 draft-ietf-alto-multi-cost-04.txt
 Date: 15/09/2016
 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-00.txt
 ALTO Performance Cost Metrics
 
 draft-ietf-alto-performance-metrics-00.txt
 Date: 07/09/2016
 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. Future extensions to ALTO may also use Cost Metric. Different applications may benefit from different Cost Metrics. For example, a Resource Consumer may prefer Resource Providers that have low delay to the Resource Consumer. However the base ALTO protocol [ALTO] has documented only a single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]). In this document, we 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 tool. We currently document 11 new Performance Metric to measure network delay, jitter, packet loss, hop count, and bandwidth. The metrics documented in this document provide a relatively comprehensive set of Cost Metrics for ALTO and allow applications to determine "where" to connect based on end to end network performance criteria. Additional Cost Metrics such as financial cost metrics may be documented in other documents.
    
draft-ietf-anima-autonomic-control-plane-05.txt
 An Autonomic Control Plane
 
 draft-ietf-anima-autonomic-control-plane-05.txt
 Date: 12/01/2017
 Authors: Michael Behringer, Toerless Eckert, Steinthor Bjarnason
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic 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-04.txt
 Bootstrapping Remote Secure Key Infrastructures (BRSKI)
 
 draft-ietf-anima-bootstrapping-keyinfra-04.txt
 Date: 31/10/2016
 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 authorized service on the Internet. 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-09.txt
 A Generic Autonomic Signaling Protocol (GRASP)
 
 draft-ietf-anima-grasp-09.txt
 Date: 16/12/2016
 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 devices and autonomic service agents to dynamically discover peers, to synchronize state with them, and to negotiate parameter settings mutually 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-02.txt
 Autonomic IPv6 Edge Prefix Management in Large-scale Networks
 
 draft-ietf-anima-prefix-management-02.txt
 Date: 09/01/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-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-00.txt
 Voucher and Voucher Revocation Profiles for Bootstrapping Protocols
 
 draft-ietf-anima-voucher-00.txt
 Date: 04/01/2017
 Authors: Kent Watsen, Michael Richardson, Max Pritikin, Toerless Eckert
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
This memo defines the two artifacts "voucher" and "voucher- revocation", which are YANG-defined structures that have been signed by a TBD algorithm. The voucher artifact is generated by the device's manufacture or delegate. The voucher's purpose is to securely assign one or more devices to an owner. The voucher informs each device which entity it should consider to be its owner. The voucher revocation artifact is used by the manufacturer or delegate (i.e. the issuer of the voucher) to revoke vouchers, if ever necessary. The voucher revocation format defined herein supports both issuer-wide and voucher-specific constructs, enabling usage flexibility. For both artifacts, this memo only defines the artifact, leaving it to future work to describe specialized protocols for accessing them.
    
draft-ietf-appsawg-mdn-3798bis-16.txt
 Message Disposition Notification
 
 draft-ietf-appsawg-mdn-3798bis-16.txt
 Date: 01/12/2016
 Authors: Tony Hansen, Alexey Melnikov
 Working Group: ART Area General Applications Working Group (appsawg)
 Formats: txt xml
This memo defines a MIME content-type that may be used by a mail user agent (MUA) or electronic mail gateway to report the disposition of a message after it has been successfully delivered to a recipient. This content-type is intended to be machine-processable. Additional message header fields are also defined to permit Message Disposition Notifications (MDNs) to be requested by the sender of a message. The purpose is to extend Internet Mail to support functionality often found in other messaging systems, such as X.400 and the proprietary "LAN-based" systems, and often referred to as "read receipts," "acknowledgements", or "receipt notifications." The intention is to do this while respecting privacy concerns, which have often been expressed when such functions have been discussed in the past. Because many messages are sent between the Internet and other messaging systems (such as X.400 or the proprietary "LAN-based" systems), the MDN protocol is designed to be useful in a multi- protocol messaging environment. To this end, the protocol described in this memo provides for the carriage of "foreign" addresses, in addition to those normally used in Internet Mail. Additional attributes may also be defined to support "tunneling" of foreign notifications through Internet Mail. This document obsoletes RFC 3798, moving it to Internet Standard. It also updates RFC 2046 (message/partial Media Type handling) and RFC 3461 (Original-Recipient header field generation requirement).
    
draft-ietf-aqm-codel-06.txt
 Controlled Delay Active Queue Management
 
 draft-ietf-aqm-codel-06.txt
 Date: 22/12/2016
 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-docsis-pie-02.txt
 A PIE-Based AQM for DOCSIS Cable Modems
 
 draft-ietf-aqm-docsis-pie-02.txt
 Date: 15/02/2016
 Authors: Greg White, Rong Pan
 Working Group: Active Queue Management and Packet Scheduling (aqm)
 Formats: txt xml
Cable modems based on the DOCSIS(R) specification provide broadband Internet access to over one hundred million users worldwide. In some cases, the cable modem connection is the bottleneck (lowest speed) link between the customer and the Internet. As a result, the impact of buffering and bufferbloat in the cable modem can have a significant effect on user experience. The CableLabs DOCSIS 3.1 specification introduces requirements for cable modems to support an Active Queue Management (AQM) algorithm that is intended to alleviate the impact that buffering has on latency sensitive traffic, while preserving bulk throughput performance. In addition, the CableLabs DOCSIS 3.0 specifications have also been amended to contain similar requirements. This document describes the requirements on Active Queue Management that apply to DOCSIS equipment, including a description of the "DOCSIS-PIE" algorithm that is required on DOCSIS 3.1 cable modems.
    
draft-ietf-aqm-ecn-benefits-08.txt
 The Benefits of using Explicit Congestion Notification (ECN)
 
 draft-ietf-aqm-ecn-benefits-08.txt
 Date: 23/11/2015
 Authors: Gorry Fairhurst, Michael Welzl
 Working Group: Active Queue Management and Packet Scheduling (aqm)
 Formats: txt xml
The goal of this document is to describe the potential benefits when applications use a transport that enables Explicit Congestion Notification (ECN). The document outlines the principal gains in terms of increased throughput, reduced delay and other benefits when ECN is used over a network path that includes equipment that supports Congestion Experienced (CE) marking. It also discusses challenges for successful deployment of ECN. It does not propose new algorithms to use ECN, nor does it describe the details of implementation of ECN in endpoint devices (Internet hosts), routers or other network devices.
    
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-aqm-pie-10.txt
 PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem
 
 draft-ietf-aqm-pie-10.txt
 Date: 26/09/2016
 Authors: Rong Pan, Preethi Natarajan, Fred Baker, Greg White
 Working Group: Active Queue Management and Packet Scheduling (aqm)
 Formats: txt
Bufferbloat is a phenomenon in which excess buffers in the network cause high latency and latency variation. As more and more interactive applications (e.g. voice over IP, real time video streaming and financial transactions) run in the Internet, high latency and latency variation degrade application performance. There is a pressing need to design intelligent queue management schemes that can control latency and latency variation, and hence provide desirable quality of service to users. This document presents a lightweight active queue management design, called PIE (Proportional Integral controller Enhanced), that can effectively control the average queueing latency to a target value. Simulation results, theoretical analysis and Linux testbed results have shown that PIE can ensure low latency and achieve high link utilization under various congestion situations. The design does not require per-packet timestamps, so it incurs very little overhead and is simple enough to implement in both hardware and software.
    
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-06.txt
 A General Mechanism for RTP Header Extensions
 
 draft-ietf-avtcore-rfc5285-bis-06.txt
 Date: 15/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-circuit-breakers-18.txt
 Multimedia Congestion Control: Circuit Breakers for Unicast RTP Sessions
 
 draft-ietf-avtcore-rtp-circuit-breakers-18.txt
 Date: 18/08/2016
 Authors: Colin Perkins, Varun Singh
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt
The Real-time Transport Protocol (RTP) is widely used in telephony, video conferencing, and telepresence applications. Such applications are often run on best-effort UDP/IP networks. If congestion control is not implemented in these applications, then network congestion can lead to uncontrolled packet loss, and a resulting deterioration of the user's multimedia experience. The congestion control algorithm acts as a safety measure, stopping RTP flows from using excessive resources, and protecting the network from overload. At the time of this writing, however, while there are several proprietary solutions, there is no standard algorithm for congestion control of interactive RTP flows. This document does not propose a congestion control algorithm. It instead defines a minimal set of RTP circuit breakers: conditions under which an RTP sender needs to stop transmitting media data, to protect the network from excessive congestion. It is expected that, in the absence of long-lived excessive congestion, RTP applications running on best-effort IP networks will be able to operate without triggering these circuit breakers. To avoid triggering the RTP circuit breaker, any standards-track congestion control algorithms defined for RTP will need to operate within the envelope set by these RTP circuit breaker algorithms.
    
draft-ietf-avtcore-rtp-multi-stream-11.txt
 Sending Multiple RTP Streams in a Single RTP Session
 
 draft-ietf-avtcore-rtp-multi-stream-11.txt
 Date: 11/12/2015
 Authors: Jonathan Lennox, Magnus Westerlund, Qin Wu, Colin Perkins
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt xml
This memo expands and clarifies the behaviour of Real-time Transport Protocol (RTP) endpoints that use multiple synchronization sources (SSRCs). This occurs, for example, when an endpoint sends multiple RTP streams in a single RTP session. This memo updates RFC 3550 with regards to handling multiple SSRCs per endpoint in RTP sessions, with a particular focus on RTCP behaviour. It also updates RFC 4585 to update and clarify the calculation of the timeout of SSRCs and the inclusion of feedback messages.
    
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-avpf-ccm-layered-04.txt
 Using Codec Control Messages in the RTP Audio-Visual Profile with Feedback with Layered Codecs
 
 draft-ietf-avtext-avpf-ccm-layered-04.txt
 Date: 10/01/2017
 Authors: Stephan Wenger, Jonathan Lennox, Bo Burman, Magnus Westerlund
 Working Group: Audio/Video Transport Extensions (avtext)
 Formats: xml txt
This document updates RFC5104 by fixing a shortcoming in the specification language of the Codec Control Message Full Intra Request (FIR) as defined in RFC5104 when using it with layered codecs. In particular, a Decoder Refresh Point needs to be sent by a media sender when a FIR is received on any layer of the layered bitstream, regardless on whether those layers are being sent in a single or in multiple RTP flows. The other payload-specific feedback messages defined in RFC 5104 and RFC 4585 as updated by RFC 5506 have also been analyzed, and no corresponding shortcomings have been found.
    
draft-ietf-avtext-framemarking-03.txt
 Frame Marking RTP Header Extension
 
 draft-ietf-avtext-framemarking-03.txt
 Date: 31/10/2016
 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 encryption 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-dci-evpn-overlay-04.txt
 Interconnect Solution for EVPN Overlay networks
 
 draft-ietf-bess-dci-evpn-overlay-04.txt
 Date: 08/09/2016
 Authors: Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Senad Palislamovic, Ali Sajassi, Dennis Cai
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes how Network Virtualization Overlay networks (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running EVPN and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS or EVPN/PBB-EVPN, and proposes a solution for the interworking between both.
    
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-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-07.txt
 A Network Virtualization Overlay Solution using EVPN
 
 draft-ietf-bess-evpn-overlay-07.txt
 Date: 30/11/2016
 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) [RFC7432] 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-03.txt
 Usage and applicability of BGP MPLS based Ethernet VPN
 
 draft-ietf-bess-evpn-usage-03.txt
 Date: 19/09/2016
 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-08.txt
 VPWS support in EVPN
 
 draft-ietf-bess-evpn-vpws-08.txt
 Date: 07/02/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 PW signaling, and provides fast protection convergence upon node or link failure.
    
draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt
 L2L3 VPN Multicast MIB
 
 draft-ietf-bess-l2l3-vpn-mcast-mib-05.txt
 Date: 01/12/2016
 Authors: Zhaohui Zhang, Hiroshi Tsunoda
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This memo defines a portion of the Management Information Base 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 L2 and L3 VPN Multicast.
    
draft-ietf-bess-l2vpn-yang-02.txt
 YANG Data Model for MPLS-based L2VPN
 
 draft-ietf-bess-l2vpn-yang-02.txt
 Date: 31/10/2016
 Authors: Himanshu Shah, Patrice Brissette, I. Chen, Iftekhar Hussain, Bin Wen
 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-l3vpn-yang-00.txt
 Yang Data Model for BGP/MPLS L3 VPNs
 
 draft-ietf-bess-l3vpn-yang-00.txt
 Date: 13/09/2016
 Authors: Dhanendra Jain, Keyur Patel, Patrice Brissette, Zhenbin Li, Shunwan Zhuang, Xufeng Liu, Jeffrey Haas, Santosh Esale, Bin Wen
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage BGP Layer 3 VPNs.
    
draft-ietf-bess-mvpn-expl-track-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-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-rfc4583bis-16.txt
 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
 
 draft-ietf-bfcpbis-rfc4583bis-16.txt
 Date: 21/09/2016
 Authors: Gonzalo Camarillo, Tom Kristensen, Paul Jones
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
This document specifies how to describe Binary Floor Control Protocol (BFCP) streams in Session Description Protocol (SDP) descriptions. User agents using the offer/answer model to establish BFCP streams use this format in their offers and answers. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 14.
    
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-04.txt
 Yang Data Model for Bidirectional Forwarding Detection (BFD)
 
 draft-ietf-bfd-yang-04.txt
 Date: 08/01/2017
 Authors: Lianshu Zheng, Reshad Rahman, 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-03.txt
 BIER support via ISIS
 
 draft-ietf-bier-isis-extensions-03.txt
 Date: 22/09/2016
 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-04.txt
 OSPF Extensions for BIER
 
 draft-ietf-bier-ospf-bier-extensions-04.txt
 Date: 22/09/2016
 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-04.txt
 Benchmarking The Neighbor Discovery Protocol
 
 draft-ietf-bmwg-ipv6-nd-04.txt
 Date: 17/11/2016
 Authors: William Cerveny, Ron Bonica, Reji Thomas
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
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-03.txt
 Benchmarking Methodology for IPv6 Transition Technologies
 
 draft-ietf-bmwg-ipv6-tran-tech-benchmarking-03.txt
 Date: 27/10/2016
 Authors: Marius Georgescu, Liviu Pislaru, Gabor Lencse
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
There are benchmarking methodologies addressing the performance of network interconnect devices that are IPv4- or IPv6-capable, but the IPv6 transition technologies are outside of their scope. This document provides complementary guidelines for evaluating the performance of IPv6 transition technologies. More specifically, this document targets IPv6 transition technologies that employ encapsulation or translation mechanisms, as dual-stack nodes can be very well tested using the recommendations of RFC2544 and RFC5180. The methodology also includes a tentative metric for benchmarking load scalability.
    
draft-ietf-bmwg-sdn-controller-benchmark-meth-03.txt
 Benchmarking Methodology for SDN Controller Performance
 
 draft-ietf-bmwg-sdn-controller-benchmark-meth-03.txt
 Date: 07/01/2017
 Authors: Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
This document defines the methodologies for benchmarking control plane performance of SDN controllers. Terminology related to benchmarking SDN controllers is described in the companion terminology document. SDN controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors have taken the approach of considering an SDN controller as a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. The intent of this document is to provide a standard mechanism to measure the performance of all controller implementations.
    
draft-ietf-bmwg-sdn-controller-benchmark-term-03.txt
 Terminology for Benchmarking SDN Controller Performance
 
 draft-ietf-bmwg-sdn-controller-benchmark-term-03.txt
 Date: 07/01/2017
 Authors: Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
This document defines terminology for benchmarking an SDN controller's control plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN controllers. The terms provided in this document help to benchmark SDN controller's performance independent of the controller's supported protocols and/or network services. A mechanism for benchmarking the performance of SDN controllers is defined in the companion methodology document. These two documents provide a standard mechanism to measure and evaluate the performance of various controller implementations.
    
draft-ietf-bmwg-virtual-net-04.txt
 Considerations for Benchmarking Virtual Network Functions and Their Infrastructure
 
 draft-ietf-bmwg-virtual-net-04.txt
 Date: 14/08/2016
 Authors: Al Morton
 Working Group: Benchmarking Methodology (bmwg)
 Formats: xml txt
Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. This memo investigates additional considerations when network functions are virtualized and performed in general purpose hardware. See the new version history section for updates.
    
draft-ietf-bmwg-vswitch-opnfv-01.txt
 Benchmarking Virtual Switches in OPNFV
 
 draft-ietf-bmwg-vswitch-opnfv-01.txt
 Date: 14/10/2016
 Authors: Maryam Tahhan, Billy O'Mahony, Al Morton
 Working Group: Benchmarking Methodology (bmwg)
 Formats: xml txt
This memo describes the progress of the Open Platform for NFV (OPNFV) project on virtual switch performance "VSWITCHPERF". This project intends to build on the current and completed work of the Benchmarking Methodology Working Group in IETF, by referencing existing literature. The Benchmarking Methodology Working Group has traditionally conducted laboratory characterization of dedicated physical implementations of internetworking functions. Therefore, this memo begins to describe the additional considerations when virtual switches are implemented in general-purpose hardware. The expanded tests and benchmarks are also influenced by the OPNFV mission to support virtualization of the "telco" infrastructure.
    
draft-ietf-calext-caldav-attachments-00.txt
 CalDAV Managed Attachments
 
 draft-ietf-calext-caldav-attachments-00.txt
 Date: 17/10/2016
 Authors: Cyrus Daboo, Arnaud Quillaud, Kenneth Murchison
 Working Group: Calendaring Extensions (calext)
 Formats: xml txt
This specification defines an extension to the calendar access protocol (CalDAV) to allow attachments associated with iCalendar data, to be stored and managed on the server.
    
draft-ietf-calext-eventpub-extensions-00.txt
 Event Publishing Extensions to iCalendar
 
 draft-ietf-calext-eventpub-extensions-00.txt
 Date: 25/08/2016
 Authors: Michael Douglass
 Working Group: Calendaring Extensions (calext)
 Formats: xml pdf txt
This specification introduces a number of new iCalendar properties which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar (RFC 5545) to allow for data that is directly pertinent to an event or task to be included with the calendar data.
    
draft-ietf-calext-ical-relations-02.txt
 Support for iCalendar Relationships
 
 draft-ietf-calext-ical-relations-02.txt
 Date: 10/02/2017
 Authors: Michael Douglass
 Working Group: Calendaring Extensions (calext)
 Formats: pdf xml txt
This specification updates RELATED-TO defined in [RFC5545] and introduces new iCalendar properties LINK, STRUCTURED-CATEGORY and REFID to allow better linking and grouping of iCalendar components and related data.
    
draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-03.txt
 A framework for Management and Control of DWDM optical interface parameters
 
 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-03.txt
 Date: 31/10/2016
 Authors: Ruediger Kunze, Gert Grammel, Dieter Beller, Gabriele Galimberti
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
To ensure an efficient data transport, meeting the requirements requested by today's IP-services the control and management of DWDM interfaces is a precondition for enhanced multilayer networking and for an further automation of network provisioning and operation. This document describes use cases and requirements for the control and management of optical interfaces parameters according to different types of single channel DWDM interfaces. The focus is on automating the network provisioning process irrespective on how it is triggered i.e. by EMS, NMS or GMPLS. This document covers management as well as control plane considerations in different management cases of a single channel DWDM interface. The purpose is to identify the necessary information elements and processes to be used by control or management systems for further processing.
    
draft-ietf-ccamp-flexible-grid-ospf-ext-09.txt
 GMPLS OSPF-TE Extensions in support of Flexi-grid DWDM networks
 
 draft-ietf-ccamp-flexible-grid-ospf-ext-09.txt
 Date: 16/02/2017
 Authors: Xian Zhang, zhenghaomian@huawei.com, Ramon Casellas, Oscar de Dios, Daniele Ceccarelli
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
The International Telecommunication Union Telecommunication Standardization Sector (ITU-T) has extended its Recommendations G.694.1 and G.872 to include a new Dense Wavelength Division Multiplexing (DWDM) grid by defining a set of nominal central frequencies, channel spacings, and the concept of the "frequency slot". Corresponding techniques for data-plane connections are known as flexi-grid. Based on the characteristics of flexi-grid defined in G.694.1, RFC 7698 and 7699, this document describes the OSPF-TE extensions in support of GMPLS control of networks that include devices that use the new flexible optical grid.
    
draft-ietf-ccamp-grid-property-lmp-04.txt
 Link Management Protocol Extensions for Grid Property Negotiation
 
 draft-ietf-ccamp-grid-property-lmp-04.txt
 Date: 22/09/2016
 Authors: Qilei Wang, Guoying Zhang, Yao Li, Ramon Casellas, Yu Wang
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
ITU-T [G.694.1] introduces the flexible-grid DWDM technique, which provides a new tool that operators can implement to provide a higher degree of network optimization than is possible with fixed-grid systems. This document describes the extensions to the Link Management Protocol (LMP) to negotiate link grid property between the adjacent DWDM nodes before the link is brought up.
    
draft-ietf-ccamp-microwave-framework-00.txt
 A framework for Management and Control of microwave and millimeter wave interface parameters
 
 draft-ietf-ccamp-microwave-framework-00.txt
 Date: 18/12/2016
 Authors: Jonas Ahlberg, Luis Contreras, Min Ye, Marko Vaupotic, Jeff Tantsura, Koji Kawada, Xi Li, Ippei Akiyoshi, Carlos Bernardos
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
To ensure an efficient data transport, meeting the requirements requested by today's transport services, the unification of control and management of microwave and millimeter wave radio link interfaces is a precondition for seamless multilayer networking and automated network wide provisioning and operation. This document describes the required characteristics and use cases for control and management of radio link interface parameters using a YANG Data Model. It focuses on the benefits of a standardized management model that is aligned with how other packet technology interfaces in a microwave/millimeter wave node are modeled, the need to support core parameters and at the same time allow for optional product/feature specific parameters supporting new, unique innovative features until they have become mature enough to be included in the standardized model. The purpose is to create a framework for identification of the necessary information elements and definition of a YANG Data Model for control and management of the radio link interfaces in a microwave/millimeter wave node.
    
draft-ietf-ccamp-ospf-availability-extension-09.txt
 OSPF-TE Link Availability Extension for Links with Variable Discrete Bandwidth
 
 draft-ietf-ccamp-ospf-availability-extension-09.txt
 Date: 15/02/2017
 Authors: Hao Long, Min Ye, Gregory Mirsky, Alessandro D'Alessandro, Himanshu Shah
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
A network may contain links with variable discrete bandwidth, e.g., copper, radio, etc. The bandwidth of such links may change discretely in reaction to changing external environment. Availability is typically used for describing such links during network planning. This document defines a new type of the Generalized Switching Capability-specific information (SCSI) TLV to extend the Generalized Multi-Protocol Label Switching (GMPLS) Open Shortest Path First (OSPF) routing protocol. The extension can be used for route computation in a network that contains links with variable discrete bandwidth. Note, this document only covers the mechanisms by which the availability information is distributed. The mechanisms by which availability information of a link is determined and the use of the distributed information for route computation are outside the scope of this document. It is intended that technology- specific documents will reference this document to describe specific uses.
    
draft-ietf-ccamp-rsvp-te-bandwidth-availability-06.txt
 Ethernet Traffic Parameters with Availability Information
 
 draft-ietf-ccamp-rsvp-te-bandwidth-availability-06.txt
 Date: 13/02/2017
 Authors: Hao Long, Min Ye, Gregory Mirsky, Alessandro D'Alessandro, Himanshu Shah
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
A Packet switching network may contain links with variable bandwidth, e.g., copper, radio, etc. The bandwidth of such links is sensitive to external environment. Availability is typically used for describing the link during network planning. This document introduces an optional Availability TLV in Resource ReSerVation Protocol - Traffic Engineer (RSVP-TE) signaling. This extension can be used to set up a Label Switched Path (LSP) in a Packet Switched Network (PSN) that contains links with discretely variable bandwidth.
    
draft-ietf-ccamp-wson-iv-info-03.txt
 Information Model for Wavelength Switched Optical Networks (WSONs) with Impairments Validation
 
 draft-ietf-ccamp-wson-iv-info-03.txt
 Date: 24/10/2016
 Authors: Giovanni Martinelli, Xian Zhang, Gabriele Galimberti, Andrea Zanardi, Domenico Siracusa, Federico Pederzolli, Young Lee, Fatai Zhang
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: xml txt
This document defines an information model to support Impairment- Aware (IA) Routing and Wavelength Assignment (RWA) functionality. This information model extends the information model for impairment- free RWA process in WSON to facilitate computation of paths where optical impairment constraints need to considered.
    
draft-ietf-ccamp-wson-yang-04.txt
 A Yang Data Model for WSON Optical Networks
 
 draft-ietf-ccamp-wson-yang-04.txt
 Date: 20/01/2017
 Authors: Young Lee, Dhruv Dhody, Xian Zhang, Aihua Guo, Victor Lopezalvarez, Daniel King, Bin-Yeong Yoon
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
This document provides a YANG data model for the routing and wavelength assignment (RWA) TE topology in wavelength switched optical networks (WSONs).
    
draft-ietf-cdni-uri-signing-10.txt
 URI Signing for CDN Interconnection (CDNI)
 
 draft-ietf-cdni-uri-signing-10.txt
 Date: 04/10/2016
 Authors: Ray van Brandenburg, Kent Leung, sorber@apache.org, Matthew Miller
 Working Group: Content Delivery Networks Interconnection (cdni)
 Formats: txt xml
This document describes how the concept of URI signing supports the content access control requirements of CDNI and proposes a URI signing method as a JSON Web Token (JWT) [RFC7519] profile. The proposed URI signing method specifies the information needed to be included in the URI to transmit the signed JWT as well as the claims needed by the signed JWT to authorize a UA. The mechanism described can be used both in CDNI and single CDN scenarios.
    
draft-ietf-cellar-ebml-01.txt
 Extensible Binary Meta Language
 
 draft-ietf-cellar-ebml-01.txt
 Date: 15/10/2016
 Authors: Steve <>, Dave <>, Moritz <>
 Working Group: Codec Encoding for LossLess Archiving and Realtime transmission (cellar)
 Formats: xml txt
This document defines the Extensible Binary Meta Language (EBML) format as a generalized file format for any type of data in a hierarchical form. EBML is designed as a binary equivalent to XML and uses a storage-efficient approach to build nested Elements with identifiers, lengths, and values. Similar to how an XML Schema defines the structure and semantics of an XML Document, this document defines how EBML Schemas are created to convey the semantics of an EBML Document.
    
draft-ietf-clue-data-model-schema-17.txt
 An XML Schema for the CLUE data model
 
 draft-ietf-clue-data-model-schema-17.txt
 Date: 13/08/2016
 Authors: Roberta Presta, Simon Romano
 Working Group: ControLling mUltiple streams for tElepresence (clue)
 Formats: txt
This document provides an XML schema file for the definition of CLUE data model types. The term "CLUE" stands for "ControLling mUltiple streams for tElepresence" and is the name of the IETF working group in which this document, as well as other companion documents, has been developed. The document defines a coherent structure for information associated with the description of a telepresence scenario.
    
draft-ietf-clue-datachannel-14.txt
 CLUE Protocol data channel
 
 draft-ietf-clue-datachannel-14.txt
 Date: 09/08/2016
 Authors: Christer Holmberg
 Working Group: ControLling mUltiple streams for tElepresence (clue)
 Formats: xml txt
This document defines how to use the WebRTC data channel mechanism in order to realize a data channel, referred to as a CLUE data channel, for transporting CLUE protocol messages between two CLUE entities. The document defines how to describe the SCTPoDTLS association used to realize the CLUE data channel using the Session Description Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data channel negotiation mechanism for establishing a CLUE data channel. Details and procedures associated with the CLUE protocol, and the SDP Offer/Answer procedures for negotiating usage of a CLUE data channel, are outside the scope of this document.
    
draft-ietf-clue-framework-25.txt
 Framework for Telepresence Multi-Streams
 
 draft-ietf-clue-framework-25.txt
 Date: 08/01/2016
 Authors: Mark Duckworth, Andrew Pepperell, Stephan Wenger
 Working Group: ControLling mUltiple streams for tElepresence (clue)
 Formats: txt
This document defines a framework for a protocol to enable devices in a telepresence conference to interoperate. The protocol enables communication of information about multiple media streams so a sending system and receiving system can make reasonable decisions about transmitting, selecting and rendering the media streams. This protocol is used in addition to SIP signaling and SDP negotiation for setting up a telepresence session.
    
draft-ietf-clue-protocol-12.txt
 CLUE protocol
 
 draft-ietf-clue-protocol-12.txt
 Date: 23/01/2017
 Authors: Roberta Presta, Simon Romano
 Working Group: ControLling mUltiple streams for tElepresence (clue)
 Formats: txt
The CLUE protocol is an application protocol conceived for the description and negotiation of a telepresence session. The design of the CLUE protocol takes into account the requirements and the framework defined within the IETF CLUE working group. A companion document delves into CLUE signaling details, as well as on the SIP/ SDP session establishment phase. CLUE messages flow over the CLUE data channel, based on reliable and ordered SCTP over DTLS transport. Message details, together with the behavior of CLUE Participants acting as Media Providers and/or Media Consumers, are herein discussed.
    
draft-ietf-clue-rtp-mapping-13.txt
 Mapping RTP streams to CLUE Media Captures
 
 draft-ietf-clue-rtp-mapping-13.txt
 Date: 13/02/2017
 Authors: Roni Even, Jonathan Lennox
 Working Group: ControLling mUltiple streams for tElepresence (clue)
 Formats: pdf txt
This document describes how the Real Time transport Protocol (RTP) is used in the context of the CLUE protocol (ControLling mUltiple streams for tElepresence). It also describes the mechanisms and recommended practice for mapping RTP media streams defined in Session Description Protocol (SDP) to CLUE Media Captures and defines a new RTP header extension (CaptureId).
    
draft-ietf-clue-signaling-10.txt
 CLUE Signaling
 
 draft-ietf-clue-signaling-10.txt
 Date: 03/01/2017
 Authors: Paul Kyzivat, Lennard Xiao, Christian Groves, Robert Hansen
 Working Group: ControLling mUltiple streams for tElepresence (clue)
 Formats: txt xml
This document specifies how CLUE-specific signaling such as the CLUE protocol [I-D.ietf-clue-protocol] and the CLUE data channel [I-D.ietf-clue-datachannel] are used with each other and with existing signaling mechanisms such as SIP and SDP to produce a telepresence call.
    
draft-ietf-codec-ambisonics-01.txt
 Ambisonics in an Ogg Opus Container
 
 draft-ietf-codec-ambisonics-01.txt
 Date: 21/11/2016
 Authors: Michael Graczyk, Jan Skoglund
 Working Group: Internet Wideband Audio Codec (codec)
 Formats: txt xml
This document defines an extension to the Ogg format to encapsulate ambisonics coded using the Opus audio codec.
    
draft-ietf-codec-opus-update-05.txt
 Updates to the Opus Audio Codec
 
 draft-ietf-codec-opus-update-05.txt
 Date: 19/12/2016
 Authors: Jean-Marc Valin, Koen Vos
 Working Group: Internet Wideband Audio Codec (codec)
 Formats: txt
This document addresses minor issues that were found in the specification of the Opus audio codec in RFC 6716 [RFC6716].
    
draft-ietf-core-coap-pubsub-00.txt
 Publish-Subscribe Broker for the Constrained Application Protocol (CoAP)
 
 draft-ietf-core-coap-pubsub-00.txt
 Date: 21/10/2016
 Authors: Michael Koster, Ari Keranen, Jaime Jimenez
 Working Group: Constrained RESTful Environments (core)
 Formats: xml txt
The Constrained Application Protocol (CoAP), and related extensions are intended to support machine-to-machine communication in systems where one or more nodes are resource constrained, in particular for low power wireless sensor networks. This document defines a publish- subscribe broker for CoAP that extends the capabilities of CoAP for supporting nodes with long breaks in connectivity and/or up-time.
    
draft-ietf-core-coap-tcp-tls-06.txt
 CoAP (Constrained Application Protocol) over TCP,TLS,and WebSockets
 
 draft-ietf-core-coap-tcp-tls-06.txt
 Date: 14/02/2017
 Authors: Carsten Bormann, Simon Lemay, Hannes Tschofenig, Klaus Hartke, Bill Silverajan, Brian Raymor
 Working Group: Constrained RESTful Environments (core)
 Formats: pdf xml txt
The Constrained Application Protocol (CoAP), although inspired by HTTP, was designed to use UDP instead of TCP. The message layer of the CoAP over UDP protocol includes support for reliable delivery, simple congestion control, and flow control. Some environments benefit from the availability of CoAP carried over reliable transports such as TCP or TLS. This document outlines the changes required to use CoAP over TCP, TLS, and WebSockets transports. It also formally updates [RFC7641] for use with these transports.
    
draft-ietf-core-cocoa-00.txt
 CoAP Simple Congestion Control/Advanced
 
 draft-ietf-core-cocoa-00.txt
 Date: 21/10/2016
 Authors: Carsten Bormann, August Betzler, Carles Gomez, Ilker Demirkol
 Working Group: Constrained RESTful Environments (core)
 Formats: txt
The CoAP protocol needs to be implemented in such a way that it does not cause persistent congestion on the network it uses. The CoRE CoAP specification defines basic behavior that exhibits low risk of congestion with minimal implementation requirements. It also leaves room for combining the base specification with advanc