Internet Drafts - Sorted by name


    
draft-aanchal-time-implementation-guidance-01.txt
 On Implementing Time
 
 draft-aanchal-time-implementation-guidance-01.txt
 Date: 22/10/2018
 Authors: Aanchal Malhotra, Kristof Teichel, Martin Hoffmann, Willem Toorop
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the properties of different types of clocks available on digital systems. It provides implementors of applications with guidance on choices they have to make when working with time to provide basic functionality and security guarantees.
    
draft-aboba-avtcore-quic-multiplexing-03.txt
 QUIC Multiplexing
 
 draft-aboba-avtcore-quic-multiplexing-03.txt
 Date: 23/01/2019
 Authors: Bernard Aboba, Peter Thatcher, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: txt
If QUIC is to be used in a peer-to-peer manner, with NAT traversal, then it is necessary to be able to demultiplex QUIC and other protocols used in WebRTC on a single UDP port. This memo discusses options for demultiplexing.
    
draft-accilent-at-sign-00.txt
 Clarification of Proper Use of "@" (at sign) in URI-style Components
 
 draft-accilent-at-sign-00.txt
 Date: 30/07/2010
 Authors: Robert Simpson
 Working Group: Individual Submissions (none)
 Formats: xml txt
Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses.
    
draft-acee-idr-lldp-peer-discovery-04.txt
 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery
 
 draft-acee-idr-lldp-peer-discovery-04.txt
 Date: 30/12/2018
 Authors: Acee Lindem, Keyur Patel, Shawn Zandi, Jeffrey Haas, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt
Link Layer Discovery Protocol (LLDP) or IEEE 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses.
    
draft-acee-lsr-ospf-admin-tags-01.txt
 Extensions to OSPF for Advertising Prefix/Link Administrative Tags
 
 draft-acee-lsr-ospf-admin-tags-01.txt
 Date: 14/01/2019
 Authors: Acee Lindem, Peter Psenak
 Working Group: Individual Submissions (none)
 Formats: txt
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to associate tags with prefixes and links. Previously, OSPFv2 and OSPFv3 were relegated to a single tag for AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may advertised for all types of prefixes and links. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. The ISIS protocol supports a similar mechanism that is described in RFC 5130.
    
draft-acee-lsr-ospfv3-extended-lsa-yang-02.txt
 Yang Model for OSPFv3 Extended LSAs
 
 draft-acee-lsr-ospfv3-extended-lsa-yang-02.txt
 Date: 22/10/2018
 Authors: Acee Lindem, Sharmila Palani
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisment (LSA) Extensibility as defined in RFC 8263. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340.
    
draft-adkp-grow-ixpcommunities-00.txt
 BGP Large Communities applications for IXP Route Servers
 
 draft-adkp-grow-ixpcommunities-00.txt
 Date: 11/03/2019
 Authors: Melchior Aelmans, Stavros Konstantaras, Stefan Plug, Christoph Dietzel
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents suggestion and examples for application of BGP Large Communities [RFC8092] at Internet Exchange Points (IXPs). Suggestions are based on operational experiences from IXP operators and members. Any IXP operator or IXP member can consider using these communities. The document specifically focusses on Route Server [RFC7947] deployments in IXP context [RFC7948].
    
draft-agrawal-spring-srv6-mpls-interworking-00.txt
 SRv6 and MPLS interworking
 
 draft-agrawal-spring-srv6-mpls-interworking-00.txt
 Date: 22/10/2018
 Authors: Swadesh Agrawal, Zafar Ali, Clarence Filsfils, daniel.voyer@bell.ca, Gaurav Dawra, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes SRv6 and MPLS/SR-MPLS interworking and co- existence procedures.
    
draft-alavarez-hamelin-tictoc-sic-02.txt
 Synchronizing Internet Clock frequency protocol (sic)
 
 draft-alavarez-hamelin-tictoc-sic-02.txt
 Date: 23/10/2018
 Authors: Jose Alvarez-Hamelin, David Samaniego, Alfredo Ortega, Ruediger Geib
 Working Group: Individual Submissions (none)
 Formats: xml txt
Synchronizing Internet Clock Frequency specifies a new secure method to synchronize difference clocks on the Internet, assuring smoothness (i.e., frequency stability) and robustness to man-in-the-middle attacks. In 90% of all cases, Synchronized Internet Clock Frequency is highly accurate, with a Maximum Time Interval Error less than 25 microseconds by a minute. Synchronized Internet Clock Frequency is based on a regular packet exchange and works with commodity terminal hardware.
    
draft-algermissen-digital-product-life-cycle-model-00.txt
 Digital Product Life Cycle Model
 
 draft-algermissen-digital-product-life-cycle-model-00.txt
 Date: 03/03/2019
 Authors: Jan Algermissen
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines an abstract model for Digital Products and their relationships with each other in order to establish a basic abstraction on which the lifecycle of Digital Products and collaborations around them can be expressed. In addition, this specification defines a number of message formats and hypermedia controls, to enable the creation of tools and application in the space of Digital Product Life Cycle Management.
    
draft-algermissen-software-system-life-cycle-model-00.txt
 Software System Life Cycle Model
 
 draft-algermissen-software-system-life-cycle-model-00.txt
 Date: 20/02/2019
 Authors: Jan Algermissen
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines an abstract model for software systems and their relationships with each other in order to establish a basic abstraction on which the lifecycle of software systems and collaborations around them can be expressed. In addition, this specification defines a number of message formats and hypermedia controls, to enable the creation of tools and application in the space of software systems life cycle management.
    
draft-ali-6man-spring-srv6-oam-01.txt
 Operations,Administration,and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
 
 draft-ali-6man-spring-srv6-oam-01.txt
 Date: 27/03/2019
 Authors: Zafar Ali, Clarence Filsfils, Nagendra Kumar, Carlos Pignataro, Rakesh Gandhi, Frank Brockners, John Leddy, Satoru Matsushima, Robert Raszuk, daniel.voyer@bell.ca, Gaurav Dawra, Bart Peirens, Mach Chen, Cheng Li, Faisal Iqbal
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines building blocks for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane (SRv6). The document also describes some SRv6 OAM mechanisms.
    
draft-ali-spring-bfd-sr-policy-02.txt
 Bidirectional Forwarding Detection (BFD) for Segment Routing Policies for Traffic Engineering
 
 draft-ali-spring-bfd-sr-policy-02.txt
 Date: 22/10/2018
 Authors: Zafar Ali, Ketan Talaulikar, Clarence Filsfils, Nagendra Kumar, Carlos Pignataro
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path using a segment list which is referred to as a SR Policy. Intermediate per-flow states are eliminated thanks to source routing. The header of a packet steered in an SR Policy is augmented with the ordered list of segments associated with that SR Policy. Bidirectional Forwarding Detection (BFD) is used to monitor different kinds of paths between node. BFD mechanisms can be also used to monitor the availability of the path indicated by a SR Policy and to detect any failures. Seamless BFD (S-BFD) extensions provide a simplified mechanism which is suitable for monitoring of paths that are setup dynamically and on a large scale. This document describes the use of Seamless BFD (S-BFD) mechanism to monitor the SR Policies that are used for Traffic Engineering (TE) in SR deployments.
    
draft-ali-spring-ioam-srv6-00.txt
 Segment Routing Header encapsulation for In-situ OAM Data
 
 draft-ali-spring-ioam-srv6-00.txt
 Date: 22/10/2018
 Authors: Zafar Ali, Rakesh Gandhi, Clarence Filsfils, Frank Brockners, Nagendra Kumar, Carlos Pignataro, Cheng Li, Mach Chen, Gaurav Dawra
 Working Group: Individual Submissions (none)
 Formats: txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the data packet while the packet traverses a path between two points in the network. This document defines how IOAM data fields are transported as part of the Segment Routing with IPv6 data plane (SRv6) header.
    
draft-ali-spring-network-slicing-building-blocks-01.txt
 Building blocks for Slicing in Segment Routing Network
 
 draft-ali-spring-network-slicing-building-blocks-01.txt
 Date: 10/03/2019
 Authors: Zafar Ali, Clarence Filsfils, Pablo Camarillo, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how to build network slice using the Segment Routing based technology. It explains how the existing building blocks specified for the Segment Routing can be used for this purpose.
    
draft-ali-spring-sr-service-programming-oam-00.txt
 OAM for Service Programming with Segment Routing
 
 draft-ali-spring-sr-service-programming-oam-00.txt
 Date: 22/10/2018
 Authors: Zafar Ali, Clarence Filsfils, Nagendra Kumar, Carlos Pignataro, Francois Clad, faiqbal@cisco.com, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the Operations, Administrations and Maintenance (OAM) for service programming in SR-enabled MPLS and IP networks.
    
draft-allan-lsr-flooding-algorithm-00.txt
 A Distributed Algorithm for Constrained Flooding of IGP Advertisements
 
 draft-allan-lsr-flooding-algorithm-00.txt
 Date: 18/10/2018
 Authors: Dave Allan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a distributed algorithm that can be applied to the problem of constraining IGP flooding in dense mesh topologies. The flooding topology utilizes two node-diverse spanning trees in order to provide complete coverage in the presence of any single failure while constraining the number of LSAs received by any IGP speaker connected to the flooding topology.
    
draft-alvestrand-mmusic-simulcast-ssrc-00.txt
 Using SSRC with WebRTC Simulcast
 
 draft-alvestrand-mmusic-simulcast-ssrc-00.txt
 Date: 11/04/2019
 Authors: Harald Alvestrand
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a convention for sending "a=ssrc" attributes in SDP together with "a=simulcast" attributes. This allows SFUs that need SSRC information to have this info easily accessible. Given that it is intended as an interim measure, it does not aim for being published as an RFC.
    
draft-amend-tsvwg-dccp-udp-header-conversion-00.txt
 Lossless and overhead free DCCP - UDP header conversion (U-DCCP)
 
 draft-amend-tsvwg-dccp-udp-header-conversion-00.txt
 Date: 11/03/2019
 Authors: Markus Amend, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic
 Working Group: Individual Submissions (none)
 Formats: txt
The Datagram Congestion Control protocol (DCCP) is a non-widely deployed transport protocol in the Internet. The reason for that is a typical chicken-egg problem. Even if there would be a use for application developer to rely on DCCP, middle-boxes like firewalls and NATs will prevent DCCP end-to-end since they lack support for DCCP. However, as long as the protocol penetration of DCCP will not increase, middle-boxes will not handle DCCP properly. To overcome this challenge NAT/NATP traversal and UDP encapsulation for DCCP is already defined. However the first requires special middle-box support and the latter introduces overhead. The proposal of a multipath extension for DCCP further stresses the question of efficient middle-box passing as its main goal is to be applied over the Internet, traversing numerous uncontrolled middle-boxes. This document introduces a new approach, disguising DCCP during transmission as UDP without requiring middle-box modification nor introducing any overhead.
    
draft-amend-tsvwg-multipath-dccp-01.txt
 DCCP Extensions for Multipath Operation with Multiple Addresses
 
 draft-amend-tsvwg-multipath-dccp-01.txt
 Date: 11/03/2019
 Authors: Markus Amend, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic
 Working Group: Individual Submissions (none)
 Formats: txt
DCCP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a DCCP session could improve resource usage within the network and, thus, improve user experience through higher throughput and improved resilience to network failure. Multipath DCCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional DCCP to support multipath operation. The protocol offers the same type of service to applications as DCCP and it provides the components necessary to establish and use multiple DCCP flows across potentially disjoint paths.
    
draft-amend-tsvwg-multipath-framework-mpdccp-00.txt
 IP compatible multipath framework for heterogeneous access networks
 
 draft-amend-tsvwg-multipath-framework-mpdccp-00.txt
 Date: 11/03/2019
 Authors: Markus Amend, Anna Brunstrom, Andreas Kassler, Veselin Rakocevic
 Working Group: Individual Submissions (none)
 Formats: txt
More and more of today's devices are multi-homing capable, in particular 3GPP user equipment like smartphones. In the current standardization of the next upcoming mobile network generation 5G Rel. 16, this is especially targeted in the study group Access Traffic Steering Switching Splitting [3GPP, TR 23.793]. ATSSS describes the flexible selection or combination of 3GPP untrusted access like Wi-Fi and cellular access, overcoming the single-access limitation of today's devices and services. Another multi- connectivity scenario is the Hybrid Access [draft-lhwxz-hybrid- access-network-architecture, draft-muley-network-based-bonding- hybrid-access], providing multiple access for CPEs, which extends the traditional way of single access connectivity at home to dual- connectivity over 3GPP and fixed access. A missing piece in the ATSSS and Hybrid Access is the access and path measurement for efficient and beneficial traffic steering decisions. This becomes particularly important in heterogeneous access networks with a multitude of volatile access paths. MP-TCP can be employed in such scenarios and concerning the ATSSS, it is the agreed protocol for the traffic splitting mode. A decision for MP-TCP though leaves the increasing share of UDP in today's traffic mix (https://arxiv.org/ abs/1801.05168) unconsidered. In this document, a network architecture leveraging the MP-DCCP network protocol is proposed, which enables above scenarios and address the formulated issues either independent or complementary to MP-TCP.
    
draft-amringer-jose-chacha-00.txt
 Chacha derived AEAD algorithms in JSON Object Signing and Encryption (JOSE)
 
 draft-amringer-jose-chacha-00.txt
 Date: 07/11/2018
 Authors: Guillaume Amringer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines how to use the AEAD algorithms "AEAD_XCHACHA20_POLY1305" and "AEAD_CHACHA20_POLY1305" from [RFC8439] and [I-D.arciszewski-xchacha] in JSON Object Signing and Encryption (JOSE).
    
draft-amsuess-core-accept-any-00.txt
 Accept-Any option for CoAP
 
 draft-amsuess-core-accept-any-00.txt
 Date: 25/03/2019
 Authors: Christian Amsuess
 Working Group: Individual Submissions (none)
 Formats: xml txt
This memoy defines the Accept-Any option, which provides a more flexible content negotiation than the one originally specified for the Constrained Application Protocol (CoAP) in [RFC7252]. As this is particularly useful with but ruled out in CoAP observation ([RFC7641]), that is updated to allow it.
    
draft-amsuess-core-rd-replication-02.txt
 Resource Directory Replication
 
 draft-amsuess-core-rd-replication-02.txt
 Date: 11/03/2019
 Authors: Christian Amsuess
 Working Group: Individual Submissions (none)
 Formats: txt xml
Discovery of endpoints and resources in M2M applications over large networks is enabled by Resource Directories, but no special consideration has been given to how such directories can scale beyond what can be managed by a single device. This document explores different ways in which Resource Directories can be scaled up from single network to enterprise and global scale. It does not attempt to standardize any of those methods, but only to demonstrate the feasibility of such extensions and to provide terminology and exploratory groundwork for later documents.
    
draft-amsuess-core-resource-directory-extensions-00.txt
 CoRE Resource Directory Extensions
 
 draft-amsuess-core-resource-directory-extensions-00.txt
 Date: 10/01/2019
 Authors: Christian Amsuess
 Working Group: Individual Submissions (none)
 Formats: txt xml
[ See Introduction ]
    
draft-amsuess-t2trg-rdlink-00.txt
 rdlink: Robust distributed links to constrained devices
 
 draft-amsuess-t2trg-rdlink-00.txt
 Date: 24/03/2019
 Authors: Christian Amsuess
 Working Group: Individual Submissions (none)
 Formats: xml txt
Thing to thing communication in Constrained RESTful Environments (CoRE) relies on URIs to link to servers. Next to hierarchical configuration and short-lived IP addresses, this document introduces a naming scheme for devices based on cryptographic identifiers. A special purpose domain is reserved for expressing those identifiers, and mechanisms for constrained devices to announce their names and to look them up are described.
    
draft-an-savi-mib-16.txt
 Definition of Managed Objects for SAVI Protocol
 
 draft-an-savi-mib-16.txt
 Date: 18/01/2019
 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-anand-ippm-po-ioam-02.txt
 Integrated Packet-Optical In-Situ OAM
 
 draft-anand-ippm-po-ioam-02.txt
 Date: 25/02/2019
 Authors: Madhukar Anand, Sanjoy Bardhan, Radha Valiveti, Ramesh Subrahmaniam, Carlos Pignataro, Shwetha Bhandari, Randy Zhang, Rajiv Asati
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a way to extend in-situ OAM techniques to include operational data from multiple network layers with a view to create an integrated record of OAM information as the data flows between two network entities. An instance of this technique that is elaborated here focuses on packet-optical networks that are traditionally transport centric. The mechanisms described are general enough to allow future extensibility of in-situ OAM techniques into other non-packet domains.
    
draft-anand-spring-poi-sr-07.txt
 Packet-Optical Integration in Segment Routing
 
 draft-anand-spring-poi-sr-07.txt
 Date: 28/01/2019
 Authors: Madhukar Anand, Sanjoy Bardhan, Ramesh Subrahmaniam, Jeff Tantsura, Utpal Mukhopadhyaya, Clarence Filsfils
 Working Group: Individual Submissions (none)
 Formats: txt
This document illustrates a way to integrate a new class of nodes and links in segment routing to represent transport/optical networks in an opaque way into the segment routing domain. An instance of this class would be optical networks that are typically transport centric by having very few devices with the capability to process packets. In the IP centric network, this will help in defining a common control protocol for packet optical integration that will include optical paths as 'transport segments' or sub-paths as an augmentation to packet paths. The transport segment option also defines a general mechanism to allow for future extensibility of segment routing into non-packet domains.
    
draft-andersson-mpls-eh-architecture-00.txt
 MPLS Extension Header Architecture
 
 draft-andersson-mpls-eh-architecture-00.txt
 Date: 13/02/2019
 Authors: Loa Andersson, Jim Guichard, Haoyu Song, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: txt
Extension Headers (EH) carry information on in-network services and functions in an MPLS network. This document describes an architecture for EHs and what actions an EH capable Label Switching Router (LSR) takes when finding or not finding an EH in the packet. Multiprotocol Label Switching (MPLS) is a widely deployed forwarding technology. It uses label stack entries that are pre-pended to either the EH or the ACH which in turn is pre-pended to the payload. The label stack entries are used to identify the forwarding actions by each LSR. Actions may include pushing, swapping or popping the labels, and using the labels to determine the next hop for forwarding the packet. Labels may also be used to establish the context under which the packet is forwarded. The extension headers are carried after the MPLS Label Stack, and the presence of EHs are indicated in the label stack by an Extension Header Indicator (EHI).
    
draft-andersson-mpls-eh-label-stack-operations-00.txt
 MPLS Label Operations in MPLS EH capable networks
 
 draft-andersson-mpls-eh-label-stack-operations-00.txt
 Date: 20/02/2019
 Authors: Loa Andersson, Jim Guichard, Haoyu Song, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: txt
Extension Headers (EH) carry information on in-network services and functions in an MPLS network. This document describes the operations on the MPLS label stack when an EH is found in the packet.
    
draft-andersson-mpls-spl-terminology-01.txt
 Special Purpose Label terminology
 
 draft-andersson-mpls-spl-terminology-01.txt
 Date: 26/02/2019
 Authors: Loa Andersson, Kireeti Kompella, Adrian Farrel
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses and recommends a terminology that may be used when MPLS Special Purpose Labels (SPL) are specified and documented. Note: The rest of the text in this section is not really part of the abstract even though the text is placed here. It is working notes. Note: At least at the moment it is not the intention to take this document to an RFC, but it might be polled to become a wg document to see if the MPLS working group agree on the proposed terminology. Note: The changes we propose are minor, but we might have to progress the document to RFC since there is a proposed change to the "Special- Purpose Multiprotocol Label Switching (MPLS) Label Values" registry.
    
draft-anilj-icnrg-dnc-qos-icn-00.txt
 QoS Treatments in ICN using Disaggregated Name Components
 
 draft-anilj-icnrg-dnc-qos-icn-00.txt
 Date: 11/03/2019
 Authors: Anil Jangam, Prakash suthar, Milan Stolic
 Working Group: Individual Submissions (none)
 Formats: txt
Mechanisms for specifying and implementing end-to-end Quality of service (QoS) treatments in Information-Centric Networks (ICN) has not been explored so far. There has been some work towards implementing QoS in ICN; however, the discussions are mainly centered around strategies used in efficient forwarding of Interest packets. Moreover, as ICN has been tested mainly as an IP overlay, it's QoS is still governed by the IP QoS framework and there is a need for implementing QoS in ICN natively. This document describes mechanisms to classify and provide associated "name-based" extensions to identify QoS within the framework of ICN's core design principles. The name-based design provides a mechanism to carry QoS information and implement the treatments as ICN packets travel across different routers in the ICN network. Detailed discussion is provided for QoS specific procedures in each of the ICN network elements i.e. consumer, producer and forwarder.
    
draft-anish-pim-reliable-registers-00.txt
 Reliable Transport For PIM Register States
 
 draft-anish-pim-reliable-registers-00.txt
 Date: 20/11/2018
 Authors: Anish Peter, Robert Kebler, Vikram Nagarajan, Toerless Eckert, Stig Venaas
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces a hard-state, reliable transport for the existing PIM-SM registers states. This eliminates the needs for periodic NULL-registers and register-stop in response to each data- register or NULL-registers. This specification uses the existing PIM reliability mechanisms defined by PIM Over Reliable Transport [RFC6559]. This is simply a means to transmit reliable PIM messages and does not require the support for Join/Prune messages over PORT as defined in [RFC6559].
    
draft-ao-nvo3-overlay-subnet-architecture-00.txt
 Architecture for Overlay Virtual Sub-Network Interconnection
 
 draft-ao-nvo3-overlay-subnet-architecture-00.txt
 Date: 20/10/2018
 Authors: Ting Ao, Gregory Mirsky, Fan Yongbing
 Working Group: Individual Submissions (none)
 Formats: txt
An virtualized overlay network may be divided into several subnets for the reasons of geographical location, management, or using different technologies being used. For example, different customer have their own preference. But all these subnets need to work together to provide an end-to-end connectionif in a virtual network, An extended architecture of the NVO3 and propose a new component to provide the connection fucntion are introduced in this document.
    
draft-ao-sfc-oam-path-consistency-05.txt
 SFC OAM for path consistency
 
 draft-ao-sfc-oam-path-consistency-05.txt
 Date: 09/03/2019
 Authors: Ting Ao, Gregory Mirsky, Zhonghua Chen, Kent Leung
 Working Group: Individual Submissions (none)
 Formats: txt
Service Function Chain (SFC) defines an ordered set of service functions (SFs) to be applied to packets and/or frames and/or flows selected as a result of classification. SFC Operation, Administration and Maintenance can monitor the continuity of the SFC, i.e., that all elements of the SFC are reachable to each other in the downstream direction. But SFC OAM must support verification that the order of traversing these SFs corresponds to the state defined by the SFC control plane or orchestrator, the metric referred in this document as the path consistency of the SFC. This document defines a new SFC OAM method to support SFC consistency check, i.e. verification that all elements of the given SFC are being traversed in the expected order.
    
draft-ao-sfc-oam-return-path-specified-03.txt
 Controlled Return Path for Service Function Chain (SFC) OAM
 
 draft-ao-sfc-oam-return-path-specified-03.txt
 Date: 11/03/2019
 Authors: Ting Ao, Gregory Mirsky, Zhonghua Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines extensions to the Service Function Chain (SFC) Operation, Administration and Maintenance (OAM) that enable control of the Echo Reply return path by specifying it as Reverse Service Function Path. Enforcing the specific return path can be used to verify bidirectional connectivity of SFC and increase the robustness of SFC OAM.
    
draft-ao-sfc-scalability-analysis-04.txt
 Analysis of the SFC scalability
 
 draft-ao-sfc-scalability-analysis-04.txt
 Date: 19/10/2018
 Authors: Ting Ao, Gregory Mirsky
 Working Group: Individual Submissions (none)
 Formats: txt
SFC is an ordered set of service function, should be scalable to meet broad range of requirements. The scalability of SFC can be interpreted as ability of the SFC to accommodate one or more SFs joining the SFC , or leaving the SFC without significant impact to SFC performance. This document presents four aspects on SFC scalability, and provide analysis of the data plane and the control plane to implement the scalable SFC.
    
draft-ao-sfc-transport-00.txt
 SFC transport considertation
 
 draft-ao-sfc-transport-00.txt
 Date: 22/10/2018
 Authors: Ting Ao, Wei Wei, Yan Zheng
 Working Group: Individual Submissions (none)
 Formats: txt
A Network Service Header(NSH) is imposed encapsulates a packet or a frame for Service Function Chaining. The resulting packet, in turn, is encapsulate according to transport layer. The NSH contains a Service Path Identifier (SPI) and a Service Index (SI). The SPI is, as per its name, an identifier. The SPI alone cannot be used to forward packets along a service path. Rather, the SPI provides a level of indirection between the service path / topology and the network transport encapsulation. For different transport encapsulations, this document provides the format information with transport and NSH, and gives operational constraints that transport technologies, used by NSH need to meet.
    
draft-ao-sfc-yang-00.txt
 YANG data model for SFC
 
 draft-ao-sfc-yang-00.txt
 Date: 10/03/2019
 Authors: Ting Ao, Ran Chen, Wei Wei
 Working Group: Individual Submissions (none)
 Formats: txt
This document is to define the YANG data model for SFC configuration.
    
draft-aranda-dispatch-q4s-07.txt
 The Quality for Service Protocol
 
 draft-aranda-dispatch-q4s-07.txt
 Date: 05/12/2018
 Authors: Jose Aranda, Monica Cortes, Joaquin Salvachua, Tecnalia Innovation, Inaki Sarriegui
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This memo describes an application level protocol for the standard communication of e2e QoS compliance information using a protocol based on Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web, and Session Description Protocol (SDP). Quality for Service Protocol (Q4S) provides a mechanism for latency, jitter, bandwidth and packet loss negotiation and monitoring, alerting whenever one of the negotiated conditions is violated. Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this draft, it is application dependent (e.g. increase quality, reduce bit-rate) or even network dependent (e.g. change connection's quality profile).
    
draft-arciszewski-xchacha-03.txt
 XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305
 
 draft-arciszewski-xchacha-03.txt
 Date: 18/12/2018
 Authors: Scott Arciszewski
 Working Group: Crypto Forum (cfrg)
 Formats: xml txt
The eXtended-nonce ChaCha cipher construction (XChaCha) allows for ChaCha-based ciphersuites to accept a 192-bit nonce with similar guarantees to the original construction, except with a much lower probability of nonce misuse occurring. This enables XChaCha constructions to be stateless, while retaining the same security assumptions as ChaCha. This document defines XChaCha20, which uses HChaCha20 to convert the key and part of the nonce into a subkey, which is in turn used with the remainder of the nonce with ChaCha20 to generate a pseudorandom keystream (e.g. for message encryption). This document also defines AEAD_XChaCha20_Poly1305, a variant of [RFC7539] that utilizes the XChaCha20 construction in place of ChaCha20.
    
draft-arias-noguchi-dnrd-objects-mapping-10.txt
 Domain Name Registration Data (DNRD) Objects Mapping
 
 draft-arias-noguchi-dnrd-objects-mapping-10.txt
 Date: 04/01/2019
 Authors: Gustavo Lozano, James Gould, Chethan Thippeswamy
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) Escrow deposits for a Domain Name Registry.
    
draft-arias-noguchi-registry-data-escrow-11.txt
 Registry Data Escrow Specification
 
 draft-arias-noguchi-registry-data-escrow-11.txt
 Date: 03/01/2019
 Authors: Gustavo Lozano
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. However, the specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for purposes other than domain name registries.
    
draft-arkko-eap-aka-pfs-04.txt
 Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)
 
 draft-arkko-eap-aka-pfs-04.txt
 Date: 21/01/2019
 Authors: Jari Arkko, Karl Norrman, Vesa Torvinen
 Working Group: Individual Submissions (none)
 Formats: txt
Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. This specification is an optional extension to the EAP-AKA' authentication method which was defined in RFC 5448 (to be superseded by draft-ietf-emu-rfc5448bis). The extension, when negotiated, provides Perfect Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from being able to decrypt all past communications. In addition, if the attacker stays merely a passive eavesdropper, the extension prevents attacks against future sessions. This forces attackers to use active attacks instead.
    
draft-arkko-iab-internet-consolidation-01.txt
 Considerations on Internet Consolidation and the Internet Architecture
 
 draft-arkko-iab-internet-consolidation-01.txt
 Date: 11/03/2019
 Authors: Jari Arkko, Brian Trammell, Mark Nottingham, Christian Huitema, Martin Thomson, Jeff Tantsura, Niels ten Oever
 Working Group: Individual Submissions (none)
 Formats: txt
Many of us have held a vision of the Internet as the ultimate distributed platform that allows communication, the provision of services, and competition from any corner of the world. But as the Internet has matured, it seems to also feed the creation of large, centralised entities in many areas. This phenomenon could be looked at from many different angles, but this memo considers the topic from the perspective of how available technology and Internet architecture drives different market directions.
    
draft-arkko-trip-registry-update-01.txt
 Update to the TRIP IANA Registry Rules Regarding Postal Addresses
 
 draft-arkko-trip-registry-update-01.txt
 Date: 04/12/2018
 Authors: Jari Arkko, Ted Hardie
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
This memo updates the IANA registry rules for the Telephony Routing over IP (TRIP) protocol, by no longer requiring that postal addresses be included in contact information. This memo updates RFC 3219.
    
draft-arnt-yao-dnsop-root-data-caching-00.txt
 Decreasing Fetch time of Root Data by Additional Caching Rules
 
 draft-arnt-yao-dnsop-root-data-caching-00.txt
 Date: 13/02/2019
 Authors: Arnt Gulbrandsen, Jiankang Yao
 Working Group: Individual Submissions (none)
 Formats: txt
Some DNS recursive resolvers have long round trip times to the nearest DSN root server, which has been an obstacle to DNS query performance. In order to decrease root record fetch time without introducing a new source of errors, this document proposes a root- specific modification to the caching rules.
    
draft-arora-mpls-spring-ttl-procedures-srte-paths-01.txt
 TTL Procedures for SR-TE Paths in Label Switched Path Traceroute Mechanisms
 
 draft-arora-mpls-spring-ttl-procedures-srte-paths-01.txt
 Date: 21/02/2019
 Authors: Kapil Arora, Shraddha Hegde, Sam Aldrin, Stephane Litkowski, Muhammad Durrani
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
Segment routing supports the creation of explicit paths using adjacency-sids, node-sids, and anycast-sids. The SR-TE paths are built by stacking the labels that represent the nodes and links in the explicit path. A very useful Operations And Maintenance requirement is to be able to trace these paths as defined in [RFC8029]. This document specifies a uniform mechanism to support MPLS traceroute for the SR-TE paths when the nodes in the network are following uniform mode or short-pipe mode [RFC3443].
    
draft-asaeda-pim-multiif-igmpmldproxy-02.txt
 Multiple Upstream Interface Support for IGMP/MLD Proxy
 
 draft-asaeda-pim-multiif-igmpmldproxy-02.txt
 Date: 04/11/2018
 Authors: Hitoshi Asaeda, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the way of supporting multiple upstream interfaces for an IGMP/MLD proxy device. The proposed extension enables an IGMP/MLD proxy device to receive multicast sessions/ channels through the different upstream interfaces. The upstream interface is selected based on the subscriber address prefixes, channel/session IDs, and interface priority values. A mechanism for upstream interface takeover that enables to switch from an inactive upstream interface to an active upstream interface is also described.
    
draft-asciirfc-minimal-03.txt
 A Minimal Internet-Draft In AsciiRFC
 
 draft-asciirfc-minimal-03.txt
 Date: 11/12/2018
 Authors: Josiah Carberry, Truman Grayson
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. NOTE This template requires usage of the Metanorma toolchain and the "metanorma-ietf" Ruby gem.
    
draft-asechoud-rtgwg-qos-model-08.txt
 YANG Model for QoS
 
 draft-asechoud-rtgwg-qos-model-08.txt
 Date: 16/01/2019
 Authors: Aseem Choudhary, Mahesh Jethanandani, Norm Strahle, Ebben Aries, Ing-Wher Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a YANG model for Quality of Service (QoS) configuration and operational parameters.
    
draft-asechoud-rtgwg-qos-oper-model-03.txt
 YANG Model for QoS Operational Parameters
 
 draft-asechoud-rtgwg-qos-oper-model-03.txt
 Date: 02/01/2019
 Authors: Aseem Choudhary, Ing-Wher Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG model for Quality of Service (QoS) operational parameters.
    
draft-aspb-rof-00.txt
 Reproduce Object framework(ROF)
 
 draft-aspb-rof-00.txt
 Date: 09/01/2019
 Authors: Abel Sanchez, pushpita bhattacharjee
 Working Group: Individual Submissions (none)
 Formats: txt
This document postulates a standard for computational models to help with reproducibility. This standard proposes a lightweight,programing language agnostic, JavaScript Object Notation(JSON) based Framework to describe the environment and behavior of a computational model.
    
draft-atkins-openpgp-device-certificates-04.txt
 OpenPGP Extensions for Device Certificates
 
 draft-atkins-openpgp-device-certificates-04.txt
 Date: 10/04/2019
 Authors: Derek Atkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
The OpenPGP Message Formats defined in RFC 4880 specify packet formats and methods for combining those packets to form messages and certificates. However RFC 4880 made an architectural decision that keys are owned by users and must be self-certified. New use cases have emerged where that is not the case. There is a desire to have certificates that are not tied to a user (e.g. device certificates) which may only have encryption keys so may not be self certifiable. Moreover, devices might be space constrained so reducing size is important. This draft specifies extensions to (and updates) RFC 4880 that loosen the definitions of certificates in order to enable userless certificates without self-certifications and specifies a set of notations to enable compact device certifications.
    
draft-atlas-rift-pgp-00.txt
 Policy Guided Prefixes with Routing In Fat Trees
 
 draft-atlas-rift-pgp-00.txt
 Date: 22/10/2018
 Authors: Alia Atlas, Zhaohui Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
In a fat tree, it can be sometimes desirable to guide traffic to particular destinations or keep specific flows to certain paths. In RIFT, this traffic steering/engineering is done by using policy- guided prefixes with their associated communities. Routes based on policy-guided prefixes are preferred over regular routes. Any node can originate a policy-guided prefix and advertise it in both north and south directions, and the calculation in both directions are distance vector based.
    
draft-audeoudh-rpl-asymmetric-links-00.txt
 Experimental observation of RPL: routing protocol overhead and asymmetric links
 
 draft-audeoudh-rpl-asymmetric-links-00.txt
 Date: 11/03/2019
 Authors: Henry-Joseph Audeoud, Martin Heusse
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document summarizes our observations of the behavior of RPL on a testbed composed of tens of IEEE 802.15.4 nodes. Our first observation is that the continuous task of estimating the link metric to all candidate neighbors causes a significant background load. This traffic is persistent, even in a stable network where DIO transmissions are eventually widely spaced. Next, this document focuses on the case of the presence of an asymmetric link, due to either a muted or a deaf node. In these circumstances, the standard RPL mechanisms may well generate hundreds of routing messages per node and per hour.
    
draft-auge-dmm-hicn-mobility-01.txt
 Anchorless mobility through hICN
 
 draft-auge-dmm-hicn-mobility-01.txt
 Date: 20/12/2018
 Authors: Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini
 Working Group: Individual Submissions (none)
 Formats: txt
This document first dicusses the use of locators and identifiers in mobility management architectures, and their implication on various anchorless properties. A new architecture is then proposed that is purely based on identifiers, and more specifically names as defined in Hybrid-ICN [I-D.muscariello-intarea-hicn]. The document then focuses on two main cases: the end-point sends data (data producer) or the end-point receive data (data consumer). These two cases are taken into account entirely to provide anchorless mobility management in hICN.
    
draft-auge-dmm-hicn-mobility-deployment-options-01.txt
 Anchorless mobility management through hICN (hICN-AMM): Deployment options
 
 draft-auge-dmm-hicn-mobility-deployment-options-01.txt
 Date: 20/12/2018
 Authors: Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini
 Working Group: Individual Submissions (none)
 Formats: txt
A novel mobility management approach is described in [I-D.auge-dmm-hicn-mobility], that leverages routable location- independent identifiers (IDs) and an Information-Centric Networking (ICN) communication model integrated in IPv6, (also referred to as Hybrid ICN, hICN, [I-D.muscariello-intarea-hicn]. Such approach belongs to the category of pure ID-based mobility management schemes whose objective is (i) to overcome the limitations of traditional locator-based solutions like Mobile IP, (ii) to remove the need for a global mapping system as the one required by locator- identifier separation solutions like LISP [I-D.ietf-lisp-introduction] or ILA [I-D.herbert-intarea-ila]. ID-based networking as proposed by ICN architectures allows to disentangle forwarding operations from changes of network location, hence removing tunnels and user plane or control plane anchors. In virtue of its anchorless property, we denote this approach as hICN- AMM (hICN Anchorless Mobility Management) hereinafter. This document discusses hICN-AMM deployment options and related tradeoffs in terms of cost/benefits. Particular attention is devoted to the insertion in the recently proposed 5G Service Based Architecture under study at 3GPP where an hICN-AMM solution might present a more efficient alternative to the traditional tunnel-based mobility architecture through GTP-U.
    
draft-aura-eap-noob-05.txt
 Nimble out-of-band authentication for EAP (EAP-NOOB)
 
 draft-aura-eap-noob-05.txt
 Date: 11/03/2019
 Authors: Tuomas Aura, Mohit Sethi
 Working Group: Individual Submissions (none)
 Formats: txt xml
Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. This EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have a minimal user interface and no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB channel between the peer device and authentication server.
    
draft-autoadd-auto-bootstrapping-iot-devices-00.txt
 AutoAdd - Automatic Bootstrapping of IoT Devices
 
 draft-autoadd-auto-bootstrapping-iot-devices-00.txt
 Date: 01/02/2019
 Authors: Anoop Pandey
 Working Group: Individual Submissions (none)
 Formats: txt xml
IoT devices are fast getting embedded into our lives, and when put together they have the potential to generate a precise and detailed history of our lives and store them forever. Their networking and communicational power can be unleashed for malicious and sabotage purposes, by a motivated attacker sitting in the far corner of the world. Attacks on Industrial IoT systems can cause greater disasters. It is therefore essential to inculcate the security aspect, right from design to development to operations. The first operation of an IoT device is to bootstrap itself, and due importance should be placed to ensure that this operation is carried out securely and with due diligence. However, it's easier said than done, and this paper outlines several approaches for secure automated bootstrapping and also proposes a new method, which is compared against the existing mechanisms for several qualitative factors.
    
draft-azimov-sidrops-aspa-profile-01.txt
 A Profile for Autonomous System Provider Authorization
 
 draft-azimov-sidrops-aspa-profile-01.txt
 Date: 06/01/2019
 Authors: Alexander Azimov, Eugene Uskov, Randy Bush, Keyur Patel, Job Snijders, Russ Housley
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a standard profile for Autonomous System Provider Authorization in the Resource Public Key Infrastructure. An Autonomous System Provider Authorization is a digitally signed object that provides a means of verifying that a Customer Autonomous System holder has authorized a Provider Autonomous System to be its upstream provider and for the Provider to send prefixes received from the Customer Autonomous System in all directions including providers and peers.
    
draft-azimov-sidrops-aspa-verification-01.txt
 Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization
 
 draft-azimov-sidrops-aspa-verification-01.txt
 Date: 22/10/2018
 Authors: Alexander Azimov, Eugene Bogomazov, Randy Bush, Keyur Patel, Job Snijders
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the semantics of an Autonomous System Provider Authorization object in the Resource Public Key Infrastructure to verify the AS_PATH attribute of routes advertised in the Border Gateway Protocol.
    
draft-baba-iot-interconnection-01.txt
 Study Report on a Framework for Cloud Inter-connection toward the Realization of IoT
 
 draft-baba-iot-interconnection-01.txt
 Date: 15/11/2018
 Authors: Hiroyuki BABA, Izaya Miyake, Jun Matsumura, Yoshiki Ishida
 Working Group: Individual Submissions (none)
 Formats: xml txt
This paper describes issues for solutions through cloud inter- connection to structural problems, which are called as "silo effects" found in cloud-connected electric home appliances, housing equipment and sensors in the face of increasingly accelerated connection of them. Specifically, this paper explains an inter-connection agreement considered to be required for enhancement of cloud inter- connection, what performance guarantee as well as IoT supervising and management should be, necessity of inter-connection HUB which is able to provide inter-connection amongst the preponderance of private cloud groups.
    
draft-baba-iot-problems-06.txt
 Problems in and among industries for the prompt realization of IoT and safety considerations
 
 draft-baba-iot-problems-06.txt
 Date: 15/11/2018
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Koichi KUNITAKE, Kaoru Maeda
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document contains opinions gathered from enterprises engaging in the IoT business as stated in the preceding version hereof, and also examines the possibilities of new social problems in the IoT era. Recognition of the importance of information security has grown in step with the rising use of the Internet. Closer examination reveals that the IoT era may see a new direct physical threat to users. For instance, the situation at a smart house may lead it to judge that the owner has only temporarily stepped out, causing it to unlock the front door, which in turn makes it easier for thieves to enter. These kinds of scenarios may occur without identity fraud, hacking, and other means of compromising information security. Therefore, for the purpose of this document, this issue shall be referred to as "IoT Safety" to distinguish it from Information Security. We believe that it is necessary to deepen our understanding of these new IoT-related threats through discussion and ensure there are measures to address these threats in the future. At the same time, we must also coordinate these measures with the solutions to the problems described in the previous version of this document.
    
draft-baba-iot-webapi-04.txt
 Report on Problem Solving Experiment for Realization of Web-API-based IoT
 
 draft-baba-iot-webapi-04.txt
 Date: 15/11/2018
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Hiroshi Masuda, Shintaro Ogura, Koichi KUNITAKE
 Working Group: Individual Submissions (none)
 Formats: xml txt
The University of Tokyo (UOT) is currently performing a demonstration experiment in COMMA House, the experimental smart-house owned by UOT and used as a connected house. The things installed in the house (Things) are operated using applications on smartphones and other devices. The various Things in the smart-house are operated online via a Web API that has been created as a prototype. This report is an overview of the experimental demonstration, which is gradually clarifying that Web API should be effective for solving issues for IoT.
    
draft-balakrichenan-lpwan-dns-usage-00.txt
 DNS usage in LPWAN
 
 draft-balakrichenan-lpwan-dns-usage-00.txt
 Date: 31/12/2018
 Authors: Sandoche Balakrichenan
 Working Group: Individual Submissions (none)
 Formats: txt xml
DNS protocol and the database are used extensively in the Internet. Usage of DNS in the constrained devices or network is still nascent. This document describes how DNS could be used in a constrained scenario such as the LPWAN.
    
draft-barkai-lisp-nexagon-00.txt
 Distributed Geo-Spatial LISP Blackboard for Automotive
 
 draft-barkai-lisp-nexagon-00.txt
 Date: 05/02/2019
 Authors: Sharon Barkai, Ohad Serfaty, Alberto Rodriguez-Natal, Fabio Maino, Albert Cabellos-Aparicio
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the use of LISP Blackboard for distributed Geo-Spatial Publish/Subscribe automotive applications.
    
draft-barkai-lisp-nfv-13.txt
 LISP Based FlowMapping for Scaling NFV
 
 draft-barkai-lisp-nfv-13.txt
 Date: 09/01/2019
 Authors: Sharon Barkai, Dino Farinacci, David Meyer, Fabio Maino, Vina Ermagan, Alberto Rodriguez-Natal, Albert Cabellos-Aparicio
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes an RFC 6830 Locator ID Separation Protocol (LISP) based distributed flow-mapping-fabric for dynamic scaling of virtualized network functions (NFV). Network functions such as subscriber-management, content-optimization, security and quality of service, are typically delivered using proprietary hardware appliances embedded into the network as turn-key service-nodes or service-blades within routers. Next generation network functions are being implemented as pure software instances running on standard servers - unbundled virtualized components of capacity and functionality. LISP-SDN based flow-mapping, dynamically assembles these components to whole solutions by steering the right traffic in the right sequence to the right virtual function instance.
    
draft-barnes-cfrg-hpke-01.txt
 Hybrid Public Key Encryption
 
 draft-barnes-cfrg-hpke-01.txt
 Date: 11/03/2019
 Authors: Richard Barnes, Karthikeyan Bhargavan
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a scheme for hybrid public-key encryption (HPKE). This scheme provides authenticated public key encryption of arbitrary-sized plaintexts for a recipient public key. HPKE works for any Diffie-Hellman group and has a strong security proof. We provide instantiations of the scheme using standard and efficient primitives.
    
draft-barnes-stir-passport-div-hi-callflows-02.txt
 Session Initiation Protocol (SIP) Call Flow Examples with PASSporT Diversion and History-Info
 
 draft-barnes-stir-passport-div-hi-callflows-02.txt
 Date: 23/10/2018
 Authors: Mary Barnes
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document focuses on use cases and call flows which include the History-Info header field and a SIP Identity header field with a PASSport with a "div" claim in cases of retargeting. These use cases are derived from those provided in the SIP History-Info call flows document. The objective is to describe the optimal way to correlate the History-Info header fields with a PASSporT with diversion information to increase the level of confidence in the History-Info header field by the terminating entity making use of the information.
    
draft-barre-mptcp-tfo-04.txt
 TFO support for Multipath TCP
 
 draft-barre-mptcp-tfo-04.txt
 Date: 22/11/2018
 Authors: Sebastien Barre, Gregory Detal, Olivier Bonaventure, Christoph Paasch
 Working Group: Individual Submissions (none)
 Formats: txt
TCP Fast Open (TFO) is a TCP extension that allows sending data in the SYN, instead of waiting until the TCP connection is established. This document describes what parts of Multipath TCP must be adapted to support it, and how TFO and MPTCP can operate together.
    
draft-barth-pce-segment-routing-policy-cp-02.txt
 PCEP extension to support Segment Routing Policy Candidate Paths
 
 draft-barth-pce-segment-routing-policy-cp-02.txt
 Date: 05/03/2019
 Authors: Colby Barth, Mike Koldychev, Siva Sivabalan, Cheng Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces a mechanism to specify an Segment Routing (SR) policy, as a collection of SR candidate paths. An SR policy is identified by tuple. An SR policy can contain one or more candidate paths where each candidate path is identified in PCEP via an PLSP-ID. This document proposes extension to PCEP to support association among candidate paths of a given SR policy. The mechanism proposed in this document is applicable to both MPLS and IPv6 data planes of SR.
    
draft-barthel-lpwan-oam-schc-00.txt
 OAM for LPWAN using Static Context Header Compression (SCHC)
 
 draft-barthel-lpwan-oam-schc-00.txt
 Date: 30/01/2019
 Authors: Dominique Barthel, Laurent Toutain, Arunprabhu Kandasamy, Diego Dujovne, Juan Zuniga
 Working Group: Individual Submissions (none)
 Formats: txt
With IP protocols now generalizing to constrained networks, users expect to be able to Operate, Administer and Maintain them with the familiar tools and protocols they already use on less constrained networks. OAM uses specific messages sent into the data plane to measure some parameters of a network. Most of the time, no explicit values are sent is these messages. Network parameters are obtained from the analysis of these specific messages. This can be used: o To detect if a host is up or down. o To measure the RTT and its variation over time. o To learn the path used by packets to reach a destination. OAM in LPWAN is a little bit trickier since the bandwidth is limited and extra traffic added by OAM can introduce perturbation on regular transmission. Two scenarios can be investigated: o OAM coming from internet. In that case, the NGW should act as a
    
draft-bashandy-isis-srv6-extensions-05.txt
 IS-IS Extensions to Support Routing over IPv6 Dataplane
 
 draft-bashandy-isis-srv6-extensions-05.txt
 Date: 06/03/2019
 Authors: Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane.
    
draft-beck-bgp-security-tracking-00.txt
 BGP Security Tracking
 
 draft-beck-bgp-security-tracking-00.txt
 Date: 01/03/2019
 Authors: Jody Beck, Andrew Gray
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the BGP Path Security Tracking attribute, an extension to BGP-4. This attribute provides a transitive means for networks to indicate BGP security checks in place to upstream networks. Upstream networks can optionally use that information to modify the path selection algorithm giving preference to paths reporting better security where the prefix length is the same and as-path length is similar. Effectively reporting no security would be treated the same as prepending the announcement once and reporting strong security would be treated the same as not prepending. The net result of using the information to influence path selection is that more secured paths would be preferred over less secured paths.
    
draft-bellis-dnsop-edns-tags-01.txt
 DNS EDNS Tags
 
 draft-bellis-dnsop-edns-tags-01.txt
 Date: 25/03/2019
 Authors: Ray Bellis, Alan Clegg, Peter van Dijk
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes EDNS Tags, a mechanism by which DNS clients and servers can transmit an opaque data field which has no defined semantic meaning other than as previously agreed between the client and server.
    
draft-bellis-dnsop-http-record-00.txt
 A DNS Resource Record for HTTP
 
 draft-bellis-dnsop-http-record-00.txt
 Date: 03/11/2018
 Authors: Ray Bellis
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an "HTTP" resource record type for the DNS to facilitate the lookup of the server hostname of HTTP(s) URIs. It is intended to replace the use of CNAME records for this purpose, and in the process provides a solution for the inability of the DNS to allow a CNAME to be placed at the apex of a domain name.
    
draft-belyavskiy-certificate-limitation-policy-07.txt
 Certificate Limitation Policy
 
 draft-belyavskiy-certificate-limitation-policy-07.txt
 Date: 25/11/2018
 Authors: Dmitry Belyavsky
 Working Group: Individual Submissions (none)
 Formats: xml txt
The document provides a specification of the application-level trust model. Being provided at the application level, the limitations of trust can be distributed separately using cryptographically protected format instead of hardcoding the checks into the application itself.
    
draft-belyavskiy-fakesni-02.txt
 Fake Server Name Indication
 
 draft-belyavskiy-fakesni-02.txt
 Date: 06/03/2019
 Authors: Dmitry Belyavsky
 Working Group: Individual Submissions (none)
 Formats: xml txt
The document provides a specification of the Fake Server Name Indication. Being implemented, the Fake SNI specification provides a way to cheat the monitoring solutions without providing any additional information to external observers.
    
draft-berger-manet-dlep-ether-credit-extension-02.txt
 DLEP IEEE 802.1Q Aware Credit Window Extension
 
 draft-berger-manet-dlep-ether-credit-extension-02.txt
 Date: 06/03/2019
 Authors: David Wiggins, Lou Berger
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an extension to the DLEP protocol that enables a Ethernet IEEE 802.1Q aware credit-window scheme for destination- specific and shared flow control.
    
draft-bernardos-anima-fog-monitoring-00.txt
 Autonomic setup of fog monitoring agents
 
 draft-bernardos-anima-fog-monitoring-00.txt
 Date: 11/03/2019
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
The concept of fog computing has emerged driven by the Internet of Things (IoT) due to the need of handling the data generated from the end-user devices. The term fog is referred to any networked computational resource in the continuum between things and cloud. In fog computing, functions can be stiched together composing a service function chain. These functions might be hosted on resources that are inherently heterogeneous, volatile and mobile. This means that resources might appear and disappear, and the connectivity characteristics between these resources may also change dynamically. This calls for new orchestration solutions able to cope with dynamic changes to the resources in runtime or ahead of time (in anticipation through prediction) as opposed to today's solutions which are inherently reactive and static or semi-static. A fog monitoring solution can be used to help predicting events so an action can be taken before an event actually takes place. This solution is composed of agents running on the fog nodes plus a controller hosted at another device (running in the infrastructure or in another fog node). Since fog environments are inherently volatile and extremely dynamic, it is convenient to enable the use of autonomic technologies to autonomously set-up the fog monitoring platform. This document aims at presenting this use case as well as specifying how to use GRASP as needed in this scenario.
    
draft-bernardos-dhc-slap-quadrant-01.txt
 SLAP quadrant selection options for DHCPv6
 
 draft-bernardos-dhc-slap-quadrant-01.txt
 Date: 08/03/2019
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Dynamic Host Configuration (dhc)
 Formats: txt
The IEEE originally structured the 48-bit MAC address space in such a way that half of it was reserved for local use. Recently, the IEEE has been working on a new specification (IEEE 802c) which defines a new "optional Structured Local Address Plan" (SLAP) that specifies different assignment approaches in four specified regions of the local MAC address space. The IEEE is working on mechanisms to allocate addresses in the one of these quadrants (IEEE 802.1CQ). There is work also in the IETF on specifying a new mechanism that extends DHCPv6 operation to handle the local MAC address assignments. In this document, we complement this ongoing IETF work by defining a mechanism to allow choosing the SLAP quadrant to use in the allocation of the MAC address to the requesting device/client. This document proposes extensions to DHCPv6 protocols to enable a DHCPv6 client or a DHCPv6 relay to indicate a preferred SLAP quadrant to the server, so that the server allocates the MAC address to the given client out of the quadrant requested by relay or client.
    
draft-bernardos-intarea-vim-discovery-01.txt
 IPv6-based discovery and association of Virtualization Infrastructure Manager (VIM) and Network Function Virtualization Orchestrator (NFVO)
 
 draft-bernardos-intarea-vim-discovery-01.txt
 Date: 25/02/2019
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Virtualized resources do not need to be limited to those available in traditional data centers, where the infrastructure is stable, static, typically homogeneous and managed by a single admin entity. Computational capabilities are becoming more and more ubiquitous, with terminal devices getting extremely powerful, as well as other types of devices that are close to the end users at the edge (e.g., vehicular onboard devices for infotainment, micro data centers deployed at the edge, etc.). It is envisioned that these devices would be able to offer storage, computing and networking resources to nearby network infrastructure, devices and things (the fog paradigm). These resources can be used to host functions, for example to offload/complement other resources available at traditional data centers, but also to reduce the end-to-end latency or to provide access to specialized information (e.g., context available at the edge) or hardware. This document describes mechanisms allowing dynamic discovery of virtualization resources and orchestrators in IPv6-based networks. In the current version, mechanisms based on piggybacking options on IPv6 neighbor discovery are explored. New IPv6 neighbor discovery options are defined. Additional mechanisms will be explored in future releases of this document.
    
draft-bernardos-nmrg-multidomain-00.txt
 Multi-domain Network Virtualization
 
 draft-bernardos-nmrg-multidomain-00.txt
 Date: 11/03/2019
 Authors: Carlos Bernardos, Luis Contreras, Ishan Vaishnavi, Robert Szabo, Xi Li, Francesco Paolucci, Andrea Sgambelluri, Barbara Martini, Luca Valcarenghi, Giada Landi, Dmitriy Andrushko, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the problem of multi-provider multi-domain orchestration, by first scoping the problem, then looking into potential architectural approaches, and finally describing the solutions being developed by the European 5GEx and 5G-TRANSFORMER projects.
    
draft-bernardos-sfc-discovery-02.txt
 Service Function discovery in fog environments
 
 draft-bernardos-sfc-discovery-02.txt
 Date: 07/03/2019
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. Service functions provide an specific treatment of received packets, therefore they need to be known so they can be used in a given service composition via SFC. This document discusses the need for service function discovery mechanisms and propose some solutions for sfc-aware nodes to discover available service functions in fog environments.
    
draft-bernardos-sfc-fog-ran-05.txt
 Service Function Chaining Use Cases in Fog RAN
 
 draft-bernardos-sfc-fog-ran-05.txt
 Date: 07/03/2019
 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-bernardos-spawn-use-cases-00.txt
 SPAWN use cases
 
 draft-bernardos-spawn-use-cases-00.txt
 Date: 25/03/2019
 Authors: Georgios Papadopoulos, Pascal Thubert, Fabrice Theoleyre, Carlos Bernardos
 Working Group: Individual Submissions (none)
 Formats: txt
The wireless medium presents significant specific challenges to achieve properties similar to those of wired deterministic networks. At the same time, a number of use cases cannot be solved with wires and justify the extra effort of going wireless. This document presents some of these use-cases.
    
draft-bertocci-oauth-access-token-jwt-00.txt
 JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
 
 draft-bertocci-oauth-access-token-jwt-00.txt
 Date: 24/03/2019
 Authors: Vittorio Bertocci
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines a profile for issuing OAuth2 access tokens in JSON web token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in interoperable manner.
    
draft-bertola-bcp-doh-clients-00.txt
 Recommendations for DNS Privacy Client Applications
 
 draft-bertola-bcp-doh-clients-00.txt
 Date: 10/03/2019
 Authors: Vittorio Bertola
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents operational, policy and security considerations for the authors and publishers of client applications that choose to implement DNS resolution through any of the protocols that provide private, encrypted connections between the application itself and the DNS resolver. As these protocols, depending on implementation choices and deployment models, may impact the Internet significantly at the architectural, legal and policy levels, the document records the current consensus on how these protocols should be used by applications, especially user-facing applications meant for mass usage by non-technical consumers.
    
draft-bhattacharyya-core-a-realist-02.txt
 Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)
 
 draft-bhattacharyya-core-a-realist-02.txt
 Date: 05/02/2019
 Authors: Abhijan Bhattacharyya, Suvrat Agrawal, Hemant Rath, Arpan Pal, Balamurali Purushothaman
 Working Group: Individual Submissions (none)
 Formats: txt
This draft presents extensions to Constrained Application Protocol (CoAP) to enable RESTful Real-time Live Streaming for improving the Quality of Experience (QoE) for delay-sensitive Internet of Things (IoT) applications. The overall architecture is termed "Adaptive RESTful Real-time Live Streaming for Things (A-REaLiST)". It is particularly designed for applications which rely on real-time augmented vision through live First Person View (FPV) feed from constrained remote agents like Unmanned Aerial Vehicle (UAV), etc. These extensions provide the necessary hooks to help solution designers ensure low-latency transfer of streams and, for contents like video, a quick recovery from freeze and corruption without incurring undue lag. A-REaLiST is an attempt to provide an integrated approach to maintain the balance amongst QoE, resource- efficiency and loss resilience. It provides the necessary hooks to optimize system performance by leveraging contextual intelligence inferred from instantaneous information segments in flight. These extensions equip CoAP with a standard for efficient RESTful streaming for Internet of Things (IoT) contrary to HTTP-streaming in conventional Internet.
    
draft-bi-savi-wlan-16.txt
 A SAVI Solution for WLAN
 
 draft-bi-savi-wlan-16.txt
 Date: 14/11/2018
 Authors: Jun Bi, Jianping Wu, You Wang, Tao Lin
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP packets to bind IP address to MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI(Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another.
    
draft-bierman-netconf-module-tag-ops-00.txt
 Module Tag Operations
 
 draft-bierman-netconf-module-tag-ops-00.txt
 Date: 10/03/2019
 Authors: Andy Bierman
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes enhancements to existing NETCONF and RESTCONF (NMDA) operations for using module tags to represent YANG datastore content. This can simplify usage of these operations by a client.
    
draft-birk-pep-03.txt
 pretty Easy privacy (pEp): Privacy by Default
 
 draft-birk-pep-03.txt
 Date: 07/03/2019
 Authors: Hernani Marques, Bernie Hoeneisen
 Working Group: Individual Submissions (none)
 Formats: xml txt
The pretty Easy privacy (pEp) protocols describe a set of conventions for the automation of operations traditionally seen as barriers to the use and deployment of secure end-to-end interpersonal messaging. These include, but are not limited to, key management, key discovery, and private key handling (including peer-to-peer synchronization of private keys and other user data across devices). pEp also introduces means to verify communication peers and proposes a trust-rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. Significantly, the pEp protocols build on already available security formats and message transports (e.g., PGP/MIME), and are written with the intent to be interoperable with already widely-deployed systems in order to facilitate and ease adoption and implementation. This document outlines the general design choices and principles of pEp.
    
draft-birk-pep-trustwords-03.txt
 IANA Registration of Trustword Lists: Guide,Template and IANA Considerations
 
 draft-birk-pep-trustwords-03.txt
 Date: 11/03/2019
 Authors: Volker Birk, Hernani Marques, Bernie Hoeneisen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the IANA Registration Guidelines for Trustwords, describes corresponding registration procedures, and provides a guideline for creating Trustword list specifications. Trustwords are common words in a natural language (e.g., English) to which the hexadecimal strings are mapped to. This makes verification processes (e.g., comparison of fingerprints), more practical and less prone to misunderstandings.
    
draft-birkholz-core-coid-01.txt
 Concise Identities
 
 draft-birkholz-core-coid-01.txt
 Date: 02/01/2019
 Authors: Henk Birkholz, Carsten Bormann, Max Pritikin, Robert Moskowitz
 Working Group: Individual Submissions (none)
 Formats: txt xml
There is an increased demand of trustworthy claim sets -- a set of system entity characteristics tied to an entity via signatures -- in order to provide information. Claim sets represented via CBOR Web Tokens (CWT) can compose a variety of evidence suitable for constrained-node networks and to support secure device automation. This document focuses on sets of identifiers and attributes that are tied to a system entity and are typically used to compose identities appropriate for Constrained RESTful Environment (CoRE) authentication needs.
    
draft-birkholz-rats-architecture-01.txt
 Architecture and Reference Terminology for Remote Attestation Procedures
 
 draft-birkholz-rats-architecture-01.txt
 Date: 11/03/2019
 Authors: Henk Birkholz, Monty Wiseman, Hannes Tschofenig, Ned Smith
 Working Group: Individual Submissions (none)
 Formats: txt xml
Remote ATtestation ProcedureS (RATS) architecture facilitates the attestation of device characteristics that, in general, are based on specific trustworthiness qualities intrinsic to a device or service. It includes trusted computing functionality provided by device hardware and software that allows trustworthiness qualities to be asserted and verified as part of, or pre-requisite to, the device's normal operation. The RATS architecture maps corresponding attestation functions and capabilities to specific RATS Roles. The goal is to enable an appropriate conveyance of evidence about device trustworthiness via network protocols. RATS Roles provide the endpoint context for understanding the various interaction semantics of the attestation lifecycle. The RATS architecture provides the building block concepts, semantics, syntax and framework for interoperable attestation while remaining hardware-agnostic. This flexibility is intended to address a significant variety of use-cases and scenarios involving interoperable attestation. Example usages include, but are not limited to: financial transactions, voting machines, critical safety systems, network equipment health, or trustworthy end-user device management. Existing industry attestation efforts may be helpful toward informing RATS architecture. Such as: Remote Integrity VERification (RIVER), the creation of Entity Attestation Tokens (EAT), software integrity Measurement And ATtestation (MAAT)
    
draft-birkholz-rats-basic-yang-module-00.txt
 YANG Module for Basic Challenge-Response-based Remote Attestation Procedures
 
 draft-birkholz-rats-basic-yang-module-00.txt
 Date: 11/03/2019
 Authors: Henk Birkholz, Michael Eckel, Shwetha Bhandari, Bill Sulzen, Eric Voit, Guy Fedorkow
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG RPC and a minimal datastore tree required to retrieve attestation evidence about integrity measurements from a composite device with one or more roots of trust for reporting. Complementary measurement logs are also provided by the YANG RPC originating from one or more roots of trust of measurement. The module defined requires a TPM 2.0 and corresponding Trusted Software Stack included in the device components of the composite device the YANG server is running on.
    
draft-birkholz-rats-reference-interaction-model-00.txt
 Reference Interaction Model for Challenge-Response-based Remote Attestation
 
 draft-birkholz-rats-reference-interaction-model-00.txt
 Date: 11/03/2019
 Authors: Henk Birkholz, Michael Eckel
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an interaction model for a basic remote attestation procedure. Additionally, the required information elements are illustrated.
    
draft-birkholz-rats-tuda-00.txt
 Time-Based Uni-Directional Attestation
 
 draft-birkholz-rats-tuda-00.txt
 Date: 11/03/2019
 Authors: Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo documents the method and bindings used to conduct time- based uni-directional attestation between distinguishable endpoints over the network.
    
draft-birkholz-yang-swid-02.txt
 Software Inventory YANG module based on Software Identifiers
 
 draft-birkholz-yang-swid-02.txt
 Date: 23/10/2018
 Authors: Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides a YANG module definition that enables a computing context to provide detailed information about installed software components. The structure of the module is based on the Concise Software Identifier draft and therefore also strongly related to the ISO 19770-2:2015 Software Identifiers standard. Both standards provide no interface to transport the SWID tag information between system entities and this document leverages the wide adoption of YANG based management interfaces.
    
draft-birrane-dtn-adm-agent-05.txt
 Asynchronous Management Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-agent-05.txt
 Date: 11/03/2019
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an Application Data Model (ADM) for an Asynchronous Management Protocol (AMP) Agent. The AMP Agent represents a managed device in the Asynchronous Management Architecture. This document is in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-bp-03.txt
 Bundle Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-bp-03.txt
 Date: 11/03/2019
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Application Data Model (ADM) for a Bundle Protocol Agent (BPA) in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ion-bpadmin-01.txt
 Bundle Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-ion-bpadmin-01.txt
 Date: 11/03/2019
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the administration of Bundle Protocol (BP) ION in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ion-ltpadmin-01.txt
 ION Licklider Transmission Protocol Admin Application Data Model
 
 draft-birrane-dtn-adm-ion-ltpadmin-01.txt
 Date: 11/03/2019
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the configuration of licklider transmission protocol (LTP) in ION in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ionadmin-01.txt
 ION Administration Application Data Model
 
 draft-birrane-dtn-adm-ionadmin-01.txt
 Date: 11/03/2019
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the administration of ION in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ionsec-01.txt
 ION Security Application Data Model
 
 draft-birrane-dtn-adm-ionsec-01.txt
 Date: 11/03/2019
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for ION Security in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ltp-01.txt
 Licklider Transmission Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-ltp-01.txt
 Date: 11/03/2019
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Application Data Model (ADM) for a Licklider Transmission Protocol Agent (LTPA) in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-amp-06.txt
 Asynchronous Management Protocol
 
 draft-birrane-dtn-amp-06.txt
 Date: 11/03/2019
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a binary encoding of the Asynchronous Management Model (AMM) and a protocol for the exchange of these encoded items over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing network management on resource constrained devices.
    
draft-bishop-httpbis-origin-fed-up-00.txt
 DNS Security with HTTP/2 ORIGIN
 
 draft-bishop-httpbis-origin-fed-up-00.txt
 Date: 08/01/2019
 Authors: Mike Bishop, Erik Nygren
 Working Group: Individual Submissions (none)
 Formats: txt xml
The definition of the HTTP/2 ORIGIN frame "relaxes" the requirement to check DNS for various reasons. However, experience has shown that such relaxation leads to security risks and is inadvisable. This document restores the original requirements.
    
draft-bkl-bimi-overview-00.txt
 An Overview of the Design of BIMI
 
 draft-bkl-bimi-overview-00.txt
 Date: 11/03/2019
 Authors: Seth Blank, Neil Kumaran, John Levine
 Working Group: Individual Submissions (none)
 Formats: txt xml
Brand Indicators for Message Identification (BIMI) provides a mechanism for mail senders to publish a validated logotype that mail receivers can display with the senders' messages. This document provides a brief overview of BIMI and examines some of the trade offs and decisions in its design. Discussion venue Comments on this draft may be directed to the BIMI list at bimi@ietf.org.
    
draft-blanchet-regext-entityid2rdapserver-00.txt
 Finding Additional Registration Data (RDAP) Service
 
 draft-blanchet-regext-entityid2rdapserver-00.txt
 Date: 11/03/2019
 Authors: Marc Blanchet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a method to find which Registration Data Access Protocol (RDAP) server is authoritative to answer additional information for a query already answered by another server. It is based on an entity id to RDAP server location mapping registry managed by IANA. One use case of this specification is the domain registry RDAP server providing a referral URL to the registrar RDAP server, based on the registrar entity id, for information that the registrar is authoritative for such as the contact or reseller information.
    
draft-blank-ietf-bimi-00.txt
 Brand Indicators for Message Identification (BIMI)
 
 draft-blank-ietf-bimi-00.txt
 Date: 06/02/2019
 Authors: Seth Blank, Peter Goldstein, Thede Loder, Terry Zink
 Working Group: Individual Submissions (none)
 Formats: xml txt
Brand Indicators for Message Identification (BIMI) permits Domain Owners to coordinate with Mail User Agents (MUAs) to display brand- specific Indicators next to properly authenticated messages. There are two aspects of BIMI coordination: a scalable mechanism for Domain Owners to publish their desired indicators, and a mechanism for Mail Transfer Agents (MTAs) to verify the authenticity of the indicator. This document specifies how Domain Owners communicate their desired indicators through the BIMI assertion record in DNS and how that record is to be handled by MTAs and MUAs. The domain verification mechanism and extensions for other mail protocols (IMAP, etc.) are specified in separate documents. MUAs and mail-receiving organizations are free to define their own policies for indicator display that makes use or not of BIMI data as they see fit.
    
draft-boneh-bls-signature-00.txt
 BLS Signature Scheme
 
 draft-boneh-bls-signature-00.txt
 Date: 08/02/2019
 Authors: Dan Boneh, Sergey Gorbunov, Hoeteck Wee, Zhenfei Zhang
 Working Group: Individual Submissions (none)
 Formats: txt
The BLS signature scheme was introduced by Boneh-Lynn-Shacham in 2001. The signature scheme relies on pairing-friendly curves and supports non-interactive aggregation properties. That is, given a collection of signatures (sigma_1, ..., sigma_n), anyone can produce a short signature (sigma) that authenticates the entire collection. BLS signature scheme is simple, efficient and can be used in a variety of network protocols and systems to compress signatures or certificate chains. This document specifies the BLS signature and the aggregation algorithms.
    
draft-bonica-6man-comp-rtg-hdr-03.txt
 The IPv6 Compressed Routing Header (CRH)
 
 draft-bonica-6man-comp-rtg-hdr-03.txt
 Date: 24/03/2019
 Authors: Ron Bonica, Ning So, Fengman Xu, Gang Chen, Yongqing Zhu, Guangming Yang, Yifeng Zhou
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the Compressed Routing Header (CRH). The CRH, like any other Routing header, contains a list of segment identifiers (SID). The CRH differs from other Routing headers in that its segment identifiers can be 8, 16 or 32 bits long.
    
draft-bonica-6man-oam-03.txt
 OAM Capabilities for IPv6
 
 draft-bonica-6man-oam-03.txt
 Date: 24/03/2019
 Authors: Ron Bonica, Ning So, Fengman Xu, Gang Chen, Yongqing Zhu, Guangming Yang, Yifeng Zhou
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines new IPv6 Operations and Management (OAM) capabilities. In order to support these new capabilities, this document defines an IPv6 OAM Option and an ICMPv6 OAM message.
    
draft-bonica-6man-seg-end-opt-03.txt
 The IPv6 Segment Endpoint Option
 
 draft-bonica-6man-seg-end-opt-03.txt
 Date: 24/03/2019
 Authors: Ron Bonica, Joel Halpern, Ning So, Fengman Xu, Gang Chen, Yongqing Zhu, Guangming Yang, Yifeng Zhou
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the IPv6 Segment Endpoint Option. Source nodes can use this option to convey internet-layer information to selected segment endpoints along a packet's delivery path.
    
draft-bonica-6man-vpn-dest-opt-05.txt
 The IPv6 Virtual Private Network (VPN) Context Information Option
 
 draft-bonica-6man-vpn-dest-opt-05.txt
 Date: 24/03/2019
 Authors: Ron Bonica, Chris Lenart, Ning So, Fengman Xu, Greg Presbury, Gang Chen, Yongqing Zhu, Guangming Yang, Yifeng Zhou
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a new IPv6 Destination Option that can be used to encode Virtual Private Network (VPN) context information. It is applicable when VPN payload is transported over IPv6.
    
draft-borchert-sidrops-bgpsec-state-unverified-01.txt
 BGPsec Validation State Unverified
 
 draft-borchert-sidrops-bgpsec-state-unverified-01.txt
 Date: 15/04/2019
 Authors: Oliver Borchert, Doug Montgomery
 Working Group: Individual Submissions (none)
 Formats: txt
In case operators decide to delay BGPsec path validation, none of the available states do properly represent this decision. This document introduces "Unverified" as a well-defined validation state which allows to properly identify a non-evaluated BGPsec routes as not verified.
    
draft-borchert-sidrops-bgpsec-validation-signaling-00.txt
 BGPsec Validation State Signaling
 
 draft-borchert-sidrops-bgpsec-validation-signaling-00.txt
 Date: 26/03/2019
 Authors: Oliver Borchert, Doug Montgomery
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a new BGP opaque extended community to carry the BGPsec path validation state inside an autonomous system. Internal BGP (IBGP) speakers that receive this community string can use the embedded BGPsec validation state and configure local policies that allow it being used to influence their decision process. This is specially helpful because (Section 5) of [RFC8205] specifically allows putting BGPsewc path validation temporarily on hold. This would allow to reduce the load of validation especially from IBGP learned routes.
    
draft-borchert-sidrops-rpki-state-unverified-01.txt
 RPKI Route Origin Validation State Unverified
 
 draft-borchert-sidrops-rpki-state-unverified-01.txt
 Date: 14/02/2019
 Authors: Oliver Borchert, Doug Montgomery
 Working Group: Individual Submissions (none)
 Formats: txt
In case operators decide not to evaluate BGP route prefixes according to RPKI route origin validation (ROV), none of the available states as specified in RFC 6811 do properly represent this decision. This document introduces "Unverified" as well-defined validation state which allows to properly identify route prefixes as not evaluated according to RPKI route origin validation.
    
draft-bormann-cbor-sequence-00.txt
 Concise Binary Object Representation (CBOR) Sequences
 
 draft-bormann-cbor-sequence-00.txt
 Date: 24/02/2019
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Concise Binary Object Representation (CBOR) Sequence format and associated media type "application/cbor- seq". A CBOR Sequence consists of any number of encoded CBOR data items, simply concatenated in sequence. Structured syntax suffixes for media types allow other media types to build on them and make it explicit that they are built on an existing media type as their foundation. This specification defines and registers "+cbor-seq" as a structured syntax suffix for CBOR Sequences.
    
draft-bormann-cbor-time-tag-02.txt
 Concise Binary Object Representation (CBOR) Tags for Time,Duration,and Period
 
 draft-bormann-cbor-time-tag-02.txt
 Date: 22/10/2018
 Authors: Carsten Bormann, Ben Gamari, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt
The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. RFC 7049 defines two tags for time: CBOR tag 0 (RFC3339 time) and tag 1 (Posix time [TIME_T], int or float). Since then, additional requirements have become known. The present document defines a CBOR tag for time that allows a more elaborate representation of time, and anticipates the definition of related CBOR tags for duration and time period. It is intended as the reference document for the IANA registration of the CBOR tags defined.
    
draft-bormann-core-ace-aif-06.txt
 An Authorization Information Format (AIF) for ACE
 
 draft-bormann-core-ace-aif-06.txt
 Date: 29/03/2019
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
Constrained Devices as they are used in the "Internet of Things" need security. One important element of this security is that devices in the Internet of Things need to be able to decide which operations requested of them should be considered authorized, need to ascertain that the authorization to request the operation does apply to the actual requester, and need to ascertain that other devices they place requests on are the ones they intended. On the ACE mailing list, an activity to create specifications for such authenticated authorization for constrained devices is contemplated, leading to protocol proposals such as [I-D.ietf-ace-dtls-authorize] or [I-D.seitz-ace-oscoap-profile]. One potential work item complementing this protocol work is an Authorization Information Format (AIF). This document provides a strawman for such a format that should enable further discussion of the objectives for its development.
    
draft-bormann-core-corr-clar-00.txt
 Constrained Application Protocol (CoAP): Corrections and Clarifications
 
 draft-bormann-core-corr-clar-00.txt
 Date: 23/10/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
RFC 7252 defines the Constrained Application Protocol (CoAP), along with a number of additional specifications, including RFC 7641, RFC 7959, RFC 8132, and RFC 8323. RFC 6690 defines the link format that is used in CoAP self-description documents. Some parts of the specification may be unclear or even contain errors that may lead to misinterpretations that may impair interoperability between different implementations. The present document provides corrections, additions, and clarifications to the RFCs cited; this document thus updates these RFCs. In addition, other clarifications related to the use of CoAP in other specifications, including RFC 7390 and RFC 8075, are also provided.
    
draft-bormann-core-media-content-type-format-00.txt
 On Media-Types,Content-Types,and related terminology
 
 draft-bormann-core-media-content-type-format-00.txt
 Date: 11/03/2019
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
There is a lot of confusion about media-types, content-types, and related terminology. This memo is an attempt at clearing it up.
    
draft-bormann-lwig-7228bis-04.txt
 Terminology for Constrained-Node Networks
 
 draft-bormann-lwig-7228bis-04.txt
 Date: 11/03/2019
 Authors: Carsten Bormann, Mehmet Ersue, Ari Keranen, Carles Gomez
 Working Group: Individual Submissions (none)
 Formats: txt
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.
    
draft-bormann-senml-more-units-00.txt
 Additional Units for SenML
 
 draft-bormann-senml-more-units-00.txt
 Date: 27/02/2019
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
The Sensor Measurement Lists (SenML) media type supports the indication of units for a quantity represented. This short document registers a number of additional unit names in the IANA registry for Units in SenML.
    
draft-bormann-t2trg-sworn-02.txt
 SWORN: Secure Wake on Radio Nudging
 
 draft-bormann-t2trg-sworn-02.txt
 Date: 22/10/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
Normally off devices (RFC7228) would need to expend considerable energy resources to be reachable at all times. Instead, MAC layer mechanisms are often employed that allow the last hop router of the device to "wake" the device via radio when needed. Activating these devices even for a short time still does expend energy and thus should be available to authorized correspondents only. Traditionally, this has been achieved by heavy firewalling, allowing only authorized hosts to reach the device at all. This may be too inflexible for an Internet of Things. The present report describes how to use a combination of currently standardized (or in progress) technologies to securely effect this authorization.
    
draft-bormann-wk-uri-00.txt
 Recording Well-Known URI Capability in the URI Scheme Registry
 
 draft-bormann-wk-uri-00.txt
 Date: 04/04/2019
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
RFC 5785 defines a path prefix, "/.well-known/", that can be used by well-known URIs, specifically for the "http" and "https" URI schemes, which has since been adopted by other URI schemes. The present memo formally updates RFC 7595, which defines the URI schemes regustry, to record the availability of these well-known URIs to the URI schemes registered there.
    
draft-bortzmeyer-dprive-rfc7626-bis-02.txt
 DNS Privacy Considerations
 
 draft-bortzmeyer-dprive-rfc7626-bis-02.txt
 Date: 15/01/2019
 Authors: Stephane Bortzmeyer, Sara Dickinson
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions. This document obsoletes RFC 7626.
    
draft-boucadair-dots-earlydata-00.txt
 Using Early Data in DOTS
 
 draft-boucadair-dots-earlydata-00.txt
 Date: 29/01/2019
 Authors: Mohamed Boucadair, Reddy K
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses to what extent it is safe to send DOTS signal channel messages as Early Data in TLS 1.3. This document is not intended to be published as an RFC. It is edited to help understanding the conclusion about the safeness of using DOTS signal channel messages as early data.
    
draft-boucadair-netmod-softwire-iftunnel-00.txt
 A Tunnel Extension to the Interface Management YANG Module
 
 draft-boucadair-netmod-softwire-iftunnel-00.txt
 Date: 19/10/2018
 Authors: Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies an extension the Interface Management YANG module. Editorial Note (To be removed by RFC Editor) Please update these statements in the document with the RFC number to be assigned to this document: o "This version of this YANG module is part of RFC XXXX;" o "RFC XXXX: A Tunnel Extension to the Interface Management YANG Module"; o "reference: RFC XXXX" Please update the "revision" date of the YANG module.
    
draft-boucadair-radext-tcpm-converter-02.txt
 RADIUS Extensions for 0-RTT TCP Converters
 
 draft-boucadair-radext-tcpm-converter-02.txt
 Date: 15/04/2019
 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 Converters. Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attributes that carry the IP addresses that will be returned to authorized users to reach one or multiple Converters.
    
draft-boucadair-tcpm-dhc-converter-02.txt
 DHCP Options for 0-RTT TCP Converters
 
 draft-boucadair-tcpm-dhc-converter-02.txt
 Date: 15/04/2019
 Authors: Mohamed Boucadair, Christian Jacquenet, Reddy K
 Working Group: Individual Submissions (none)
 Formats: xml txt
Because of the lack of Multipath TCP (MPTCP) support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called Converters. Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document focuses on the explicit deployment scheme where the identity of the Converters is explicitly configured on connected hosts. This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Converters parameters.
    
draft-bouilland-polystring-02.txt
 Multi-languages string: Polystring
 
 draft-bouilland-polystring-02.txt
 Date: 15/02/2019
 Authors: Aurelien Bouilland
 Working Group: Individual Submissions (none)
 Formats: txt
Managing multi-languages support for a service with autonomous parts can be complex. Having its internal parts be polyglot, and coalece to end-user's language only on display is one solution. This paper discuss a format to store, exchange, and algorithms to consume multi-language strings to this goal.
    
draft-bourbaki-6man-classless-ipv6-05.txt
 IPv6 is Classless
 
 draft-bourbaki-6man-classless-ipv6-05.txt
 Date: 17/04/2019
 Authors: Nicolas Bourbaki
 Working Group: Individual Submissions (none)
 Formats: txt
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing.
    
draft-boutros-bess-evpn-geneve-04.txt
 EVPN control plane for Geneve
 
 draft-boutros-bess-evpn-geneve-04.txt
 Date: 06/03/2019
 Authors: Sami Boutros, Ali Sajassi, John Drake, Jorge Rabadan, Sam Aldrin
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how Ethernet VPN (EVPN) control plane can be used with Network Virtualization Overlay over Layer 3 (NVO3) Generic Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 solutions. EVPN control plane can also be used by a Network Virtualization Endpoints (NVEs) to express Geneve tunnel option TLV(s)supported in transmission and/or reception of Geneve encapsulated data packets.
    
draft-boutros-nvo3-geneve-applicability-for-sfc-03.txt
 Geneve applicability for service function chaining
 
 draft-boutros-nvo3-geneve-applicability-for-sfc-03.txt
 Date: 06/03/2019
 Authors: Sami Boutros, Dharma Rajan, Philip Kippen, Pierluigi Rolando, Jim Guichard, Sam Aldrin
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of using Generic Network Virtualization Encapsulation (Geneve), to carry the service function path (SFP) information, and the network service header (NSH) encapsulation. The SFP information will be carried in Geneve option TLV(s).
    
draft-boydseda-ipfix-psamp-bulk-data-yang-model-01.txt
 YANG Data Models for the IP Flow Information Export (IPFIX) Protocol,Packet Sampling (PSAMP) Protocol,and Bulk Data Export
 
 draft-boydseda-ipfix-psamp-bulk-data-yang-model-01.txt
 Date: 11/03/2019
 Authors: Joey Boyd, Marta Seda
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a flexible modular YANG model for packet sampling (PSAMP) and bulk data collection and export via the IPFIX protocol. This new model is an alternative to the model defined in RFC 6728, "Configuration Data Model for the IP Flow Information Export (IPFIX) and Packet Sampling (PSAMP) Protocols". All functionality modeled in RFC 6728 has been carried over to this new model. The YANG data model in this document conforms to the Network Management Datastore Architecture (NMDA) defined in RFC 8342. This document obsoletes RFC 6728 (if approved).
    
draft-bradley-dnssd-private-discovery-01.txt
 Private Discovery
 
 draft-bradley-dnssd-private-discovery-01.txt
 Date: 20/04/2019
 Authors: Bob Bradley
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a mechanism for advertising and discovering in a private manner.
    
draft-bradley-oauth-jwt-encoded-state-09.txt
 Encoding claims in the OAuth 2 state parameter using a JWT
 
 draft-bradley-oauth-jwt-encoded-state-09.txt
 Date: 04/11/2018
 Authors: John Bradley, Torsten Lodderstedt, Hans Zandbelt
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft provides a method for a client to encode one or more elements encoding information about the session into the OAuth 2 "state" parameter.
    
draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
 DNS-over-TLS for insecure delegations
 
 draft-bretelle-dprive-dot-for-insecure-delegations-01.txt
 Date: 11/03/2019
 Authors: Emmanuel Bretelle
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an alternative mechanism to DANE ([RFC6698]) in order to authenticate a DNS-over-TLS (DoT [RFC7858]) authoritative server by not making DNSSEC a hard requirement, making DoT server authentication available for insecure delegations.
    
draft-bretelle-dprive-dot-spki-in-ns-name-00.txt
 Encoding DNS-over-TLS (DoT) Subject Public Key Info (SPKI) in Name Server name
 
 draft-bretelle-dprive-dot-spki-in-ns-name-00.txt
 Date: 11/03/2019
 Authors: Emmanuel Bretelle
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a mechanism to exchange the Subject Public Key Info (SPKI) ([RFC5280] Section 4.1.2.7) fingerprint associated with a DNS-over-TLS (DoT [RFC7858]) authoritative server by encoding it as part of its name. The fingerprint can thereafter be used to validate the certificate received from the DoT server as well as being able to discover support for DoT on the server.
    
draft-briscoe-tsvwg-l4s-diffserv-02.txt
 Interactions between Low Latency,Low Loss,Scalable Throughput (L4S) and Differentiated Services
 
 draft-briscoe-tsvwg-l4s-diffserv-02.txt
 Date: 04/11/2018
 Authors: Bob Briscoe
 Working Group: Individual Submissions (none)
 Formats: xml txt
L4S and Diffserv offer somewhat overlapping services (low latency and low loss), but bandwidth allocation is out of scope for L4S. Therefore there is scope for the two approaches to complement each other, but also to conflict. This informational document explains how the two approaches interact, how they can be arranged to complement each other and in which cases one can stand alone without needing the other.
    
draft-brissette-bess-evpn-l2gw-proto-04.txt
 EVPN Multi-Homing Mechanism for Layer-2 Gateway Protocols
 
 draft-brissette-bess-evpn-l2gw-proto-04.txt
 Date: 11/03/2019
 Authors: Patrice Brissette, Ali Sajassi, LucAndre Burdet, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
The existing EVPN multi-homing load-balancing modes defined are Single-Active and All-Active. Neither of these multi-homing mechanisms are appropriate to support access networks with Layer-2 Gateway protocols such as G.8032, MPLS-TP, STP, etc. These Layer-2 Gateway protocols require a new multi-homing mechanism defined in this draft.
    
draft-brissette-bess-evpn-mh-pa-03.txt
 EVPN multi-homing port-active load-balancing
 
 draft-brissette-bess-evpn-mh-pa-03.txt
 Date: 11/03/2019
 Authors: Patrice Brissette, Samir Thoria, Ali Sajassi
 Working Group: Individual Submissions (none)
 Formats: txt
The Multi-Chassis Link Aggregation Group (MC-LAG) technology enables the establishment of a logical port-channel connection with a redundant group of independent nodes. The purpose of multi-chassis LAG is to provide a solution to achieve higher network availability, while providing different modes of sharing/balancing of traffic. EVPN standard defines EVPN based MC-LAG with single-active and all-active multi-homing load-balancing mode. The current draft expands on existing redundancy mechanisms supported by EVPN and introduces support of port-active load-balancing mode. In the current draft, port-active load-balancing mode is also referred to as per interface active/standby.
    
draft-brockhaus-lamps-industrial-cmp-profile-00.txt
 Lightweight Industrial CMP Profile
 
 draft-brockhaus-lamps-industrial-cmp-profile-00.txt
 Date: 11/03/2019
 Authors: Hendrik Brockhaus, Steffen Fries, David von Oheimb
 Working Group: Individual Submissions (none)
 Formats: txt xml
The goal of this document is to facilitate interoperability and automation by profiling the Certificate Management Protocol (CMP) [RFC4210] and the related Certificate Request Message Format (CRMF) [RFC4211]. It specifies a subset of CMP and CRMF focusing on typical uses cases relevant for managing certificates of devices in industrial and IoT scenarios. To limit the overhead of certificate management for constrained devices only the most crucial types of transactions are specified as mandatory. To foster interoperability also in more complex scenarios, other types of transactions are specified as recommended or optional.
    
draft-brockners-ippm-ioam-geneve-02.txt
 Geneve encapsulation for In-situ OAM Data
 
 draft-brockners-ippm-ioam-geneve-02.txt
 Date: 11/03/2019
 Authors: Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Petr Lapukhov, Barak Gafni, Aviv Kfir, Mickey Spiegel
 Working Group: Individual Submissions (none)
 Formats: txt xml
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in Geneve.
    
draft-brotman-ietf-bimi-guidance-00.txt
 Receivers Guidance for Implementing Branded Indicators for Message Identification (BIMI)
 
 draft-brotman-ietf-bimi-guidance-00.txt
 Date: 06/02/2019
 Authors: Alexander Brotman, Terry Zink
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is meant to assist receivers or other mailbox providers by providing guidance to implementing Brand Indicators for Message Identification (BIMI). This document is a companion to the main BIMI drafts which should first be consulted and reviewed.
    
draft-brotman-rdbd-01.txt
 Related Domains By DNS
 
 draft-brotman-rdbd-01.txt
 Date: 06/03/2019
 Authors: Alexander Brotman, Stephen Farrell
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document outlines a mechanism by which a registered domain can publicly document a relationship with a different registered domain, called "Related Domains By DNS", or "RDBD".
    
draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-03.txt
 Elliptic curve 2y^2=x^3+x over field size 8^91+5
 
 draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-03.txt
 Date: 04/04/2019
 Authors: Dan Brown
 Working Group: Individual Submissions (none)
 Formats: txt
This document recommends using a special elliptic curve alongside dissimilar curves, such as NIST P-256, Curve25519, sect283k1, Brainpool, and random curves, as a cryptographic defense against an unlikely, undisclosed attack against mainstream curves. Features of this curve 2y^2=x^3+x/GF(8^91+5) are: isomorphism to Miller curves from 1985; Montgomery form mappable to Edwards; simple field powering for inversion, Legendre symbol, and square roots; efficient endomorphism to speed up Diffie--Hellman with Bernstein's 2-D ladder; 34-byte keys; similarity to Bitcoin curve; hashing-to-point; low Kolmogorov complexity (low risk of backdoor).
    
draft-brown-epp-contacts-in-rdap-00.txt
 Extensible Provisioning Protocol (EPP) Contact Mapping for Registration Data Access Protocol (RDAP) JSON Responses
 
 draft-brown-epp-contacts-in-rdap-00.txt
 Date: 18/02/2019
 Authors: Gavin Brown
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes how EPP contact objects can be represented in RDAP entities.
    
draft-browne-sfc-nsh-kpi-stamp-07.txt
 A Key Performance Indicators (KPI) Stamping for the Network Service Header (NSH)
 
 draft-browne-sfc-nsh-kpi-stamp-07.txt
 Date: 25/02/2019
 Authors: Rory Browne, Andrey Chilikin, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a method of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH). This method may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.
    
draft-bruckert-brainpool-for-tls13-02.txt
 ECC Brainpool Curves for Transport Layer Security (TLS) Version 1.3
 
 draft-bruckert-brainpool-for-tls13-02.txt
 Date: 06/02/2019
 Authors: Leonie Bruckert, Johannes Merkle, Manfred Lochter
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This document specifies the use of several ECC Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.3.
    
draft-bryant-mpls-sfl-control-03.txt
 MPLS Flow Identification Considerations
 
 draft-bryant-mpls-sfl-control-03.txt
 Date: 09/01/2019
 Authors: Stewart Bryant, George Swallow, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: txt xml
In draft-ietf-mpls-sfl-framework the concept of MPLS synonymous flow labels (SFL) was introduced. This document describes a control protocol that runs over an associated control header to request, withdrawn and extend the lifetime of such labels.
    
draft-bryskin-teas-service-tunnel-steering-model-02.txt
 Basic YANG Model for Steering Client Services To Server Tunnels
 
 draft-bryskin-teas-service-tunnel-steering-model-02.txt
 Date: 26/02/2019
 Authors: Igor Bryskin, Vishnu Beeram, Tarek Saad, Xufeng Liu, Young Lee
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG data model for managing pools of transport tunnels and steering client services on them.
    
draft-busi-pals-pw-cw-stitching-01.txt
 Pseudowire (PW) Control Word (CW) Stitching
 
 draft-busi-pals-pw-cw-stitching-01.txt
 Date: 22/10/2018
 Authors: Italo Busi, Stewart Bryant, Andrew Malis, Jie Dong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the behavior of a new type of Multi-Segment Pseudowire (MS-PW) Switching PE (S-PE) which enhances the S-PE functions defined in [RFC 6073], with the capability to switch an Ethernet pseudowire (PW) segment that uses the PW Control Word (CW) [RFC 4385] with an Ethernet PW segment that does not use the CW. This new type of S-PE can be deployed in the network one hop away, at the MPLS layer, from a Terminating PE (T-PE) which does not support CW for Ethernet PW encapsulation [RFC 4448]. In this way, all the Ethernet PW packets sent though the MPLS network will have the CW and be protected against incorrect equal-cost-multi-path (ECMP) behavior as described in [I-D ETH-CW].
    
draft-busizheng-teas-mpls-tp-yang-00.txt
 YANG Data Models for Multiprotocol Label Switching - Transport Profile
 
 draft-busizheng-teas-mpls-tp-yang-00.txt
 Date: 11/03/2019
 Authors: Italo Busi, Haomian Zheng
 Working Group: Individual Submissions (none)
 Formats: txt
Multi-protocol Label Switching - Transport Profile (MPLS-TP) is a profile of the MPLS protocol that is used in packet switched transport networks and operated in a similar manner to other existing transport technologies (e.g., OTN), as described in RFC5921. This document specifies YANG models for MPLS-TP, which have not been covered by existing models so far. The gap analysis with current relevant traffic-engineering (TE) and MPLS models is also included.
    
draft-camarillo-dmm-srv6-mobile-pocs-01.txt
 Segment Routing IPv6 for mobile user-plane PoCs
 
 draft-camarillo-dmm-srv6-mobile-pocs-01.txt
 Date: 22/10/2018
 Authors: Pablo Camarillo, Clarence Filsfils, Lyle Bertz, Arashmid Akhavain, Satoru Matsushima, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the ongoing proof of concepts of [I-D.ietf-dmm-srv6-mobile-uplane] and their progress.
    
draft-camarilloelmalky-springdmm-srv6-mob-usecases-01.txt
 SRv6 Mobility Use-Cases
 
 draft-camarilloelmalky-springdmm-srv6-mob-usecases-01.txt
 Date: 15/01/2019
 Authors: Pablo Camarillo, Clarence Filsfils, Hani Elmalky, Satoru Matsushima, daniel.voyer@bell.ca, Anna Cui, Bart Peirens
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the SRv6 use-cases in the mobile network in association with different mobile generations (3G, 4G, and 5G). It also highlights potential interworking with SR-MPLS in relevant use- cases.
    
draft-campagna-tls-bike-sike-hybrid-00.txt
 BIKE and SIKE Hybrid Key Exchange Cipher Suites for Transport Layer Security (TLS)
 
 draft-campagna-tls-bike-sike-hybrid-00.txt
 Date: 27/03/2019
 Authors: Matt Campagna, Eric Crockett
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document describes new hybrid key exchange schemes for the Transport Layer Security (TLS) protocol, which are based on combining Elliptic Curve Diffie Hellman (ECDH) with one of the Bit Flipping Key Exchange (BIKE) or the Supersingular Isogeny Key Exchange (SIKE) schemes. In particular, this document specifies the use of BIKE or SIKE in combination with ECDHE as a hybrid key agreement in a TLS 1.2 handshake, together with the use of ECDSA or RSA for authentication. Hybrid key exchange refers to executing two separate key exchanges and subsequently feeding the two resulting shared secrets into the existing TLS Pseudo Random Function (PRF), in order to derive a master secret.
    
draft-campbell-sip-messaging-smime-05.txt
 SIP-based Messaging with S/MIME
 
 draft-campbell-sip-messaging-smime-05.txt
 Date: 26/01/2019
 Authors: Ben Campbell, Russ Housley
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFC 3261, RFC 3428, and RFC 4975.
    
draft-camwinget-tls-ts13-macciphersuites-02.txt
 TLS 1.3 Authentication and Integrity only Ciphersuites
 
 draft-camwinget-tls-ts13-macciphersuites-02.txt
 Date: 20/12/2018
 Authors: Nancy Cam-Winget, Jack Visoky
 Working Group: Individual Submissions (none)
 Formats: txt xml
There are use cases, specifically in Internet of Things (IoT) and constrained environments that do not require confidentiality, though mutual authentication during tunnel establishment and message integrity is still mandated. This document defines the use of HMAC only as ciphersuites in TLS 1.3.
    
draft-camwinget-tls-use-cases-04.txt
 TLS 1.3 Impact on Network-Based Security
 
 draft-camwinget-tls-use-cases-04.txt
 Date: 10/03/2019
 Authors: Flemming Andreasen, Nancy Cam-Winget, Eric Wang
 Working Group: Individual Submissions (none)
 Formats: xml txt
Network-based security solutions are used by enterprises, public sector, and cloud service providers today in order to both complement and enhance host-based security solutions. TLS 1.3 introduces several changes to TLS 1.2 with a goal to improve the overall security and privacy provided by TLS. However some of these changes have a negative impact on network-based security solutions and deployments that adopt a multi-layered approach to security. While this may be viewed as a feature, there are several real-life use case scenarios where the same functionality and security can not be offered without such network-based security solutions. In this document, we identify the TLS 1.3 changes that may impact such use cases.
    
draft-carpenter-anima-asa-guidelines-06.txt
 Guidelines for Autonomic Service Agents
 
 draft-carpenter-anima-asa-guidelines-06.txt
 Date: 06/01/2019
 Authors: Brian Carpenter, Laurent Ciavaglia, Sheng Jiang, Peloso Pierre
 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-carpenter-anima-grasp-bulk-03.txt
 Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP)
 
 draft-carpenter-anima-grasp-bulk-03.txt
 Date: 06/01/2019
 Authors: Brian Carpenter, Sheng Jiang, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes how bulk data may be transferred between Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol (GRASP).
    
draft-carpenter-anima-l2acp-scenarios-00.txt
 Scenarios and Requirements for Layer 2 Autonomic Control Planes
 
 draft-carpenter-anima-l2acp-scenarios-00.txt
 Date: 27/02/2019
 Authors: Brian Carpenter, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses scenarios and requirements for Autonomic Control Planes (ACPs) constructed and secured at Layer 2. These would be alternatives to an ACP constructed and secured at the network layer. A secure ACP is required as the substrate for the Generic Autonomic Signaling Protocol (GRASP) used by Autonomic Service Agents.
    
draft-carpenter-limited-domains-07.txt
 Limited Domains and Internet Protocols
 
 draft-carpenter-limited-domains-07.txt
 Date: 15/04/2019
 Authors: Brian Carpenter, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains, also known as controlled environments, and emerging solutions, and includes a related taxonomy. It then briefly discusses the standardization of protocols for limited domains. Finally, it shows the needs for a precise definition of limited domain membership and for mechanisms to allow nodes to join a domain securely and to find other members, including boundary nodes.
    
draft-carrel-ipsecme-controller-ike-01.txt
 IPsec Key Exchange using a Controller
 
 draft-carrel-ipsecme-controller-ike-01.txt
 Date: 10/03/2019
 Authors: David Carrel, Brian Weis
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a key exchange method allowing devices managed by a controller (e.g., an SDN management station) to create private pair-wise IPsec SAs without IKEv2 or any other direct peer-to-peer session establishment messages. The method can be used when a full mesh of IKEv2 sessions between IPsec devices is not appropriate.
    
draft-cc-lsr-flooding-reduction-03.txt
 LS Distributed Flooding Reduction
 
 draft-cc-lsr-flooding-reduction-03.txt
 Date: 11/03/2019
 Authors: Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang, Aijun Wang, Xufeng Liu, Yanhe Fan, Lei Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an approach to flood link states on a topology that is a subgraph of the complete topology per underline physical network, so that the amount of flooding traffic in the network is greatly reduced, and it would reduce convergence time with a more stable and optimized routing environment. The approach can be applied to any network topology in a single area. In this approach, every node in the area automatically calculates a flooding topology by using a same algorithm concurrently.
    
draft-ce-lsr-ppr-graph-01.txt
 Preferred Path Route Graph Structure
 
 draft-ce-lsr-ppr-graph-01.txt
 Date: 23/10/2018
 Authors: Uma Chunduri, Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a graph structure for the Preferred Path Route (PPR) for IS-IS, OSPFv2 and OSPFv3 protocols. This structure helps further scale of the PPR and reduce domain level global entries needed in some data planes.
    
draft-cel-nfsv4-comp-stor-reqs-00.txt
 Network File System Requirements for Computational Storage
 
 draft-cel-nfsv4-comp-stor-reqs-00.txt
 Date: 25/03/2019
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces an architecture for supporting Computational Storage on Network File System version 4 (NFS) servers and clients.
    
draft-cel-nfsv4-reminv-design-09.txt
 Using Remote Invalidation With RPC-Over-RDMA Transports
 
 draft-cel-nfsv4-reminv-design-09.txt
 Date: 19/11/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
Remote Invalidation relieves RDMA responders of some of the burden of preparing memory to be accessed remotely, thus reducing the latency of RDMA Read and Write operations. This document considers how to introduce generic support for Remote Invalidation to RPC-over-RDMA transport protocols.
    
draft-cel-nfsv4-rpcrdma-reliable-reply-04.txt
 Improving the Performance and Reliability of RPC Replies on RPC-over-RDMA Transports
 
 draft-cel-nfsv4-rpcrdma-reliable-reply-04.txt
 Date: 19/11/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: txt xml
RPC transports such as RPC-over-RDMA version 1 require reply buffers to be in place before an RPC Call is sent. However, RPC consumers sometimes have difficulty estimating the expected maximum size of a particular RPC reply. This introduces the risk that an RPC Reply message can overrun reply resources provided by the requester, preventing delivery of the message, through no fault of the requester. This document describes a mechanism that eliminates the need for pre-allocation of reply resources for unpredictably large replies.
    
draft-cel-nfsv4-rpcrdma-version-two-08.txt
 RPC-over-RDMA Version 2 Protocol
 
 draft-cel-nfsv4-rpcrdma-version-two-08.txt
 Date: 08/11/2018
 Authors: Chuck Lever, David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a new version of the transport protocol that conveys Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA). The new version of this protocol is extensible.
    
draft-celi-block-ciph-00.txt
 ACVP Symmetric Block Cipher Algorithm JSON Specification
 
 draft-celi-block-ciph-00.txt
 Date: 21/02/2019
 Authors: Chris Celi
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines the JSON schema for using symmetric block cipher algorithms with the ACVP specification.
    
draft-cfb-ippm-spinbit-new-measurements-00.txt
 New Spin bit enabled measurements with one or two more bits
 
 draft-cfb-ippm-spinbit-new-measurements-00.txt
 Date: 28/02/2019
 Authors: Mauro Cociglio, Giuseppe Fioccola, Fabio Bulgarella, Riccardo Sisto
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces additional measurements by using the same spin bit signal as defined in [I-D.trammell-ippm-spin]. The spin bit signal alone is not enough to evaluate correctly in every network condition the RTT of a flow. In order to solve this problem, it is theorized the possibility of introducing an additional validation signal called delay bit, similar to what is done done by the Valid Edge Counter (VEC), but using just one bit instead of two. An alternative with two bits is also introduced with a so called loss bit.
    
draft-chandra-mpls-rsvp-shared-labels-np-01.txt
 Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane
 
 draft-chandra-mpls-rsvp-shared-labels-np-01.txt
 Date: 03/01/2019
 Authors: Chandrasekar R, Vishnu Beeram, Harish Sitaraman
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routed RSVP-TE tunnels provide the ability to use a shared MPLS forwarding plane at every hop of the Label Switched Path (LSP). The shared forwarding plane is realized with the use of 'Traffic Engineering (TE) link labels' that get shared by LSPs traversing these TE links. This paradigm helps significantly reduce the forwarding plane state required to support a large number of LSPs on a Label Switching Router (LSR). Segment Routed RSVP-TE tunnels require the ingress Label Edge Router (LER) to impose a stack of labels. If the ingress LER cannot impose the full label stack, it can use the assistance of one or more delegation hops along the path of the LSP to impose parts of the label stack. The procedures for a Point of Local Repair (PLR) to provide local protection against link failures using facility backup for Segment Routed RSVP-TE tunnels are well defined and do not require specific protocol extensions. This document defines the procedures for a PLR to provide local protection against transit node failures using facility backup for these tunnels. The procedures defined in this document include protection against delegation hop failures.
    
draft-chen-ati-adaptive-ipv4-address-space-04.txt
 Adaptive IPv4 Address Space
 
 draft-chen-ati-adaptive-ipv4-address-space-04.txt
 Date: 11/12/2018
 Authors: Abraham Chen, Ramamurthy Ati, Abhay Karandikar, David Crowe
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, or the current private networks. It is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivity, but also their interoperability. EzIP deployments may coexist with existing Internet traffic and the IoT (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to indepdently choose this system. EzIP may be implemented as a software or firmware enhancement to Internet edge routers or private network routing gateways, wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed here establishes a complete spherical layer of routers for interfacing between the Internet fabic (core plus edge routers) and the end user premises. Incorporating caching proxy technology in the gateway, a fairly large geographical region may enjoy EzIP as address expansion using as little as one ordinary IPv4 public address utilizing IP packets with degenerated EzIP header. If IPv4 public pool allocations were reorganized, the assignable pool could be multiplied by 512M times or even more. EzIP will immediately resolve local IPv4 address shortages, while being transparent to the rest of the Internet. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording IPv6 more time to reach maturity and to provide the availability levels required for delivering a long-term general service.
    
draft-chen-bier-te-ping-04.txt
 BIER-TE Ping and Trace
 
 draft-chen-bier-te-ping-04.txt
 Date: 26/02/2019
 Authors: Ran Chen, Gregory Mirsky, Shaofu Peng
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with 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 the BIER-TE network.
    
draft-chen-detnet-det-vpn-00.txt
 Deterministic VPN
 
 draft-chen-detnet-det-vpn-00.txt
 Date: 08/03/2019
 Authors: Zhe Chen, Li Qiang
 Working Group: Individual Submissions (none)
 Formats: xml txt
Deterministic Networking (DetNet) services are expected to be integrated with VPN technologies. Such deployment scenarios include mobile backhauls and TSN islands inter-connections. This document describes an overall VPN framework that provides deterministic transport services (called deterministic VPN), specifies corresponding control and data plane protocols that are required to support the framework, and initially summarizes potential extensions of existing protocols to enable deterministic VPNs.
    
draft-chen-detnet-loss-delay-01.txt
 DetNet Packet Loss and Delay Performance Measurement
 
 draft-chen-detnet-loss-delay-01.txt
 Date: 22/10/2018
 Authors: Mach Chen, Andrew Malis
 Working Group: Individual Submissions (none)
 Formats: txt
Deterministic Networking (DetNet) is defined to provide end-to-end bounded latency and extremely low packet loss rates for critical flows. It's important to measure and monitor the packet loss rates and end-to-end delay and delay variation of a DetNet flow path, which allows evaluation of whether the Service Level Agreements (SLA) of the provided DetNet services are satisfied. These metrics are also useful in network/traffic planning, trouble shooting, and network performance evaluation. This document defines protocol mechanisms to support passive Performance Measurement (PM) for DetNet service.
    
draft-chen-detnet-sr-based-bounded-latency-00.txt
 Segment Routing (SR) Based Bounded Latency
 
 draft-chen-detnet-sr-based-bounded-latency-00.txt
 Date: 19/10/2018
 Authors: Mach Chen, Xuesong Geng, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt
One of the goals of DetNet is to provide bounded end-to-end latency for critical flows. This document defines how to leverage Segment Routing (SR) to implement bounded latency. Specifically, the SR Identifier (SID) is used to specify transmission time (cycles) of a packet. When forwarding devices along the path follow the instructions carried in the packet, the bounded latency is achieved. This is called Cycle Specified Queuing and Forwarding (CSQF) in this document. Since SR is a source routing technology, no per-flow state is maintained at intermediate and egress nodes, SR-based CSQF naturally supports flow aggregation that is deemed to be a key capability to allow DetNet to scale to large networks.
    
draft-chen-dots-attack-bandwidth-expansion-01.txt
 Using attack bandwidth in signal channel
 
 draft-chen-dots-attack-bandwidth-expansion-01.txt
 Date: 11/03/2019
 Authors: chenmeiling, Li Su, Jin Peng
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a DDoS Mitigation Request parameter used in the Signal Channel request, as an expansion of the signal channel for mitigating DDoS attack accurately with target-bandwidth. The proposed parameter will help to choose the appropriate mitigator or mitigators for mitigation, When An attack occurs that is greater than the maximum clean capability, this paramter can decide to be blackhole directly or to be drainaged for clean.
    
draft-chen-grow-enhanced-as-loop-detection-01.txt
 Enhanced AS-Loop Detection for BGP
 
 draft-chen-grow-enhanced-as-loop-detection-01.txt
 Date: 02/04/2019
 Authors: China Telecom, Di Ma, Yunan Gu, Shunwan Zhuang, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes to enhance AS-Loop Detection for BGP Inbound/ Outbound Route Processing. This could empower networks to quickly and accurately figure out they're being victimized.
    
draft-chen-iccrg-rocev3-cm-requirements-00.txt
 Requirements for RoCEv3 Congestion Management
 
 draft-chen-iccrg-rocev3-cm-requirements-00.txt
 Date: 23/03/2019
 Authors: Fei Chen, Wenhao Sun, Yolanda Yu
 Working Group: Individual Submissions (none)
 Formats: txt
On IP-routed datacenter networks, RDMA is deployed using RoCEv2 protocol. RoCEv2 specification does not define the strong congestion management mechanisms and load balancing methods. RoCEv2 relies on the existing Link-Layer Flow-Control IEEE 802.1Qbb(Priority-based Flow Control, PFC)to provide a lossless fabric. RoCEv2 Congestion Management(RCM) use ECN(Explicit Congestion Notification, defined in RFC3168) to signal the congestion to the destination and use the congestion notification to reduce the rate of injection and increase the injection rate when the extent of congestion decreases. More and more practice of congestion management for RoCEv2 appear in the industry, such as DCQCN(Data Center Quantized Congestion Notification). There is a demanding for the new RoCEv3 protocol to provide stronger congestion management and load balancing mechanisms for RDMA deployment in modern datacenter.
    
draft-chen-idr-bgp-srv6-sid-allocation-00.txt
 BGP Extensions for SRv6 SIDs Allocation
 
 draft-chen-idr-bgp-srv6-sid-allocation-00.txt
 Date: 08/03/2019
 Authors: Huaimo Chen, Zhenbin Li, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes extensions to the BGP-LS for IDs allocation. The IDs are SIDs for segment routing for IPv6 (SRv6). They are distributed to their domains if needed.
    
draft-chen-mpls-cqf-lsp-dp-00.txt
 MPLS-LSP Data Plane for Cyclic Queuing and Forwarding
 
 draft-chen-mpls-cqf-lsp-dp-00.txt
 Date: 09/03/2019
 Authors: Zhe Chen, Li Qiang
 Working Group: Individual Submissions (none)
 Formats: txt xml
Large-scale Deterministic Network (LDN) [ldn] aims to achieve bounded latency forwarding on layer-3 networks that contain long-distance links, large number of nodes and flows. LDN requires a data plane mechanism to indicate different forwarding cycles in the upstream node. This document proposes to use multiple MPLS labels to indicate this kind of information, for MPLS-LSP data plane.
    
draft-chen-npm-use-cases-00.txt
 Network-wide Protocol Monitoring (NPM): Use Cases
 
 draft-chen-npm-use-cases-00.txt
 Date: 11/03/2019
 Authors: Huanan Chen, Zhenqiang Li, Feng Xu, Yunan Gu, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
As networks continue to scale, we need a coordinated effort for diagnosing control plane health issues in heterogeneous environments. Traditionally, operators developed internal solutions to address the identification and remediation of control plane health issues, but as networks increase in size, speed and dynamicity, new methods and techniques will be required. This document highlights key network health issues, as well as network planning requirements, identified by leading network operators. It also provides an overview of current art and techniques that are used, but highlights key deficiencies and areas for improvement. This document proposes a unified management framework for coordinating diagnostics of control plane problems and optimization of network design. Furthermore, it outlines requirements for collecting, storing and analyzing control plane data, to minimise or negate control plane problems that may significantly affect overall network performance and to optimize path/peering/policy planning for meeting application-specific demands.
    
draft-chen-nvo3-yang-02.txt
 YANG Data Model for NVO3 Protocol
 
 draft-chen-nvo3-yang-02.txt
 Date: 24/03/2019
 Authors: Ran Chen, fangwei hu, Yubao Wang, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for NVO3 configuration and operation. This YANG model covers two types of encapsulations: Geneve, and VXLAN-GPE
    
draft-chen-pce-bier-05.txt
 PCEP Extensions for BIER
 
 draft-chen-pce-bier-05.txt
 Date: 24/03/2019
 Authors: Ran Chen, Zheng Zhang
 Working Group: Individual Submissions (none)
 Formats: txt xml
Bit Index Explicit Replication (BIER)-TE shares architecture and packet formats with BIER as described in [RFC8279]. 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 as described in [I-D.ietf-bier-te-arch].BIER-TE Path can be derived from a Path Computation Element (PCE). This document specifies extensions to the Path Computation Element Protocol (PCEP) that allow a PCE to compute and initiate the path for the BIER-TE.
    
draft-chen-rtgwg-srv6-midpoint-protection-00.txt
 SRv6 Proxy Forwarding
 
 draft-chen-rtgwg-srv6-midpoint-protection-00.txt
 Date: 10/03/2019
 Authors: Huaimo Chen, Zhibo Hu, China Telecom
 Working Group: Individual Submissions (none)
 Formats: txt
The endpoints of a SRv6 path are given by a SRv6 Policy. When an endpoint node fails, we need bypass this failed endpoint node and forward the packets to the failed node's next endpoint node.
    
draft-cheng-mpls-inband-pm-encapsulation-00.txt
 Encapsulation For MPLS Inband Performance Measurement
 
 draft-cheng-mpls-inband-pm-encapsulation-00.txt
 Date: 10/03/2019
 Authors: Weiqiang Cheng, Min Xiao, Tianran Zhou, Ximing Dong
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the encapsulation for MPLS inband performance measurement, which performs flow-based packet loss, delay, and jitter measurements on live traffic, by using the alternate-marking method.
    
draft-cheshire-dnssd-roadmap-03.txt
 Service Discovery Road Map
 
 draft-cheshire-dnssd-roadmap-03.txt
 Date: 23/10/2018
 Authors: Stuart Cheshire
 Working Group: Extensions for Scalable DNS Service Discovery (dnssd)
 Formats: txt
Over the course of several years, a rich collection of technologies has developed around DNS-Based Service Discovery, described across multiple documents. This "Road Map" document gives an overview of how these related but separate technologies (and their documents) fit together, to facilitate service discovery in various environments.
    
draft-cheshire-sudn-ipv4only-dot-arpa-14.txt
 Special Use Domain Name 'ipv4only.arpa'
 
 draft-cheshire-sudn-ipv4only-dot-arpa-14.txt
 Date: 03/11/2018
 Authors: Stuart Cheshire, David Schinazi
 Working Group: Individual Submissions (none)
 Formats: xml txt
The specification for how a client discovers its local network's NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but in its Domain Name Reservation Considerations section that specification indicates that the name actually has no particularly special properties would require special handling, and does not request IANA to record the name in the Special-Use Domain Names registry. Consequently, despite the well articulated special purpose of the name, 'ipv4only.arpa' was not recorded in the Special-Use Domain Names registry as a name with special properties. As a result of this omission, in cases where software needs to give this name special treatment in order for it to work correctly, there was no clear mandate authorizing software authors to implement that special treatment. Software implementers were left with the choice between not implementing the special behavior necessary for the name queries to work correctly, or implementing the special behavior and being accused of being noncompliant with some RFC. This document describes the special treatment required, formally declares the special properties of the name, and adds similar declarations for the corresponding reverse mapping names.
    
draft-chkim-vlc-iot-00.txt
 Framework of Visible Light Communications in IoT Networks
 
 draft-chkim-vlc-iot-00.txt
 Date: 18/10/2018
 Authors: Cheol-Min Kim, Seok Koh
 Working Group: Individual Submissions (none)
 Formats: txt
The LED-based Visible Light Communication (VLC) has been proposed as the IEEE 802.15.7-2011 standard and regarded as a new wireless access medium in IoT environment. With this trend, many works have so far been made to improve the performance of VLC. However, how to effectively integrate VLC services into IoT networks has not been studied enough. In this document, we propose a scheme for device management and data transport in IoT networks using VLC. Specifically, we discuss how to manage VLC transmitters and receivers, and to support VLC data transmission in IoT networks. The proposed scheme considers uni-directional VLC transmissions from transmitter to receivers for delivery of location-based VLC data. The backward transmission from VLC receivers will be made by using platform server and aggregation agents in the network.
    
draft-choi-icnrg-aiot-00.txt
 Requirements and Challenges for User-level Service Managements of IoT Network by utilizing Artificial Intelligence
 
 draft-choi-icnrg-aiot-00.txt
 Date: 11/03/2019
 Authors: Junkyun Choi, Na Kim, Jaeseob Han, Min Kim, Gyu Lee
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This document describes the requirements and challenges to employ artificial intelligence (AI) into the constraint Internet of Things (IoT) service environment for embedding intelligence and increasing efficiency. The IoT service environment includes heterogeneous and multiple IoT devices and systems that work together in a cooperative and intelligent way to manage homes, buildings, and complex autonomous systems. Therefore, it is becoming very essential to integrate IoT and AI technologies to increase the synergy between them. However, there are several limitations to achieve AI enabled IoT as the availability of IoT devices is not always high, and IoT networks cannot guarantee a certain level of performance in real-time applications due to resource constraints. This document intends to present a right direction to empower AI in IoT for learning and analyzing the usage behaviors of IoT devices/systems and human behaviors based on previous records and experiences. With AI enabled IoT, the IoT service environment can be intelligently managed in order to compensate for the unexpected performance degradation often caused by abnormal situations.
    
draft-chopps-netmod-geo-location-01.txt
 YANG Geo Location
 
 draft-chopps-netmod-geo-location-01.txt
 Date: 02/03/2019
 Authors: Christian Hopps
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a generic geographical location object YANG grouping. The geographical location grouping is intended to be used in YANG models for specifying a location on or in reference to the Earth or any other astronomical object.
    
draft-chuang-ietf-bimi-security-perspectives-00.txt
 Verified Mark Certificates Proposal: A Security Perspective
 
 draft-chuang-ietf-bimi-security-perspectives-00.txt
 Date: 11/03/2019
 Authors: Wei Chuang, Thede Loder
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document motivates the need for embedding logotypes in X.509 certificates along with the certificate validation process from a security perspective.
    
draft-chunduri-lsr-isis-mt-deployment-cons-01.txt
 IS-IS Multi Topology Deployment Considerations
 
 draft-chunduri-lsr-isis-mt-deployment-cons-01.txt
 Date: 22/10/2018
 Authors: Uma Chunduri, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes IS-IS Multi Topology (MT) considerations in various deployments (Core/Mobile Backhaul/Data Center underlays). This document explores the nuances around the terminology and usage of various IS-IS address families, topologies and considerations, while choosing the right combination for a specific deployment scenario. This document also discusses various ways one can deploy IPv6 only IS-IS topology.
    
draft-chunduri-lsr-isis-preferred-path-routing-02.txt
 Preferred Path Routing (PPR) in IS-IS
 
 draft-chunduri-lsr-isis-preferred-path-routing-02.txt
 Date: 14/02/2019
 Authors: Uma Chunduri, Renwei Li, Russ White, Jeff Tantsura, Luis Contreras, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR), a routing protocol mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to IS-IS advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chunduri-lsr-isis-prefix-multi-algo-01.txt
 Multiple Algorithm support for IS-IS Prefixes
 
 draft-chunduri-lsr-isis-prefix-multi-algo-01.txt
 Date: 22/10/2018
 Authors: Uma Chunduri, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an extension to Intermediate System to Intermediate System (IS-IS) protocol by adding an Algorithm support for prefixes advertised. This allows multiple independent algorithm usage for computing the reachability of nodes and prefixes as opposed to only one algorithm.
    
draft-chunduri-lsr-ospf-preferred-path-routing-02.txt
 Preferred Path Routing (PPR) in OSPF
 
 draft-chunduri-lsr-ospf-preferred-path-routing-02.txt
 Date: 14/02/2019
 Authors: Uma Chunduri, Yingzhen Qu, Russ White, Jeff Tantsura, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR), a routing protocol mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments with OSPFv2 and OSPFv3 protocols. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to OSPF advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chung-dtn-extension-prophet-icn-03.txt
 Extension of Probabilistic Routing Protocol using History of Encounters and Transitivity for Information Centric Network
 
 draft-chung-dtn-extension-prophet-icn-03.txt
 Date: 22/10/2018
 Authors: Yun Chung, Min Kang, Dong Seo, Young-Han Kim
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes extension of probabilistic routing protocol using history of encounters and transitivity (PRoPHET) for information centric network.
    
draft-clarke-cbor-crs-00.txt
 Concise Binary Object Representation (CBOR) Tag for Coordinate Reference System (CRS) Specification
 
 draft-clarke-cbor-crs-00.txt
 Date: 25/03/2019
 Authors: Trevor Clarke
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Concise Binary Object Representation (CBOR, RFC 7049) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. In CBOR, one point of extensibility is the definition of CBOR tags. An existing CBOR tag, 103, allows for the representation of geographic coordinates. Proper exploitation of geographic coordinates requires an associated reference frame. The present document defines a CBOR tag for referencing the coordinate reference system (CRS) for a geographic coordinate. It is intended as the reference document for the IANA registration of the CBOR tag defined.
    
draft-clemm-netmod-push-smart-filters-01.txt
 Smart Filters for Push Updates
 
 draft-clemm-netmod-push-smart-filters-01.txt
 Date: 22/10/2018
 Authors: Alexander Clemm, Eric Voit, Xufeng Liu, Igor Bryskin, Tianran Zhou, Guangying Zheng, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG model for Smart Filters for push updates. Smart Filters allow to filter push updates based on values of pushed datastore nodes and/or state, such as previous updates. Smart Filters provide an important building block for service assurance and network automation. This revision of the document is intended as a placeholder, containing the problem statement of draft-clemm-netconf-push-smart- filters-ps-00 that has recently expired. The YANG model itself still needs to be defined.
    
draft-clt-dmm-tn-aware-mobility-03.txt
 Transport Network aware Mobility for 5G
 
 draft-clt-dmm-tn-aware-mobility-03.txt
 Date: 14/02/2019
 Authors: Uma Chunduri, Renwei Li, Sridhar Bhaskaran, Jeff Tantsura, Luis Contreras, Praveen Muley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a framework and a mapping function for 5G mobile user plane with transport network slicing, integrated with Mobile Radio Access and a Virtualized Core Network. The integrated approach is specified in a way to fit into the 5G core network architecture defined in [TS23.501]. It focuses on an optimized mobile user plane functionality with various transport services needed for some of the 5G traffic needing low and deterministic latency, real-time, mission-critical services. This document describes, how this objective is achieved agnostic to the transport underlay used (IPv4, IPv6, MPLS) in various deployments and with a new transport network underlay routing, called Preferred Path Routing (PPR).
    
draft-contreras-layered-sdn-03.txt
 Cooperating Layered Architecture for Software Defined Networking (CLAS)
 
 draft-contreras-layered-sdn-03.txt
 Date: 22/11/2018
 Authors: Luis Contreras, Carlos Bernardos, Diego Lopez, Mohamed Boucadair, Paola Iovanna
 Working Group: Individual Submissions (none)
 Formats: txt xml
Software Defined Networking adheres to the separation of the control plane from the data plane in the network nodes and its logical centralization on one or a set of control entities. Most of the network and/or sevice intelligence is moved to these control entities. Typically, such entity is seen as a compendium of interacting control functions in a vertical, tight integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that relies upon transport capabilities. This document describes an approach named Cooperating Layered Architecture for Software Defined Networking. The idea behind that is to differentiate the control functions associated to transport from those related to services, in such a way that they can be provided and maintained independently, and can follow their own evolution path.
    
draft-cooper-wugh-github-wg-configuration-02.txt
 GitHub Configuration for IETF Working Groups
 
 draft-cooper-wugh-github-wg-configuration-02.txt
 Date: 17/12/2018
 Authors: Alissa Cooper, Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
The use of GitHub in IETF working group processes is increasing. This document describes possible uses and conventions for working groups which are considering starting to use GitHub. It does not mandate any processes, and does not intend to change the processes used by current working groups. Discussion of this document takes place on the ietf-and-github mailing list (ietf-and-github@ietf.org), which is archived at .
    
draft-cth-rtgwg-bgp-control-01.txt
 Architecture for Use of BGP as Central Controller
 
 draft-cth-rtgwg-bgp-control-01.txt
 Date: 10/03/2019
 Authors: Huaimo Chen, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
BGP is a core part of a network including Software-Defined Networking (SDN) system. It has the traffic engineering information on the network topology and can compute optimal paths for a given traffic flow acrosss the network. This document describes the architecture for BGP as a central controller. A BGP-based central controller can simplify the operations on the network and use network resources efficiently for providing services with high quality.
    
draft-cups-rtgwg-cu-separation-requirement-00.txt
 Requirements for BNG Control-plane And User-plane Separation
 
 draft-cups-rtgwg-cu-separation-requirement-00.txt
 Date: 08/03/2019
 Authors: Tianpeng Yu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document aims to abstract reqruriment of an extensible and flexible Control Plane (CP) and User Plane (UP) Separated BNG Architecture.
    
draft-cuspdt-rtgwg-cu-separation-bng-architecture-04.txt
 Architecture for Control Plane and User Plane Separated BNG
 
 draft-cuspdt-rtgwg-cu-separation-bng-architecture-04.txt
 Date: 11/03/2019
 Authors: Shujun Hu, Fengwei Qin, Zhenqiang Li, Tee Chua, Victor Lopezalvarez, Donald Eastlake, Zitao Wang, Jun Song
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines an architecture for Broadband Network Gateway (BNG) devices with control plane (CP) and user plane (UP) separation. A BNG-CP is a user control management component while a BNG-UP takes responsibility as the network edge and user policy implementation component. Both BNG-CP and BNG-UP are core components for fixed broadband services and are deployed separately at different network layers.
    
draft-cuspdt-rtgwg-cu-separation-bng-deployment-02.txt
 Control Plane and User Plane Separated BNG Deployment Model
 
 draft-cuspdt-rtgwg-cu-separation-bng-deployment-02.txt
 Date: 12/12/2018
 Authors: Rong Gu, Sujun Hu, Zitao Wang, Donald Eastlake, fangwei hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the deployment model for a Broadband Network Gateway (BNG) device with Control Plane (CP) and User Plane(UP) separation. It is intended to give guidance for the deployment of CP and UP separated BNG devices in an operators' network.
    
draft-cuspdt-rtgwg-cu-separation-bng-protocol-04.txt
 Control-Plane and User-Plane Separation BNG Simple Control Channel Protocol
 
 draft-cuspdt-rtgwg-cu-separation-bng-protocol-04.txt
 Date: 11/03/2019
 Authors: Shujun Hu, Donald Eastlake, Mach Chen, Fengwei Qin, Zhenqiang Li, Jun Song, Tee Chua
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the Simple Control Plane (CP) and User Plane (UP) Separation Broadband Network Gateway (BNG) control channel Protocol (S-CUSP) for communications between a CP and a UP. S-CUSP is designed to be flexible and extensible so as to easily allow for the addition of further messages and data items, should requirements be expressed in the future.
    
draft-cuspdt-rtgwg-cu-separation-infor-model-03.txt
 Information Model of Control-Plane and User-Plane Separation BNG
 
 draft-cuspdt-rtgwg-cu-separation-infor-model-03.txt
 Date: 22/10/2018
 Authors: Shujun Hu, Donald Eastlake, Zitao Wang, Victor Lopezalvarez, Fengwei Qin, Zhenqiang Li, Tee Chua
 Working Group: Individual Submissions (none)
 Formats: xml txt
To improve network resource utilization and reduce operational expense, the Control-Plane and User-Plane separation concept is defined in Broadband Forum TR-384. This document describes the information model for the interface between the Control-Plane (CP) and the User-Plane (UP) in the CP/UP separation BNG. This information model may involve both the control channel interface and the configuration channel interface. The interface for the control channel allows the Control-Plane to send flow tables to the User- Plane, such as user's information table, user's interface table, and user's QoS table. And it also allows the User-Plane to report resource and statistics information to the Control-Plane. The interface for the configuration channel is in charge of the protocol version negotiation between the Control-Plane and User-Plane, the configuration for devices of the Control-Plane and User-Plane, and the reports of User-Plane's capabilities, etc. The information model defined in this document supports defining a standardized data model. Such a data model can be used to specify an interface to the CU separation BNG.
    
draft-cuspdt-rtgwg-cu-separation-yang-model-03.txt
 YANG Data Model for Configuration Interface of Control-Plane and User-Plane separation BNG
 
 draft-cuspdt-rtgwg-cu-separation-yang-model-03.txt
 Date: 10/03/2019
 Authors: Daniel Huang, fangwei hu, Sujun Hu, Fengwei Qin
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the YANG data model for management of Control- Plane and User-Plane separation of BNGs (Broadband Network Gateways).
    
draft-cuspdt-rtgwg-cusp-requirements-03.txt
 Requirements for Control Plane and User Plane Separated BNG Protocol
 
 draft-cuspdt-rtgwg-cusp-requirements-03.txt
 Date: 22/10/2018
 Authors: Sujun Hu, Victor Lopezalvarez, Fengwei Qin, Zhenqiang Li, Tee Chua, Donald Eastlake, Zitao Wang, Jun Song
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the Control Plane and User Plane separated BNG (Broadband Network Gateway) architecture and defines a set of associated terminology. It also specifies a set of protocol requirements for communication between the BNG-CP and the BNG-UPs in the Control Plane and User Plane Separated BNG.
    
draft-daboo-valarm-extensions-05.txt
 VALARM Extensions for iCalendar
 
 draft-daboo-valarm-extensions-05.txt
 Date: 05/03/2019
 Authors: Cyrus Daboo, Ken Murchison
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a set of extensions to the iCalendar VALARM component to enhance use of alarms and improve interoperability between clients and servers.
    
draft-dahlberg-ll-quantum-02.txt
 The Link Layer service in a Quantum Internet
 
 draft-dahlberg-ll-quantum-02.txt
 Date: 15/04/2019
 Authors: Axel Dahlberg, Matthew Skrzypczyk, Stephanie Wehner
 Working Group: Individual Submissions (none)
 Formats: txt xml
In a classical network the link layer is responsible for transferring a datagram between two nodes that are connected by a single link, possibly including switches. In a quantum network however, the link layer will need to provide a robust entanglement generation service between two quantum nodes which are connected by a quantum link. This service can be used by higher layers to produce entanglement between distant nodes or to perform other operations such as qubit transmission, without full knowledge of the underlying hardware and its parameters. This draft defines what can be expected from the service provided by a link layer for a Quantum Network and defines an interface between higher layers and the link layer.
    
draft-dalal-deprecation-header-00.txt
 The Deprecation HTTP Header
 
 draft-dalal-deprecation-header-00.txt
 Date: 27/02/2019
 Authors: Sanjay Dalal, Erik Wilde
 Working Group: Individual Submissions (none)
 Formats: xml txt
The HTTP Deprecation response header can be used to signal to consumers of a URI-identified resource that the use of the resource has been deprecated. Additionally, the deprecation link relation can be used to link to a resource that provides additional context for the deprecation, and possibly ways in which clients can find a replacement for the deprecated resource.
    
draft-dang-ippm-congestion-01.txt
 A One-Path Congestion Metric for IPPM
 
 draft-dang-ippm-congestion-01.txt
 Date: 10/03/2019
 Authors: Joanna Dang, Jianglong Wang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This memo defines a metric for one path congestion across Internet paths. The traditional mode evaluates network congestion based on the bandwidth utilization of the link. However, there is a lack of E2E path congestion that is truly service oriented. So A Path Congestion Metric is required.
    
draft-dang-ippm-multiple-path-measurement-01.txt
 A Multi-Path Concurrent Measurement Protocol for IPPM
 
 draft-dang-ippm-multiple-path-measurement-01.txt
 Date: 10/03/2019
 Authors: Joanna Dang, Jianglong Wang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This test method can test multi-paths concurrently between two edge nodes. This document details Multi-Path Concurrent Measurement Protocol (MPCMP).
    
draft-davidben-http2-tls13-00.txt
 Using TLS 1.3 with HTTP/2
 
 draft-davidben-http2-tls13-00.txt
 Date: 01/04/2019
 Authors: David Benjamin
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document clarifies the use of TLS 1.3 post-handshake authentication and key update with HTTP/2.
    
draft-dawes-sipcore-mediasec-parameter-09.txt
 Security Mechanism Names for Media
 
 draft-dawes-sipcore-mediasec-parameter-09.txt
 Date: 09/11/2018
 Authors: Peter Dawes
 Working Group: Individual Submissions (none)
 Formats: txt
Negotiating the security mechanisms used between a Session Initiation Protocol (SIP) user agent and its next-hop SIP entity is described in [2]. This document adds the capability to distinguish security mechanisms that apply to the media plane by defining a new Session Initiation Protocol (SIP) header field parameter to label such security mechanisms.
    
draft-dawra-bess-srv6-services-00.txt
 SRv6 BGP based Overlay services
 
 draft-dawra-bess-srv6-services-00.txt
 Date: 11/03/2019
 Authors: Gaurav Dawra, Clarence Filsfils, Darren Dukes, Patrice Brissette, Shyam Sethuram, Pablo Camarillo, John Leddy, daniel.voyer@bell.ca, daniel.bernier@bell.ca, Dirk Steinberg, Robert Raszuk, Bruno Decraene, Satoru Matsushima, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines procedures and messages for SRv6-based BGP services including L3VPN, EVPN and Internet services. It builds on RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 "BGP MPLS-Based Ethernet VPN" and provides a migration path from MPLS-based VPNs to SRv6 based VPNs.
    
draft-dawra-idr-bgp-ls-sr-service-segments-01.txt
 BGP-LS Advertisement of Segment Routing Service Segments
 
 draft-dawra-idr-bgp-ls-sr-service-segments-01.txt
 Date: 16/01/2019
 Authors: Gaurav Dawra, Clarence Filsfils, daniel.bernier@bell.ca, Jim Uttaro, Bruno Decraene, Hani Elmalky, Xiaohu Xu, Francois Clad, Ketan Talaulikar
 Working Group: Individual Submissions (none)
 Formats: txt
BGP Link-State (BGP-LS) enables distribution of topology information from the network to a Path Computation Engine (PCE) or any controller/application in general so it can learn the network topology. Service functions are deployed as virtualized elements along with network elements or on servers in data centers. The advertisement of such attached service capabilities along with the network nodes that they are attached to or associated with enable their discovery and for programming of service paths that use these service functions. Segment Routing (SR) bring in the concept of segments which can be topological or service instructions. SR Policies enable setup of paths which are a mix of topological and service segments. This document specifies the extensions to BGP-LS for discovery and advertisement of service segments so as to enable setup of service programming paths using Segment Routing.
    
draft-dawra-idr-bgpls-srv6-ext-06.txt
 BGP Link State Extensions for SRv6
 
 draft-dawra-idr-bgpls-srv6-ext-06.txt
 Date: 24/03/2019
 Authors: Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Mach Chen, daniel.bernier@bell.ca, Jim Uttaro, Bruno Decraene, Hani Elmalky
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing IPv6 (SRv6) allows for a flexible definition of end- to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by the various protocols such as BGP, ISIS and OSPFv3. BGP Link-state (BGP-LS) address-family solution for SRv6 is similar to BGP-LS for SR for MPLS dataplane. This draft defines extensions to the BGP-LS to advertise SRv6 Segments along with their functions and other attributes via BGP.
    
draft-dcn-bmwg-containerized-infra-00.txt
 Considerations for Benchmarking Network Performance in Containerized Infrastructures
 
 draft-dcn-bmwg-containerized-infra-00.txt
 Date: 07/03/2019
 Authors: Sun Kj, Hyunsik Yang, ykpark@dcn.ssu.ac.kr, Young-Han Kim, Wangbong Lee
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft describes benchmarking considerations for a containerized infrastructure. In a containerized infrastructure, Virtualized Network Functions(VNFs) are deployed on operating-system-level virtualization platform by abstracting the user namespace as opposed to virtualization using a hypervisor. Leveraging this, the system configurations and networking scenarios for VNF benchmarking will be partially changed by way of resource allocation and network port binding between a physical host and VNFs. In this draft we compare the state of the art in container networking architecture with networking on VM-based virtualized systems, and provide several test scenarios for network performance in containerized infrastructure.
    
draft-dcrocker-dns-perimeter-00.txt
 DNS Perimeter Overlay
 
 draft-dcrocker-dns-perimeter-00.txt
 Date: 02/04/2019
 Authors: Dave Crocker, T. Adams
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Domain Name System (DNS) naming syntax provides no meta-data for indicating administrative transitions through the hierarchy. For example, it does not distinguish the higher-level portions that operate as public registries, versus those that operate as private organizations. This specification creates a basic overlay mechanism for defining a logical Perimeter between administrative entities through the naming hierarchy. The mechanism can then be applied for a variety of independent administrative indications.
    
draft-deconinck-quic-multipath-02.txt
 Multipath Extensions for QUIC (MP-QUIC)
 
 draft-deconinck-quic-multipath-02.txt
 Date: 07/03/2019
 Authors: Quentin Coninck, Olivier Bonaventure
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies extensions to the QUIC protocol to enable, other than connection migration, simultaneous usage of multiple paths for a single connection. Those extensions remain compliant with the current single-path QUIC design. They allow devices to benefit from multiple network paths while preserving the privacy features of QUIC.
    
draft-defoy-mptcp-5g-session-continuity-support-00.txt
 5G Session Continuity Support in MPTCP
 
 draft-defoy-mptcp-5g-session-continuity-support-00.txt
 Date: 13/02/2019
 Authors: Xavier de Foy, Ulises Olvera, Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes how 5G session continuity can affect MPTCP. For now only potential performance issues are identified. This document aims to document discussions that took place at the IETF on this subject, to facilitate future deployment of MPTCP over 5G.
    
draft-defoy-nvo3-5g-datacenter-interconnection-00.txt
 5G-Datacenter Interconnection Use Case
 
 draft-defoy-nvo3-5g-datacenter-interconnection-00.txt
 Date: 24/01/2019
 Authors: Xavier de Foy, Ulises Olvera
 Working Group: Individual Submissions (none)
 Formats: xml txt
Interconnection between 5G networks and datacenter networks provide a new use case for NVO3 and for the 3rd Generation Partnership Project (3GPP) "5GLAN" feature. This document describes how layer-2 and layer-3 datacenter VPN technology can interoperate with anchor User Plane Functions (UPF) to interconnect 5G devices and datacenter servers over a virtual LAN.
    
draft-dejong-remotestorage-12.txt
 remoteStorage
 
 draft-dejong-remotestorage-12.txt
 Date: 08/12/2018
 Authors: Michiel de Jong, F. Kooman
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens.
    
draft-dekok-emu-eap-session-id-00.txt
 EAP Session-Id Derivation
 
 draft-dekok-emu-eap-session-id-00.txt
 Date: 28/01/2019
 Authors: Alan DeKok
 Working Group: Individual Submissions (none)
 Formats: txt
EAP Session-Id derivation has not been defined for EAP-SIM, EAP-AKA, and EAP-AKA' when using the fast re-authentication exchange instead of full authentication. This document updates [RFC5247] to define those derivations for EAP-SIM, and EAP-AKA. [AKAP] defines the Session-ID for EAP-AKA', so the definition for EAP-AKA' is not included here. [RFC5247] also does not define Session-Id derivation for PEAP. A definition is given here which follows the definition for other TLS-based EAP methods.
    
draft-dekok-emu-tls-eap-types-00.txt
 TLS-based EAP types and TLS 1.3
 
 draft-dekok-emu-tls-eap-types-00.txt
 Date: 11/02/2019
 Authors: Alan DeKok
 Working Group: Individual Submissions (none)
 Formats: txt
EAP-TLS [RFC5216] is being updated for TLS 1.3 in [EAPTLS]. Many other EAP [RFC3748] and [RFC5247] types also depend on TLS, such as FAST [RFC4851], TTLS [RFC5281], TEAP [RFC7170], and possibly many vendor specific EAP methods. This document updates those methods in order to use the new key derivation methods available in TLS 1.3. Additional changes necessitated by TLS 1.3 are also discussed.
    
draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt
 LSR Extensions for BIER over Ethernet
 
 draft-dhanaraj-bier-lsr-ethernet-extensions-00.txt
 Date: 29/01/2019
 Authors: Senthil Dhanaraj, IJsbrand Wijnands, Peter Psenak, Zhaohui Zhang, Gang Yan, Jingrong Xie
 Working Group: Individual Submissions (none)
 Formats: txt xml
Bit Index Explicit Replication (BIER) [RFC8279] is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. BIER can be supported in MPLS and non-MPLS networks. The common BIER header format and encapsulation for MPLS and non-MPLS networks is specified in [RFC8296]. This document specifies the required extensions to the IS-IS [RFC1195] and OSPFv2 [RFC2328] protocol for supporting BIER in non- MPLS networks using BIER in Ethernet encapsulation.
    
draft-dhody-pce-pcep-extension-pce-controller-p2mp-01.txt
 PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for P2MP LSPs
 
 draft-dhody-pce-pcep-extension-pce-controller-p2mp-01.txt
 Date: 18/02/2019
 Authors: Mahendra Negi, Zhenbin Li, Xuesong Geng
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. The PCE has been identified as an appropriate technology for the determination of the paths of point- to-multipoint (P2MP) TE Label Switched Paths (LSPs). PCE was developed to derive paths for MPLS P2MP LSPs, which are supplied to the head end (root) of the LSP using PCEP. PCEP has been proposed as a control protocol to allow the PCE to be fully enabled as a central controller. A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. Thus, the P2MP LSP can be calculated/setup/initiated and the label forwarding entries can also be downloaded through a centralized PCE server to each network devices along the P2MP path while leveraging the existing PCE technologies as much as possible. This document specifies the procedures and PCEP protocol extensions for using the PCE as the central controller for P2MP TE LSP.
    
draft-dhody-pce-pcep-extension-pce-controller-srv6-01.txt
 PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for SRv6
 
 draft-dhody-pce-pcep-extension-pce-controller-srv6-01.txt
 Date: 18/02/2019
 Authors: Mahendra Negi, Zhenbin Li, Xuesong Geng
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands. PCE was developed to derive paths for MPLS Label Switched Paths (LSPs), which are supplied to the head end of the LSP using the Path Computation Element Communication Protocol (PCEP). But SDN has a broader applicability than signaled (G)MPLS traffic-engineered (TE) networks, and the PCE may be used to determine paths in a range of use cases. PCEP has been proposed as a control protocol for use in these environments to allow the PCE to be fully enabled as a central controller. A PCE-based central controller (PCECC) can simplify the processing of a distributed control plane by blending it with elements of SDN and without necessarily completely replacing it. This document specifies the procedures and PCEP protocol extensions when a PCE-based controller is also responsible for configuring the forwarding actions on the routers for Segment Routing in IPv6 (SRv6), in addition to computing the SRv6 paths for packet flows and telling the edge routers what instructions to attach to packets as they enter the network.
    
draft-dhody-pce-recv-srlg-08.txt
 PCEP Extensions for Receiving SRLG Information
 
 draft-dhody-pce-recv-srlg-08.txt
 Date: 08/03/2019
 Authors: Dhruv Dhody, Fatai Zhang, Xian Zhang, Mahendra Negi, Victor Lopezalvarez, Oscar de Dios
 Working Group: Individual Submissions (none)
 Formats: txt
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. The document is currently dead as there is little interest in this as of now.
    
draft-dhody-pce-stateful-pce-interdomain-08.txt
 Stateful Path Computation Element (PCE) Inter-domain Considerations
 
 draft-dhody-pce-stateful-pce-interdomain-08.txt
 Date: 19/02/2019
 Authors: Cheng Li, Xian Zhang
 Working Group: Individual Submissions (none)
 Formats: xml txt
A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering path calculations for its associated Path Computation Clients (PCCs). Furthermore, PCEs are used to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains. This document describes general considerations for the deployment of stateful PCE(s) in inter-domain scenarios including inter-area and inter-AS. The inter-layer considerations will be described in a separate document. This document does not specify any extensions to PCEP.
    
draft-dhody-pce-stateful-pce-optional-03.txt
 Extension for Stateful PCE to allow Optional Processing of PCEP Objects.
 
 draft-dhody-pce-stateful-pce-optional-03.txt
 Date: 05/03/2019
 Authors: Cheng Li, Haomian Zheng, Stephane Litkowski
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces a mechanism to mark some Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints.
    
draft-dhody-pce-stateful-pce-vendor-06.txt
 Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for stateful PCE.
 
 draft-dhody-pce-stateful-pce-vendor-06.txt
 Date: 19/02/2019
 Authors: Cheng Li, Haomian Zheng
 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 the stateful PCE model.
    
draft-dhodylee-pce-pcep-ls-13.txt
 PCEP Extension for Distribution of Link-State and TE Information.
 
 draft-dhodylee-pce-pcep-ls-13.txt
 Date: 15/02/2019
 Authors: Dhruv Dhody, Young Lee, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-dhs-spring-pce-sr-p2mp-policy-00.txt
 PCEP extensions for p2mp sr policy
 
 draft-dhs-spring-pce-sr-p2mp-policy-00.txt
 Date: 11/03/2019
 Authors: Hooman Bidgoli, daniel.voyer@bell.ca, Saranya Rajarathinam, Jayant Kotalwar, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: txt
SR P2MP policies are set of policies that enable architecture for P2MP service delivery. This document specifies extensions to the Path Computation Element Communication Protocol (PCEP) that allow a stateful PCE to compute and initiate P2MP paths from a Root to a set of Leaves.
    
draft-dijk-core-groupcomm-bis-00.txt
 Group Communication for the Constrained Application Protocol (CoAP)
 
 draft-dijk-core-groupcomm-bis-00.txt
 Date: 10/03/2019
 Authors: Esko Dijk, Chonggang Wang, Marco Tiloca
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies the use of the Constrained Application Protocol (CoAP) for group communication, using UDP/IP multicast as the underlying data transport. Both unsecured and secured CoAP group communication are specified. Security is achieved by the Group Object Security for Constrained RESTful Environments (Group OSCORE) protocol. The target application area of this specification is any group communication use cases that involve resource-constrained network nodes. The most common of such use cases are listed in this document.
    
draft-djamaa-core-proactive-rd-discovery-00.txt
 Proactive Discovery of CoRE Resource Directories
 
 draft-djamaa-core-proactive-rd-discovery-00.txt
 Date: 01/04/2019
 Authors: Badis Djamaa, Ali Yachir
 Working Group: Individual Submissions (none)
 Formats: txt
The CoRE working group has proposed a Resource Directory (RD) solution to facilitate the discovery of the resources provided by constrained sensor and actuator networks. For such a mechanism to be effectively deployable, endpoints must first discover the existence of an RD in the network before being able to exploit its functionalities. This document presents Proactive RD Discovery (PRD); a scalable and effective mechanism to discover RDs. To achieve such qualities, PRD follows an announce-based model that builds upon CoAP Group Communication. PRD aims to provide important performance in terms of energy consumption, generated traffic, expressivity, and RD discovery time.
    
draft-dkg-openpgp-abuse-resistant-keystore-03.txt
 Abuse-Resistant OpenPGP Keystores
 
 draft-dkg-openpgp-abuse-resistant-keystore-03.txt
 Date: 18/04/2019
 Authors: Daniel Gillmor
 Working Group: Individual Submissions (none)
 Formats: xml txt
OpenPGP transferable public keys are composite certificates, made up of primary keys, direct key signatures, user IDs, identity certifications ("signature packets"), subkeys, and so on. They are often assembled by merging multiple certificates that all share the same primary key, and are distributed in public keystores. Unfortunately, since many keystores permit any third-party to add a certification with any content to any OpenPGP certificate, the assembled/merged form of a certificate can become unwieldy or undistributable. Furthermore, keystores that are searched by user ID or fingerprint can be made unusable for specific searches by public submission of bogus certificates. And finally, keystores open to public submission can also face simple resource exhaustion from flooding with bogus submissions, or legal or other risks from uploads of toxic data. This draft documents techniques that an archive of OpenPGP certificates can use to mitigate the impact of these various attacks, and the implications of these concerns and mitigations for the rest of the OpenPGP ecosystem.
    
draft-dkg-tls-reject-static-dh-01.txt
 TLS clients should reject static Diffie-Hellman
 
 draft-dkg-tls-reject-static-dh-01.txt
 Date: 04/12/2018
 Authors: Daniel Gillmor
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft addresses problematic proposals that contradict the expected security properties of TLS. In particular, the ETSI "Middlebox Security Protocol" standard deliberately weakens the cryptographic guarantees of TLS unilaterally by the server, using static Diffie-Hellman keys where ephemeral keys are expected. Responsible TLS clients should avoid connecting to servers that appear to implement such a specification.
    
draft-dold-payto-06.txt
 The 'payto' URI scheme for payments
 
 draft-dold-payto-06.txt
 Date: 17/04/2019
 Authors: Florian Dold, Christian Grothoff
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the 'payto' Uniform Resource Identifier (URI) scheme for designating targets for payments.
    
draft-dong-lsr-sr-enhanced-vpn-01.txt
 IGP Extensions for Segment Routing based Enhanced VPN
 
 draft-dong-lsr-sr-enhanced-vpn-01.txt
 Date: 22/10/2018
 Authors: Jie Dong, Stewart Bryant
 Working Group: Individual Submissions (none)
 Formats: txt
Enhanced VPN (VPN+) is an enhancement to VPN services to support the needs of new applications, particularly including the applications that are associated with 5G services. These applications require better isolation and have more stringent performance requirements than that can be provided with traditional overlay VPNs. An enhanced VPN may form the underpin of 5G transport network slicing, and will also be of use in its own right. This document describes how Multi- Topology Routing (MTR) as described in RFC 5120, RFC 4915 and RFC5340, can be extended to signal the network resources allocated in the underlay network to construct the customized virtual networks for enhanced VPN services, together with the Segment Routing Identifiers (SIDs) used to identify and access the network resources allocated for each virtual network in the data plane.
    
draft-dong-spring-sr-for-enhanced-vpn-03.txt
 Segment Routing for Enhanced VPN Service
 
 draft-dong-spring-sr-for-enhanced-vpn-03.txt
 Date: 11/03/2019
 Authors: Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka
 Working Group: Individual Submissions (none)
 Formats: txt
Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it to support the needs of new applications, particularly applications that are associated with 5G services. These applications require better isolation from both control and data plane's perspective and have more stringent performance requirements than can be provided with overlay VPNs. The characteristics of an enhanced VPN as perceived by its tenant needs to be comparable to those of a dedicated private network. This requires tight integration between the overlay VPN and the underlay network resources in a scalable manner. An enhanced VPN may form the underpinning of 5G network slicing, but will also be of use in its own right. This document describes the use of segment routing based mechanisms to provide the enhanced VPN service with dedicated network resources. The proposed mechanism is applicable to both SR with MPLS data plane and SR with IPv6 data plane (SRv6).
    
draft-donnerhacke-linktax-03.txt
 Rights for restricted content
 
 draft-donnerhacke-linktax-03.txt
 Date: 07/03/2019
 Authors: Lutz Donnerhacke
 Working Group: Individual Submissions (none)
 Formats: txt xml
Links are omnipresent in the Internet to provide access to other resources. There is no mechanism to express differences in law systems, access limitations, or arbitrary rules defined by the owner of the linked resource. Therefore links do depend on and enforce a communist sharing ideology, which ignores the content owner rights. Links may point to resources far away from the originating page, hiding this fact from the customer. It takes the data transport services for free, internet transit providers on the way from the content source to the customers are not extra payed for this effort. In many cases, the remote company generates huge amount of money from the customers worldwide not shared with the transit providers. In order to get the rights of all involved parties balanced, a new type of connection initiation is proposed: The Right.
    
draft-dorfner-core-simplemetadata-01.txt
 SimpleMetadata: An interoperable format for sharing metadata
 
 draft-dorfner-core-simplemetadata-01.txt
 Date: 24/03/2019
 Authors: Ralf Dorfner
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a standardized container format for storing serializable metadata. It does not describe any additional new format, but provides a shell for the exchange of arbitrary, structured data. It shall provide the possibility to store and share any kind of metadata, including encryption support. The idea is to create an open, universal and interoperable standard for storing and distributing every kind of metadata independent from media type or file format.
    
draft-draft-li-intent-classification-00.txt
 Intent Classification
 
 draft-draft-li-intent-classification-00.txt
 Date: 22/10/2018
 Authors: Chen Li, Ying Cheng, John Strassner, Olga Havel, Weiping Xu
 Working Group: Individual Submissions (none)
 Formats: txt
RFC 7575 [RFC7575] defines Intent as an abstract high-level policy used to operate the network. Intent management system includes an interface for users to input requests and an engine to translate the intents into the network configuration and manage their lifecycle. Up to now, there is no commonly agreed definition, interface or model of intent. This document discusses what intent means to different stakeholders, describes different ways to classify intent, and an associated taxonomy of this classification.
    
draft-dreibholz-ipv4-flowlabel-29.txt
 An IPv4 Flowlabel Option
 
 draft-dreibholz-ipv4-flowlabel-29.txt
 Date: 06/03/2019
 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-26.txt
 Applicability of Reliable Server Pooling for Real-Time Distributed Computing
 
 draft-dreibholz-rserpool-applic-distcomp-26.txt
 Date: 06/03/2019
 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-25.txt
 Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility
 
 draft-dreibholz-rserpool-applic-mobility-25.txt
 Date: 06/03/2019
 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-24.txt
 Handle Resolution Option for ASAP
 
 draft-dreibholz-rserpool-asap-hropt-24.txt
 Date: 06/03/2019
 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-23.txt
 Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling
 
 draft-dreibholz-rserpool-delay-23.txt
 Date: 06/03/2019
 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-21.txt
 Takeover Suggestion Flag for the ENRP Handle Update Message
 
 draft-dreibholz-rserpool-enrp-takeover-21.txt
 Date: 06/03/2019
 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-11.txt
 Ideas for a Next Generation of the Reliable Server Pooling Framework
 
 draft-dreibholz-rserpool-nextgen-ideas-11.txt
 Date: 06/03/2019
 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-24.txt
 Reliable Server Pooling (RSerPool) Bakeoff Scoring
 
 draft-dreibholz-rserpool-score-24.txt
 Date: 06/03/2019
 Authors: Thomas Dreibholz, Michael Tuexen
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.
    
draft-dreibholz-taps-neat-socketapi-04.txt
 NEAT Sockets API
 
 draft-dreibholz-taps-neat-socketapi-04.txt
 Date: 18/01/2019
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a BSD Sockets-like API on top of the callback-based NEAT User API. This facilitates porting existing applications to use a subset of NEAT's functionality.
    
draft-dreibholz-tsvwg-sctp-nextgen-ideas-09.txt
 Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)
 
 draft-dreibholz-tsvwg-sctp-nextgen-ideas-09.txt
 Date: 06/03/2019
 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-18.txt
 SCTP Socket API Extensions for Concurrent Multipath Transfer
 
 draft-dreibholz-tsvwg-sctpsocket-multipath-18.txt
 Date: 06/03/2019
 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-18.txt
 Sender Queue Info Option for the SCTP Socket API
 
 draft-dreibholz-tsvwg-sctpsocket-sqinfo-18.txt
 Date: 06/03/2019
 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-08.txt
 The Applicability of Reliable Server Pooling (RSerPool) for Virtual Network Function Resource Pooling (VNFPOOL)
 
 draft-dreibholz-vnfpool-rserpool-applic-08.txt
 Date: 31/01/2019
 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-dugeon-pce-stateful-interdomain-02.txt
 PCEP Extension for Stateful Inter-Domain Tunnels
 
 draft-dugeon-pce-stateful-interdomain-02.txt
 Date: 04/03/2019
 Authors: Olivier Dugeon, Julien Meuric, Young Lee, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document proposes to combine a Backward Recursive or Hierarchical method in Stateful PCE with PCInitiate message to setup independent paths per domain, and combine these different paths together in order to operate them as end-to-end inter-domain paths without the need of signaling session between AS border routers. A new Stitching Label is defined, new Path Setup Types and a new Association Type are considered for that purpose.
    
draft-duke-quic-load-balancers-03.txt
 QUIC-LB: Generating Routable QUIC Connection IDs
 
 draft-duke-quic-load-balancers-03.txt
 Date: 10/12/2018
 Authors: Martin Duke
 Working Group: Individual Submissions (none)
 Formats: xml txt
QUIC connection IDs allow continuation of connections across address/ port 4-tuple changes, and can store routing information for stateless or low-state load balancers. They also can prevent linkability of connections across deliberate address migration through the use of protected communications between client and server. This creates issues for load-balancing intermediaries. This specification standardizes methods for encoding routing information and proposes an optional protocol called QUIC_LB to exchange the parameters of that encoding.
    
draft-dukes-spring-sr-for-sdwan-01.txt
 SR For SDWAN: VPN with Underlay SLA
 
 draft-dukes-spring-sr-for-sdwan-01.txt
 Date: 04/12/2018
 Authors: Darren Dukes, Clarence Filsfils, Gaurav Dawra, Xiaohu Xu, daniel.voyer@bell.ca, Pablo Camarillo, Francois Clad, Stefano Salsano
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes how SR enables underlay Service Level Agreements (SLA) to a VPN with scale and security while ensuring service opacity. This solution applies to Over-The-Top VPN (OTT VPN) and Software-Defined WAN (SDWAN).
    
draft-dulaunoy-dnsop-passive-dns-cof-06.txt
 Passive DNS - Common Output Format
 
 draft-dulaunoy-dnsop-passive-dns-cof-06.txt
 Date: 08/04/2019
 Authors: Alexandre Dulaunoy, Aaron Kaplan, Paul Vixie, Henry Stern
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-07.txt
 MISP core format
 
 draft-dulaunoy-misp-core-format-07.txt
 Date: 03/02/2019
 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-galaxy-format-06.txt
 MISP galaxy format
 
 draft-dulaunoy-misp-galaxy-format-06.txt
 Date: 01/04/2019
 Authors: Alexandre Dulaunoy, Andras Iklody, Deborah Servili
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository [MISP-G] [MISP-G-DOC] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
    
draft-dulaunoy-misp-taxonomy-format-07.txt
 MISP taxonomy format
 
 draft-dulaunoy-misp-taxonomy-format-07.txt
 Date: 08/04/2019
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the MISP taxonomy format which describes a simple JSON format to represent machine tags (also called triple tags) vocabularies. A public directory of common vocabularies called MISP taxonomies is available and relies on the MISP taxonomy format. MISP taxonomies are used to classify cyber security events, threats, suspicious events, or indicators.
    
draft-dulaunoy-programming-methodology-framework-00.txt
 Programming Methodology Framework aka PMF
 
 draft-dulaunoy-programming-methodology-framework-00.txt
 Date: 11/04/2019
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Programming Methodology Framework also known under the PMF methodology. The methodology is based on the manifesto written by Zed A. Shaw [PROGRAMMING-MF-MANIFESTO] which describes a natural approach to software engineering with a strong focus on the act of programming. The PMF methodology uses a soft naming to allow for a non-partisan reference to official engineering or project documents describing one of the most used software engineering methodologies.
    
draft-dunbar-idr-sdwan-port-safi-01.txt
 Subsequent Address Family Indicator for SDWAN Ports
 
 draft-dunbar-idr-sdwan-port-safi-01.txt
 Date: 06/03/2019
 Authors: Linda Dunbar, Susan Hares, Haibo Wang, Hao Weiguo
 Working Group: Individual Submissions (none)
 Formats: txt
The document specifies a new BGP NLRI and SAFI for advertising properties of a SDWAN edge node WAN ports that face untrusted networks, such as the public internet. Those WAN ports may get assigned IP addresses from the Internet Service Providers (ISPs), may get assigned dynamic IP addresses via DHCP, or may have private addresses (e.g. inside third party Cloud DCs). Packets sent over those SDWAN WAN ports might need to be encrypted (depending on the user policies) or need to go through NAT. SDWAN edge need to propagate those WAN ports properties to its SDWAN controller, which propagates to the authorized peers and manage the IPsec SAs among those peers for encrypting traffic via the untrusted networks. BGP Route Reflectors (RR) are proposed as points of combination for this information in order to allow scaling of the SDWAN.
    
draft-dunbar-sr-sdwan-over-hybrid-networks-03.txt
 Segment routing for SD-WAN paths over hybrid networks
 
 draft-dunbar-sr-sdwan-over-hybrid-networks-03.txt
 Date: 28/02/2019
 Authors: Linda Dunbar, Mehmet Toy
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a method for end-to-end (E2E) SD-WAN paths to traverse specific list of network segments, some of which are private networks which include SR enabled segments, some of which may be the public IP networks that do not support SR, to achieve the desired optimal E2E quality. The method described in this draft uses the principle of segment routing to enforce a SD-WAN path' head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segment to have the intelligence (or maintaining states) of selecting next hop or next domain.
    
draft-dunglas-mercure-03.txt
 The Mercure Protocol
 
 draft-dunglas-mercure-03.txt
 Date: 09/01/2019
 Authors: Kevin Dunglas
 Working Group: Individual Submissions (none)
 Formats: txt xml
Mercure is a protocol enabling the pushing of data updates to web browsers and other HTTP clients in a fast, reliable and battery- efficient way. It is especially useful for publishing real-time updates of resources served through web APIs to reactive web and mobile apps.
    
draft-dupont-6man-nat64handoff-00.txt
 NAT64 Handoff
 
 draft-dupont-6man-nat64handoff-00.txt
 Date: 03/04/2019
 Authors: Kasper Dupont
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a NAT64 extension which allows IPv4 hosts to learn the real IP address of hosts which they are communicating with and assume responsibility to maintain the authoritative connection tracking table.
    
draft-dykim-6man-sid6-01.txt
 Subnet ID Deprecation for IPv6
 
 draft-dykim-6man-sid6-01.txt
 Date: 03/03/2019
 Authors: Kim Dy
 Working Group: Individual Submissions (none)
 Formats: txt xml
Deprecation of the subnet ID in IPv6 networking is proposed; the subnet ID is set to zero so that all nodes in a site carry the same prefix. While the procedures for neighbor discovery and duplicate address detection have to be changed, possible simplification gains in IPv6 networking including that of intra-site host- and subnet- mobility might be worth the modification. Site-external behaviors don't change through this modification, enabling incremental deployment of the proposal. Sites of manageable sizes for which scalability is not much a critical issue might consider the mode of operation proposed in this document.
    
draft-eastlake-bess-enhance-evpn-all-active-02.txt
 EVPN All Active Usage Enhancement
 
 draft-eastlake-bess-enhance-evpn-all-active-02.txt
 Date: 25/02/2019
 Authors: Donald Eastlake, Zhenbin Li, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: txt
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links.
    
draft-eastlake-bess-evpn-vxlan-bypass-vtep-02.txt
 EVPN VXLAN Bypass VTEP
 
 draft-eastlake-bess-evpn-vxlan-bypass-vtep-02.txt
 Date: 09/01/2019
 Authors: Donald Eastlake, Zhenbin Li, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) with all-active links. This draft specifies a mechanism to simplify PEs used with VXLAN tunnels and enhance VXLAN Active-Active reliability.
    
draft-eastlake-fnv-16.txt
 The FNV Non-Cryptographic Hash Algorithm
 
 draft-eastlake-fnv-16.txt
 Date: 10/12/2018
 Authors: Glenn Fowler, Landon Noll, Kiem-Phong Vo, Donald Eastlake, Tony Hansen
 Working Group: Individual Submissions (none)
 Formats: txt
FNV (Fowler/Noll/Vo) is a fast, non-cryptographic hash algorithm with good dispersion. The purpose of this document is to make information on FNV and open source code performing FNV conveniently available to the Internet community.
    
draft-eastlake-rfc6931bis-xmlsec-uris-09.txt
 Additional XML Security Uniform Resource Identifiers (URIs)
 
 draft-eastlake-rfc6931bis-xmlsec-uris-09.txt
 Date: 26/03/2019
 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-eckert-pim-igmp-mld-questionnaire-00.txt
 IGMP and MLD Questionnaire
 
 draft-eckert-pim-igmp-mld-questionnaire-00.txt
 Date: 28/03/2019
 Authors: mankamana mishra, Toerless Eckert, Hitoshi Asaeda, Anish Peter, Olufemi Komolafe, Suneesh Babu, Nicolai Leymann, Ramakanth Josyula, Timothy Winters
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides questionnaire to advance the IGMPv2, IGMPv3, and MLD v2 from Proposed standard to the Internet Standard.
    
draft-edwards-telnet-xon-xoff-state-control-00.txt
 Xon/Xoff State Control for Telnet Com Port Control Option
 
 draft-edwards-telnet-xon-xoff-state-control-00.txt
 Date: 23/03/2010
 Authors: Grant Edwards
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server.
    
draft-eggert-irtf-rfc2014bis-05.txt
 IRTF Research Group Guidelines and Procedures
 
 draft-eggert-irtf-rfc2014bis-05.txt
 Date: 23/11/2018
 Authors: Lars Eggert
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Internet Research Task Force (IRTF) has responsibility for organizing groups to investigate research topics related to the Internet protocols, applications, and technology. IRTF activities are organized into Research Groups. This document describes the guidelines and procedures for formation and operation of IRTF Research Groups. It describes the relationship between IRTF participants, Research Groups, the Internet Research Steering Group (IRSG) and the Internet Architecture Board (IAB). The basic duties of IRTF participants, including the IRTF Chair, Research Group Chairs and IRSG members are defined. This document obsoletes RFC2014.
    
draft-ekwk-capport-rfc7710bis-02.txt
 Captive-Portal Identification in DHCP / RA
 
 draft-ekwk-capport-rfc7710bis-02.txt
 Date: 11/03/2019
 Authors: Warren Kumari, Erik Kline
 Working Group: Individual Submissions (none)
 Formats: xml txt
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device, and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to, and interacting with the captive portal is out of scope of this document. [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-ekwk-capport-rfc7710bis. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. Text in square brackets will be removed before publication. ]
    
draft-elkschul-conflict-problem-01.txt
 Conflict Resolution within a Working Group: Problem Statement
 
 draft-elkschul-conflict-problem-01.txt
 Date: 05/12/2018
 Authors: Nalini Elkins, Henning Schulzrinne
 Working Group: Individual Submissions (none)
 Formats: txt
At the IETF, we currently use a set of methods to communicate a point of view, to solicit input, to resolve conflict and attempt to obtain consensus within the group. These methods include: writing an Internet Draft, discussion on email lists, discussion at face-to- face, interim or virtual meetings, and design teams. At times, these methods fall short. People become entrenched in their positions. A Working Group may be split for a prolonged period wasting time and energy. There may be a lasting impact. While the authors support rough consensus, the collateral damage of this process, at times can be considerable. This document discusses the benefits and drawbacks of each of the current methods of communication focusing solely on their efficacy at conflict resolution. A companion document will propose some solutions including alternative methods of conflict resolution.
    
draft-emailwhois-pradeepkumarxplorer-01.txt
 Extensions to WHois service to allow query on email identities
 
 draft-emailwhois-pradeepkumarxplorer-01.txt
 Date: 18/10/2018
 Authors: pradeep xplorer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the need for a WHois email address service similar to the internet domainname WHois service. Theres a need for a registered email address as opposed to non-registered email address to fight internet SPAM, as well as encouraging email use for personal, commercial and legal and all kinds of purposes.An internet user can have multiple email identities.
    
draft-enghardt-panrg-path-properties-01.txt
 A Vocabulary of Path Properties
 
 draft-enghardt-panrg-path-properties-01.txt
 Date: 11/03/2019
 Authors: Theresa Enghardt, Cyrill Krahenbuhl
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines and categorizes information about Internet paths that an entity, such as an endpoint, might have or want to have. This information is expressed as properties of paths between two endpoints.
    
draft-enhanced-xml-digital-signature-algorithm-01.txt
 Enhanced XML Digital Signature Algorithm to Mitigate Wrapping Attacks
 
 draft-enhanced-xml-digital-signature-algorithm-01.txt
 Date: 04/02/2019
 Authors: Jitendra Kumar, Balaji Rajendran, Bindhumadhava BS
 Working Group: Individual Submissions (none)
 Formats: xml txt
XML signature standard [RFC3275]identifies signed elements by their unique identities in the XML document. However this allows shifting of XML elements from one location to another within the same XML document, without affecting the ability to verify the signature. This flexibility paves the way for an attacker to tweak the original XML message without getting noticed by the receiver, leading to XML Signature wrapping or rewriting attacks. This document proposes to use absolute XPath as a "Positional Token" and modifies the existing XML Digital Signature algorithm to overcome this attack.
    
draft-even-avtcore-priority-markings-03.txt
 Frame Priority Marking RTP Header Extension
 
 draft-even-avtcore-priority-markings-03.txt
 Date: 23/12/2018
 Authors: Roni Even, Ofer Idan
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document updates the Frame Marking RTP header extension in draft-ietf-avtext-framemarking-06 used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middle-boxes or network nodes. The flags for frame marking for non-scalable streams include the D bit to mark a frame that can be discarded, and still provide a decodable media stream. There is also the I bit for frames that can be decoded independent of prior frames, e.g. intra-frame. This memo adds priority values for the non-scalable streams discardable frames
    
draft-even-fast-congestion-response-00.txt
 Fast Congestion Response
 
 draft-even-fast-congestion-response-00.txt
 Date: 10/03/2019
 Authors: Roni Even
 Working Group: Individual Submissions (none)
 Formats: txt pdf
The high link speed (100Gb/s) in Data Centers (DC) are making network transfers complete faster and in fewer RTTs. The short data bursts requires low latency while longer data transfer require high throughput. This document describes the current state of flow control and congestion handling in the DC using RoCEv2 and suggests new directions for faster congestion control.
    
draft-evenwu-opsawg-yang-composed-vpn-03.txt
 YANG Data Model for Composed VPN Service Delivery
 
 draft-evenwu-opsawg-yang-composed-vpn-03.txt
 Date: 08/03/2019
 Authors: Roni Even, Wu Bo, Qin Wu, Ying Cheng
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG data model that can be used by a network operator to configure a VPN service that spans multiple administrative domains and that is constructed from component VPNs in each of those administrative domains. The component VPNs may be L2VPN or L3VPN or a mixture of the two. This model is intended to be instantiated at the management system to deliver the end to end service (i.e., performing service provision and activation functions at different levels through a unified interface). The model is not a configuration model to be used directly on network elements. This model provides an abstracted common view of VPN service configuration components segmented at different layer and administrative domain. It is up to a management system to take this as an input and generate specific configurations models to configure the different network elements within each administrative domain to deliver the service. How configuration of network elements is done is out of scope of the document.
    
draft-fairhurst-udp-options-cco-00.txt
 Checksum Compensation Options for UDP Options
 
 draft-fairhurst-udp-options-cco-00.txt
 Date: 19/10/2018
 Authors: Gorry Fairhurst, Tom Jones, Raffaele Zullo
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a robust method for calculating checksums for use with UDP Options. The new method proposes an alternative checksum calculation for coverage of the option space. This is based on the IP checksum calculation, but uses an updated pseudoheader. The new method only checks the option portion of a UDP packet, but creates a checksum that compensates for the range of IP and UDP chekcsum validation methods that have been deployed, in this way the new method enhances the proability of NAPT traversal for packets that carry UDP-Options.
    
draft-faltstrom-unicode11-08.txt
 IDNA2008 and Unicode 11.0.0
 
 draft-faltstrom-unicode11-08.txt
 Date: 11/03/2019
 Authors: Patrik Faltstrom
 Working Group: Applications and Real-Time Area (art)
 Formats: txt xml
This document describes the changes between Unicode 6.3.0 and Unicode 11.0.0 in the context of IDNA2008. Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. Although IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document does not add any such exceptions. This document provides the necessary tables to IANA to make its database consisstent with Unicode 11.0.0. To improve understanding, this document describes systems that are being used as alternatives to those that conform to IDNA2008. TO BE REMOVED AT TIME OF PUBLICATION AS AN RFC: This document is discussed on the i18nrp@ietf.org mailing list of the IETF.
    
draft-faltstrom-unicode12-00.txt
 IDNA2008 and Unicode 12.0.0
 
 draft-faltstrom-unicode12-00.txt
 Date: 11/03/2019
 Authors: Patrik Faltstrom
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
This document describes the changes between Unicode 6.3.0 and Unicode 12.0.0 in the context of IDNA2008. Some additions and changes have been made in the Unicode Standard that affect the values produced by the algorithm IDNA2008 specifies. Although IDNA2008 allows adding exceptions to the algorithm for backward compatibility; however, this document does not add any such exceptions. This document provides the necessary tables to IANA to make its database consisstent with Unicode 12.0.0. To improve understanding, this document describes systems that are being used as alternatives to those that conform to IDNA2008. TO BE REMOVED AT TIME OF PUBLICATION AS AN RFC: This document is discussed on the i18nrp@ietf.org mailing list of the IETF.
    
draft-farinacci-lisp-decent-03.txt
 A Decent LISP Mapping System (LISP-Decent)
 
 draft-farinacci-lisp-decent-03.txt
 Date: 10/03/2019
 Authors: Dino Farinacci, Colin Cantrell
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust.
    
draft-farinacci-lisp-geo-07.txt
 LISP Geo-Coordinate Use-Cases
 
 draft-farinacci-lisp-geo-07.txt
 Date: 11/04/2019
 Authors: Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols.
    
draft-farinacci-lisp-mobile-network-05.txt
 LISP for the Mobile Network
 
 draft-farinacci-lisp-mobile-network-05.txt
 Date: 07/03/2019
 Authors: Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: txt
This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network.
    
draft-farinacci-lisp-name-encoding-07.txt
 LISP Distinguished Name Encoding
 
 draft-farinacci-lisp-name-encoding-07.txt
 Date: 07/03/2019
 Authors: Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines how to use the AFI=17 Distinguished Names in LISP.
    
draft-farinacci-lisp-telemetry-01.txt
 LISP Data-Plane Telemetry
 
 draft-farinacci-lisp-telemetry-01.txt
 Date: 28/12/2018
 Authors: Dino Farinacci, Said Ouissal, Erik Nordmark
 Working Group: Individual Submissions (none)
 Formats: txt
This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages.
    
draft-farmer-6man-routing-64-02.txt
 IPv6 Routing and its Relationship to the 64-bit Boundary in the IPv6 Addressing Architecture
 
 draft-farmer-6man-routing-64-02.txt
 Date: 06/01/2019
 Authors: David Farmer
 Working Group: Individual Submissions (none)
 Formats: xml txt
There is a common misconception that the IPv6 Addressing Architecture requires the use of only /64 subnet prefixes for subnet routing. This document clarifies the characterization of the relationship between IPv6 routing and the 64 bit boundary, which is that of a recommendation for the use of /64 subnet prefixes for subnet routing in most circumstances, not a requirement for such. To further clarify this relationship, the document also provides operational guidance for the configuration of subnet prefixes and updates RFC 4291 accordingly.
    
draft-fattore-dmm-n6-cpdp-trafficsteering-01.txt
 Control-/Data Plane Aspects for N6 Traffic Steering
 
 draft-fattore-dmm-n6-cpdp-trafficsteering-01.txt
 Date: 11/03/2019
 Authors: Umberto Fattore, Marco Liebsch
 Working Group: Individual Submissions (none)
 Formats: txt
Current standardization effort on the evolution of the mobile communication system reconsiders the mobile data plane protocol. The IETF DMM Working Group has work that proposes and analyzes various protocols as alternative to the GPRS Tunneling Protocol for User Plane (GTP-U) for an overlay deployment in between the mobile device's assigned data plane anchor and its current radio base station, which are denoted as N9 and N3 interfaces. In the view of some future deployment and the original intent per the very early DMM WG charter, a mobile device's data plane anchor may be highly distributed and re-selected for optimization throughout a mobile device's communication with one or more correspondent services. Such re-configuration has impact on the packet routing in between the mobile device's data plane anchor and the one or multiple data networks hosting the services, which is denoted as N6 interface. This draft proposes and discusses a solution to control, setup and maintain traffic treatment policy on the cellular communication system's N6 interface while taking the UE's PDU session settings per the cellular system's control plane, such as QoS and locator information, into account.
    
draft-fear-ippm-mpdm-02.txt
 IPv6 Marking and Performance and Diagnostic Metrics (MPDM)
 
 draft-fear-ippm-mpdm-02.txt
 Date: 21/10/2018
 Authors: Nalini Elkins, Giuseppe Fioccola, mackermann@bcbsm.com, Rob Hamilton
 Working Group: Individual Submissions (none)
 Formats: txt
To assess performance problems, this document describes optional headers embedded in each packet that provide marking, sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real-time or after the fact. This document specifies the IPv6 Marking and Performance and Diagnostic Metrics (M-PDM) Hop-byHop and Destination Options extension headers.
    
draft-ferrieux-hamchaoui-quic-lossbits-00.txt
 The QUIC Loss Bits
 
 draft-ferrieux-hamchaoui-quic-lossbits-00.txt
 Date: 09/04/2019
 Authors: Alexandre Ferrieux, Isabelle Hamchaoui
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the addition of loss bits to the QUIC transport protocol and describes how to use them to measure and locate packet loss. Note to Readers This document specifies an experimental delta to the QUIC transport protocol.
    
draft-ferrieuxhamchaoui-quic-lossbits-00.txt
 The QUIC Loss Bits
 
 draft-ferrieuxhamchaoui-quic-lossbits-00.txt
 Date: 09/04/2019
 Authors: Alexandre Ferrieux, Isabelle Hamchaoui
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the addition of loss bits to the QUIC transport protocol and describes how to use them to measure and locate packet loss. Note to Readers This document specifies an experimental delta to the QUIC transport protocol.
    
draft-fett-oauth-dpop-01.txt
 OAuth 2.0 Demonstration of Proof-of-Possession at the Application Layer
 
 draft-fett-oauth-dpop-01.txt
 Date: 02/04/2019
 Authors: Daniel Fett, John Bradley, Brian Campbell, Torsten Lodderstedt, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a mechanism for sender-constraining OAuth 2.0 tokens via a proof-of-possession mechanism on the application level. This mechanism allows to detect replay attacks with access and refresh tokens.
    
draft-fiebig-security-acme-00.txt
 Extended Security Considerations for the Automatic Certificate Management Environment (ESecACME)
 
 draft-fiebig-security-acme-00.txt
 Date: 11/01/2019
 Authors: Tobias Fiebig, Kevin Borgolte
 Working Group: Individual Submissions (none)
 Formats: txt
Most Public Key Infrastructure X.509 (PKIX) certificates are issued via the ACME protocol. Recently, several attacks against domain validation (DV) have been published, including IP-use-after-free and (forced) on-path attacks. These attacks can often be mitigated by (selectively) requiring additional challenges, such as DNS validation, proof of ownership of a prior certificate, and by being more diligent in operating a certificate authority. This document provides a list of currently known attacks and describes mitigations and operational procedures to prevent issuing a certificate to an unauthorized party.
    
draft-filsfils-spring-large-scale-interconnect-13.txt
 Interconnecting Millions Of Endpoints With Segment Routing
 
 draft-filsfils-spring-large-scale-interconnect-13.txt
 Date: 05/03/2019
 Authors: Clarence Filsfils, Stefano Previdi, Gaurav Dawra, Wim Henderickx, Dave Cooper
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use-case can be applied to the interconnection of massive-scale DCs and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries. This may be achieved by inherert scaleable nature of Segment Routing and designed proposed in this document.
    
draft-filsfils-spring-sr-policy-considerations-03.txt
 SR Policy Implementation and Deployment Considerations
 
 draft-filsfils-spring-sr-policy-considerations-03.txt
 Date: 16/04/2019
 Authors: Clarence Filsfils, Ketan Talaulikar, Przemyslaw Krol, Martin Horneffer, Paul Mattes
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. SR Policy framework enables the instantiation and the management of necessary state on the headend node for flows along a source routed paths using an ordered list of segments associated with their specific SR Policies. This document describes some of the implementation and deployment aspects that are useful for operationalizing the SR Policy architecture.
    
draft-filsfils-spring-srv6-interop-02.txt
 SRv6 interoperability report
 
 draft-filsfils-spring-srv6-interop-02.txt
 Date: 04/03/2019
 Authors: Clarence Filsfils, Francois Clad, Pablo Camarillo, Ahmed Abdelsalam, Stefano Salsano, Olivier Bonaventure, Jakub Horn, Jose Liste
 Working Group: Individual Submissions (none)
 Formats: txt xml
Segment Routing (SR) can be applied to the IPv6 data plane by leveraging a new type of routing extension header, called Segment Routing Header (SRH). An SRH contains an ordered list, or sequence, of segments representing topological or service-based instructions, or any combination of those. This draft provides an overview of IPv6 Segment Routing (SRv6) implementations and interoperability. It makes an inventory of the various pieces of hardware and software that have been demonstrated to support the processing of an SRH, and details some interoperability scenarios that have been showcased at a public event.
    
draft-filsfils-spring-srv6-net-pgm-illustration-00.txt
 Illustrations for SRv6 Network Programming
 
 draft-filsfils-spring-srv6-net-pgm-illustration-00.txt
 Date: 14/02/2019
 Authors: Clarence Filsfils, Pablo Camarillo, Zhenbin Li, Satoru Matsushima, Bruno Decraene, Dirk Steinberg, David Lebrun, Robert Raszuk, John Leddy
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document illustrates how SRv6 Network Programming [I-D.filsfils-spring-srv6-network-programming] can be used to create interoperable and protected overlays with underlay optimization and service programming.
    
draft-filsfils-spring-srv6-network-programming-07.txt
 SRv6 Network Programming
 
 draft-filsfils-spring-srv6-network-programming-07.txt
 Date: 14/02/2019
 Authors: Clarence Filsfils, Pablo Camarillo, John Leddy, daniel.voyer@bell.ca, Satoru Matsushima, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the SRv6 network programming concept and its most basic functions.
    
draft-finkelman-httpbis-has-redirecting-00.txt
 HTTP Redirects in HTTP Adaptive Streaming
 
 draft-finkelman-httpbis-has-redirecting-00.txt
 Date: 04/11/2018
 Authors: Ori Finkelman, Ali Begen
 Working Group: Individual Submissions (none)
 Formats: txt
This document motivates the need for clarifications of client behavior in cases of HTTP redirect to a content delivery network (CDN) when the redirected object contains relative references. This document focuses on HTTP Adaptive Streaming (HAS) use cases, but it might be possible to generalize to other use cases. The goal of this document is to present the current status of things and to explore potential solutions.
    
draft-finn-detnet-bounded-latency-03.txt
 DetNet Bounded Latency
 
 draft-finn-detnet-bounded-latency-03.txt
 Date: 11/03/2019
 Authors: Norman Finn, Jean-Yves Le Boudec, Ehsan Mohammadpour, Jiayi Zhang, Balazs Varga, Janos Farkas
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document presents a parameterized timing model for Deterministic Networking (DetNet), so that existing and future standards can achieve the DetNet quality of service features of bounded latency and zero congestion loss. It defines requirements for resource reservation protocols or servers. It calls out queuing mechanisms, defined in other documents, that can provide the DetNet quality of service.
    
draft-finzi-priority-switching-scheduler-04.txt
 Priority Switching Scheduler
 
 draft-finzi-priority-switching-scheduler-04.txt
 Date: 22/10/2018
 Authors: Fred Baker, Anais Finzi, Fabrice Frances, Nicolas Kuhn, Emmanuel Lochin, Ahlem Mifdaoui
 Working Group: Individual Submissions (none)
 Formats: txt xml
We detail the implementation of a network rate scheduler based on both a packet-based implementation of the generalized processor sharing (GPS) and a strict priority policies. This credit based scheduler called Priority Switching Scheduler (PSS), inherits from the standard Strict Priority Scheduler (SP) but dynamically changes the priority of one or several queues. Usual scheduling architectures often combine rate schedulers with SP to implement DiffServ service classes. Furthermore, usual implementations of rate scheduler schemes (such as WRR, DRR, ...) do not allow to efficiently guarantee the capacity dedicated to both AF and DF DiffServ classes as they mostly provide soft bounds. This means excessive margin is used to ensure the capacity requested and this impacts the number of additional users that could be accepted in the network. PSS allows a more predictable output rate per traffic class and is a one fit all scheme allowing to enable both SP and rate scheduling policies within a single algorithm.
    
draft-flanagan-fiftyyears-05.txt
 Fifty Years of RFCs
 
 draft-flanagan-fiftyyears-05.txt
 Date: 18/04/2019
 Authors: Heather Flanagan
 Working Group: Individual Submissions (none)
 Formats: txt xml
This RFC marks the fiftieth anniversary for the RFC Series. It includes both retrospective material from individuals involved at key inflection points, as well as a review of the current state of affairs. It concludes with thoughts on possibilities for the next fifty years for the Series. This document updates and brings current the history started in RFCs 2555 and 5540.
    
draft-fmm-nvo3-pm-alt-mark-03.txt
 Performance Measurement (PM) with Alternate Marking in Network Virtualization Overlays (NVO3)
 
 draft-fmm-nvo3-pm-alt-mark-03.txt
 Date: 23/10/2018
 Authors: Giuseppe Fioccola, Gregory Mirsky, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how the alternate marking method can be used for performance measurement method in a Network Virtualization Overlays (NVO3) Domain. The description aims to be general for NVO3 encapsulations, but is focused to Geneve, recommended by the NVO3 design team [I-D.ietf-nvo3-encap].
    
draft-foglar-ipv6-ull-routing-04.txt
 IPv6 Source Routing for ultralow Latency
 
 draft-foglar-ipv6-ull-routing-04.txt
 Date: 20/01/2019
 Authors: Andreas Foglar, Mike Parker, Theodoros Rokkas
 Working Group: Individual Submissions (none)
 Formats: txt
This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for very fast source routing experimentation using simple forwarding nodes. Research groups evaluate achievable latency reduction for special applications such as radio access networks, industrial networks or other networks requiring very low latency.
    
draft-fossati-tsvwg-lola-00.txt
 A Loss-Latency Trade-off Signal for the Mobile Network
 
 draft-fossati-tsvwg-lola-00.txt
 Date: 16/12/2018
 Authors: Thomas Fossati, Gorry Fairhurst, Pedro Gutierrez, Mirja Kuehlewind
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a marking scheme for tagging low-latency flows (for example: interactive voice and video, gaming, machine to machine applications) that is safe to use by the mobile network for matching such flows to suitable per-hop behaviors (EPS bearers defined by 3GPP) in its core and radio segments. The suggested scheme re-uses NQB, a DiffServ-based signalling scheme with compatible rate-delay trade-off semantics that has been recently introduced in the context of fixed access to allow differential treatment of non-queue building vs queue building flows.
    
draft-foudil-securitytxt-06.txt
 A Method for Web Security Policies
 
 draft-foudil-securitytxt-06.txt
 Date: 08/04/2019
 Authors: Edwin Foudil, Yakov Shafranovich
 Working Group: Individual Submissions (none)
 Formats: txt
When security vulnerabilities are discovered by independent security researchers, they often lack the channels to report them properly. As a result, security vulnerabilities may be left unreported. This document defines a format ("security.txt") to help organizations describe the process for security researchers to follow in order to report security vulnerabilities.
    
draft-fregly-regext-rdap-search-regex-04.txt
 Registration Data Access Protocol (RDAP) Search Using POSIX Regular Expressions
 
 draft-fregly-regext-rdap-search-regex-04.txt
 Date: 01/06/2018
 Authors: afregly@verisign.com, Swapneel Sheth, Scott Hollenbeck
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Registration Data Access Protocol (RDAP) provides limited search functionality based on pattern matching. This document describes an RDAP query extension that provides additional search functionality using POSIX extended regular expressions.
    
draft-friel-anima-brski-over-802dot11-00.txt
 BRSKI over IEEE 802.11
 
 draft-friel-anima-brski-over-802dot11-00.txt
 Date: 18/10/2018
 Authors: Owen Friel, Eliot Lear, Jerome Henry, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document outlines the challenges associated with implementing Bootstrapping Remote Secure Key Infrastructures over IEEE 802.11 and IEEE 802.1x networks. Multiple options are presented for discovering and authenticating to the correct IEEE 802.11 SSID. This draft is a discussion document and no final recommendations are made on the recommended approaches to take. However, the advantages and downsides of each possible method are evaluated.
    
draft-friel-tls-atls-02.txt
 Application-Layer TLS
 
 draft-friel-tls-atls-02.txt
 Date: 11/03/2019
 Authors: Owen Friel, Richard Barnes, Max Pritikin, Hannes Tschofenig, Mark Baugher
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies how TLS sessions can be established at the application layer over untrusted transport between clients and services for the purposes of establishing secure end-to-end encrypted communications channels. Transport layer encodings for application layer TLS records are specified for HTTP and CoAP transport. Explicit identification of application layer TLS packets enables middleboxes to provide transport services and enforce suitable transport policies for these payloads, without requiring access to the unencrypted payload content. Multiple scenarios are presented identifying the need for end-to-end application layer encryption between clients and services, and the benefits of reusing the well- defined TLS protocol, and a standard TLS stack, to accomplish this are described. Application software architectures for building, and network architectures for deploying application layer TLS are outlined.
    
draft-fries-anima-brski-async-enroll-00.txt
 Support of asynchronous Enrollment in BRSKI
 
 draft-fries-anima-brski-async-enroll-00.txt
 Date: 11/03/2019
 Authors: Steffen Fries, Hendrik Brockhaus, Eliot Lear
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses the enhancement of automated bootstrapping of a remote secure key infrastructure (BRSKI) to operate in domains featuring no or only timely limited connectivity to backend services offering enrollment functionality like a Public Key Infrastructure (PKI). In the context of deploying new devices the design of BRSKI allows for online (synchronous object exchange) and offline interactions (asynchronous object exchange) with a manufacturer's authorization service. It utilizes a self-contained voucher to transport the domain credentials as a signed object to establish an initial trust between the pledge and the deployment domain. The currently supported enrollment protocol for request and distribution of deployment domain specific device certificates provides only limited support for asynchronous PKI interactions. This memo motivates support of self-contained objects also for certificate management by using an abstract notation to allow off-site operation of PKI services, with only limited connectivity to the pledge deployment domain. This addresses specifically scenarios, in which the deployment domain of a pledge does not perform the final authorization of a certification request and rather delegates this decision to an operator backend. The goal is to enable the usage of existing and potentially new PKI protocols supporting self- containment for certificate management.
    
draft-fujiwara-dnsop-fragment-attack-01.txt
 Measures against cache poisoning attacks using IP fragmentation in DNS
 
 draft-fujiwara-dnsop-fragment-attack-01.txt
 Date: 01/03/2019
 Authors: Kazunori Fujiwara
 Working Group: Individual Submissions (none)
 Formats: txt
Researchers proposed practical DNS cache poisoning attacks using IP fragmentation. This document shows feasible and adequate measures at full-service resolvers and authoritative servers against these attacks. To protect resolvers from these attacks, avoid fragmentation (limit requestor's UDP payload size to 1220/1232), drop fragmented UDP DNS responses and use TCP at resolver side. To make a domain name robust against these attacks, limit EDNS0 Responder's maximum payload size to 1220, set DONTFRAG option to DNS response packets and use good random fragmentation ID at authoritative server side.
    
draft-fussell-acvp-spec-00.txt
 Automated Cryptographic Validation Protocol
 
 draft-fussell-acvp-spec-00.txt
 Date: 21/02/2019
 Authors: Barry Fussell, Apostol Vassilev, Harold Booth
 Working Group: Individual Submissions (none)
 Formats: xml txt
The ACV Protocol provides a method for communication between a cryptographic module that is embedded inside of a device or otherwise running on a platform accessible via computer network, and an external testing system, using standard network communication interfaces and protocols. This communication protocol can also be used to validate the correctness of the algorithm implementations in the cryptographic module with a validation authority.
    
draft-gafni-ippm-ioam-ipv4-options-00.txt
 In-situ OAM IPv4 Options
 
 draft-gafni-ippm-ioam-ipv4-options-00.txt
 Date: 09/03/2019
 Authors: Barak Gafni, Aviv Kfir, Shwetha Bhandari, Frank Brockners, Ramesh Sivakolundu, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt xml
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in IPv4.
    
draft-galimbe-ccamp-iv-yang-08.txt
 A YANG model to manage the optical parameters for in a WDM network
 
 draft-galimbe-ccamp-iv-yang-08.txt
 Date: 11/03/2019
 Authors: Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a Yang model that translate the information model to support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functionality. The information model is defined in draft-ietf- ccamp-wson-iv-info and draft-martinelli-ccamp-wson-iv-encode. This document defines proper encoding and extend to the models defined in draft-lee-ccamp-wson-yang tu support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functions The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the multivendor Endpoints and ROADMs. The use of this model does not guarantee interworking of transceivers over a DWDM. Optical path feasibility and interoperability has to be determined by means outside the scope of this document. The purpose of this model is to program interface parameters to consistently configure the mode of operation of transceivers.
    
draft-galis-precision-netslices-problem-statement-00.txt
 Management of Precision Network Slicing - Problem Statement
 
 draft-galis-precision-netslices-problem-statement-00.txt
 Date: 04/11/2018
 Authors: A. Galis
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces Precision Network Slicing Management problems and their context. It represents an initial review of the Management of Network Slicing problem statement derived from the analysis of the technical gaps in IETF protocols ecosystem. It complements and brings together the efforts being carried out in several other IETF working groups covering certain aspects of Network Slicing management functions and operations.
    
draft-gandhi-spring-ioam-sr-mpls-00.txt
 Segment Routing with MPLS Data Plane encapsulation for In-situ OAM Data
 
 draft-gandhi-spring-ioam-sr-mpls-00.txt
 Date: 23/10/2018
 Authors: Rakesh Gandhi, Zafar Ali, Clarence Filsfils, Frank Brockners, Bin Wen, Voitek Kozak
 Working Group: Individual Submissions (none)
 Formats: txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the data packet while the packet traverses a path between two points in the network. This document defines how IOAM data fields are transported with the Segment Routing with MPLS data plane (SR-MPLS) encapsulation.
    
draft-gandhi-spring-rfc6374-srpm-mpls-00.txt
 In-band Performance Measurement for Segment Routing Networks with MPLS Data Plane
 
 draft-gandhi-spring-rfc6374-srpm-mpls-00.txt
 Date: 14/02/2019
 Authors: Rakesh Gandhi, Clarence Filsfils, daniel.voyer@bell.ca, Stefano Salsano, Pier Ventre, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt
RFC 6374 specifies protocol mechanisms to enable the efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay variation in MPLS networks using probe messages. This document reviews how these mechanisms can be used for Delay and Loss Performance Measurements (PM) in Segment Routing (SR) networks with MPLS data plane (SR-MPLS), for both SR links and end-to-end SR Policies. The performance measurements for SR links are used to compute extended Traffic Engineering (TE) metrics for delay and loss and are advertised in the network using the routing protocol extensions.
    
draft-gandhi-spring-rfc6374-srpm-udp-00.txt
 In-band Performance Measurement Using UDP Path for Segment Routing Networks
 
 draft-gandhi-spring-rfc6374-srpm-udp-00.txt
 Date: 14/02/2019
 Authors: Rakesh Gandhi, Clarence Filsfils, daniel.voyer@bell.ca, Stefano Salsano, Pier Ventre, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document specifies procedures for using UDP path for sending and processing in-band probe query and response messages for Performance Measurement. The procedure uses the RFC 6374 defined mechanisms for Delay and Loss performance measurement. The procedure specified is applicable to SR-MPLS and SRv6 data planes for both links and end-to-end measurement for SR Policies. In addition, this document defines Return Path TLV for two-way performance measurement and Block Number TLV for loss measurement.
    
draft-gandhi-spring-twamp-srpm-00.txt
 In-band Performance Measurement Using TWAMP for Segment Routing Networks
 
 draft-gandhi-spring-twamp-srpm-00.txt
 Date: 09/02/2019
 Authors: Rakesh Gandhi, Clarence Filsfils, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document specifies procedures for sending and processing in-band probe query and response messages for Performance Measurement. The procedure uses the mechanisms defined in RFC 5357 (Two-Way Active Measurement Protocol (TWAMP)) for Delay Measurement, and also uses the mechanisms for direct-mode loss measurement defined in this document. The procedure specified is applicable to SR-MPLS and SRv6 data planes for both links and end-to-end measurement for SR Policies.
    
draft-gao-bess-evpn-blackhole-01.txt
 EVPN blackhole community extention for Blackholing
 
 draft-gao-bess-evpn-blackhole-01.txt
 Date: 17/01/2019
 Authors: Yuan Gao, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: txt
Ethernet Virtual Private Networks (EVPN) is becoming the de-facto standard-based control plane solution for Data Center and layer-2 Service Provider applications.The risk of hacking and DDos attacks within the EVPN network is general common concern.Blackhole mac is a method used to block hacking or DDos attacks, The network device discard the packets where destionation match the blackhole mac.Normally blackhole mac is mannually configured on the networkdevic,Configure blackhole mac is complex and error-prone task for network operators.This document introduces a blackhole community extension for evpn mac route to distribute the blackhole mac in the EVPN networks.The evpn mac route with blackhole community allows the bgp speaker to notify the recipients the specific mac is a blackhole mac.
    
draft-gao-flexible-session-protocol-02.txt
 Flexible Session Protocol
 
 draft-gao-flexible-session-protocol-02.txt
 Date: 16/04/2019
 Authors: Jun-an, Gao
 Working Group: Individual Submissions (none)
 Formats: txt
FSP is a connection-oriented transport layer protocol that provides mobility and multihoming support by introducing the concept of 'upper layer thread ID', which is associated with some shared secret that is applied to protect authenticity of the origin of the FSP packets. It introduces the concept of transmit transaction to facilitate a quad-party sub-protocol for shared secret installation. It provides transport layer features of zero round-trip connection multiplication and on-the-wire compression, in addition to ubiquitous message authentication with optional encryption service.
    
draft-gao-fsp-motivations-01.txt
 Motivations and Design Choices of the Flexible Session Protocol
 
 draft-gao-fsp-motivations-01.txt
 Date: 14/04/2019
 Authors: Jun-an, Gao
 Working Group: Individual Submissions (none)
 Formats: txt
This document introduces the motivation to design the Flexible Session Protocol which supports mobility and multihoming at the transport layer. FSP is to avoid, if not to extirpate, the routing scalability problem in the IPv6 internetwork. The document serves to explain choices of design goals of FSP as well.
    
draft-garciamorchon-t2trg-automated-iot-security-01.txt
 Automated IoT Security
 
 draft-garciamorchon-t2trg-automated-iot-security-01.txt
 Date: 19/10/2018
 Authors: Oscar Garcia-Morchon, Thorsten Dahm
 Working Group: Individual Submissions (none)
 Formats: txt
The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs are well-recognized but the design space of IoT applications and systems is complex and exposed to multiple types of threats. In particular, threats keep evolving at a fast pace while many IoT systems are rarely updated and still remain operational for decades. This document describes a comprehensive agile security framework to integrate existing security processes such as risk assessment or vulnerability assessment in the lifecycle of a smart object in an IoT application. The core of our agile security approach relies on two protocols: the Protocol for Automatic Security Configuration (PASC) and the Protocol for Automatic Vulnerability Assessment (PAVA). PASC is executed during the onboarding phase of a smart object in an IoT system and is in charge of automatically performing a risk assessment and assigning a security configuration - applicable to the device or the system - to defeat the identified risks. The assigned security configuration fits the specific environment and threat model of the application in which the device has been deployed. PAVA is executed during the operation of the IoT object and ensures that vulnerabilities in the smart object and IoT system are discovered in a proactive way. These two protocols can benefit users, manufactures and operators by automating IoT security.
    
draft-geib-ippm-connectivity-monitoring-00.txt
 A Connectivity Monitoring Metric for IPPM
 
 draft-geib-ippm-connectivity-monitoring-00.txt
 Date: 11/03/2019
 Authors: Ruediger Geib
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routed measurement packets can be sent along pre-determined paths. This allows new kinds of measurements. Connectivity monitoring allows to supervise the state of a connection or a (sub)path from one or a few central monitoring systems. This document specifies a suitable type-P connectivity monitoring metric.
    
draft-geng-detnet-dp-sol-srv6-00.txt
 DetNet SRv6 Data Plane Encapsulation
 
 draft-geng-detnet-dp-sol-srv6-00.txt
 Date: 11/03/2019
 Authors: Xuesong Geng, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies Deterministic Networking data plane operation for SRv6 encapsulated user data.
    
draft-geng-detnet-info-distribution-03.txt
 IGP-TE Extensions for DetNet Information Distribution
 
 draft-geng-detnet-info-distribution-03.txt
 Date: 22/10/2018
 Authors: Xuesong Geng, Mach Chen, Zhenqiang Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document extends the IGP-TE, including OSPF-TE and ISIS-TE, to support DetNet by specifying new information that can be placed in Link State Protocol Data Units (LSP). This information describes additional details regarding the state of the network that are useful for DetNet computations.
    
draft-geng-detnet-requirements-bounded-latency-01.txt
 Technical Requirements of Bounded Latency Forwarding
 
 draft-geng-detnet-requirements-bounded-latency-01.txt
 Date: 07/03/2019
 Authors: Liang Geng, Li Qiang, Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyses the technical requirements that Layer 3 bounded latency forwarding scheme should satisfy.
    
draft-gerdes-ace-c3dc-00.txt
 C3DC -- Constrained Client/Cross-Domain Capable Authorization Profile for Authentication and Authorization for Constrained Environments (ACE)
 
 draft-gerdes-ace-c3dc-00.txt
 Date: 23/10/2018
 Authors: Stefanie Gerdes, Olaf Bergmann, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
Resource-constrained nodes come in various sizes and shapes and often have constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document specifies a profile that describes how two autonomous resource-constrained devices, a client and a server, obtain the required keying material and authorization information to securely communicate with each other. Each of the devices is coupled with a less-constrained device, the authorization manager, that helps with difficult authentication and authorization tasks. The constrained devices do not need to register with authorization managers from other security domains. The profile specifically targets constrained clients and servers. It is designed to consider the security objectives of the owners on the server and the client side.
    
draft-ggalimbe-ccamp-flex-if-lmp-07.txt
 Extension to the Link Management Protocol (LMP/DWDM -rfc4209) for Dense Wavelength Division Multiplexing (DWDM) Optical Line Systems to manage the application code of optical interface parameters in DWDM application
 
 draft-ggalimbe-ccamp-flex-if-lmp-07.txt
 Date: 11/03/2019
 Authors: Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze
 Working Group: Individual Submissions (none)
 Formats: txt
This experimental memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) adding a set of parameters related to multicarrier DWDM interfaces to be used in Spectrum Switched Optical Networks (sson).
    
draft-ggalimbe-ccamp-flexigrid-carrier-label-06.txt
 Signaling extensions for Media Channel sub-carriers configuration in Spectrum Switched Optical Networks (SSON) in Lambda Switch Capable (LSC) Optical Line Systems.
 
 draft-ggalimbe-ccamp-flexigrid-carrier-label-06.txt
 Date: 11/03/2019
 Authors: Gabriele Galimberti, Domenico Fauci, Andrea Zanardi, Lorenzo Galvagni
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines the signaling extensions for managing Spectrum Switched Optical Network (SSON) parameters shared between the Client and the Network and inside the Network in accordance to the model described in RFC 7698. The extensions are in accordance and extending the parameters defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872].
    
draft-ghedini-dprive-early-data-00.txt
 Using Early Data in DNS over TLS
 
 draft-ghedini-dprive-early-data-00.txt
 Date: 25/03/2019
 Authors: Alessandro Ghedini
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document illustrates the risks of using TLS 1.3 early data with DNS over TLS, and specifies behaviors that can be adopted by clients and servers to reduce those risks.
    
draft-ginsberg-lsr-isis-invalid-tlv-03.txt
 Invalid TLV Handling in IS-IS
 
 draft-ginsberg-lsr-isis-invalid-tlv-03.txt
 Date: 03/04/2019
 Authors: Les Ginsberg, Paul Wells, Tony Li, Tony Przygienda, Shraddha Hegde
 Working Group: Individual Submissions (none)
 Formats: txt xml
Key to the extensibility of the Intermediate System to Intermediate System (IS-IS) protocol has been the handling of unsupported and/or invalid Type/Length/Value (TLV) tuples. Although there are explicit statements in existing specifications, deployment experience has shown that there are inconsistencies in the behavior when a TLV which is disallowed in a particular Protocol Data Unit (PDU) is received. This document discusses such cases and makes the correct behavior explicit in order to insure that interoperability is maximized. This document when approved updates RFC3563, RFC5305, RFC6232, and RFC6233.
    
draft-gmsm-bess-evpn-bfd-02.txt
 Fault Management for EVPN networks
 
 draft-gmsm-bess-evpn-bfd-02.txt
 Date: 21/02/2019
 Authors: Vengada Govindan, Mallik Mudigonda, Ali Sajassi, Gregory Mirsky, Donald Eastlake
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies proactive, in-band network OAM mechanisms to detect loss of continuity and miss-connection faults that affect unicast and multi-destination paths (used by Broadcast, Unknown Unicast and Multicast traffic) in an Ethernet VPN (EVPN) network. The mechanisms specified in the draft are based on the widely adopted Bidirectional Forwarding Detection (BFD) protocol.
    
draft-gomez-rto-considerations-lpwan-00.txt
 RTO considerations in LPWAN
 
 draft-gomez-rto-considerations-lpwan-00.txt
 Date: 10/03/2019
 Authors: Carles Gomez, Jon Crowcroft
 Working Group: Individual Submissions (none)
 Formats: xml txt
Low-Power Wide Area Network (LPWAN) technologies are characterized by very low physical layer bit and message transmission rates. Moreover, a response to a message sent by an LPWAN device may often only be received after a significant delay. As a result, Round-Trip Time (RTT) values in LPWAN are often (sometimes, significantly) greater than typical default values of Retransmission TimeOut (RTO) algorithms. Furthermore, buffering at network elements such as radio gateways may interact negatively with LPWAN technology transmission mechanisms, potentially exacerbating RTTs by up to several orders of magnitude. This document provides guidance for RTO settings in LPWAN, and describes an experimental dual RTO algorithm for LPWAN.
    
draft-gont-6man-slaac-renum-01.txt
 Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events
 
 draft-gont-6man-slaac-renum-01.txt
 Date: 18/02/2019
 Authors: Fernando Gont, Jan Zorz
 Working Group: Individual Submissions (none)
 Formats: txt
In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document analyzes these problem scenarios, and proposes workarounds to improve network robustness. This document updates RFC4861 and RFC4862 to allow for a more robust reaction to network configuration changes.
    
draft-gont-ntp-port-randomization-00.txt
 Port Randomization in the Network Time Protocol Version 4
 
 draft-gont-ntp-port-randomization-00.txt
 Date: 16/04/2019
 Authors: Fernando Gont, Guillermo Gont
 Working Group: Individual Submissions (none)
 Formats: txt
The Network Time Protocol can operate in several modes. Some of these modes are based on the receipt of unsolicited packets, and therefore require the use of a service/well-known port as the local port number. However, in the case of NTP modes where the use of a service/well-known port is not required, employing such well-known/ service port unnecessarily increases the ability of attackers to perform blind/off-path attacks, since knowledge of such port number is typically required for such attacks. This document formally updates RFC5905, recommending the use of port randomization for those modes where use of the NTP service port is not required.
    
draft-gont-numeric-ids-generation-03.txt
 On the Generation of Transient Numeric Identifiers
 
 draft-gont-numeric-ids-generation-03.txt
 Date: 11/03/2019
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. Subsequently, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, describes a number of algorithms that have been employed in real implementations to generate transient numeric identifiers and analyzes their security and privacy properties.
    
draft-gont-numeric-ids-history-04.txt
 Unfortunate History of Transient Numeric Identifiers
 
 draft-gont-numeric-ids-history-04.txt
 Date: 11/03/2019
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. It describes a number of algorithms that have been employed in real implementations to meet such requirements and analyzes their security and privacy properties. Additionally, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it provides recommendations for future protocol specifications regarding the specification of the aforementioned numeric identifiers.
    
draft-gont-numeric-ids-sec-considerations-03.txt
 Security Considerations for Transient Numeric Identifiers Employed in Network Protocols
 
 draft-gont-numeric-ids-sec-considerations-03.txt
 Date: 16/04/2019
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
For more than 30 years, a large number of implementations of the TCP/ IP protocol suite have been subject to a variety of attacks, with effects ranging from Denial of Service (DoS) or data injection, to information leakage that could be exploited for pervasive monitoring. The root of these issues has been, in many cases, the poor selection of transient identifiers in such protocols, usually as a result of an insufficient or misleading specifications. This document formally updates RFC3552, such that RFCs are required to perform a security and privacy analysis of the transient numeric identifiers they specify.
    
draft-gont-predictable-numeric-ids-03.txt
 Security and Privacy Implications of Numeric Identifiers Employed in Network Protocols
 
 draft-gont-predictable-numeric-ids-03.txt
 Date: 11/03/2019
 Authors: Fernando Gont, Ivan Arce
 Working Group: Individual Submissions (none)
 Formats: txt
This document performs an analysis of the security and privacy implications of different types of "numeric identifiers" used in IETF protocols, and tries to categorize them based on their interoperability requirements and the associated failure severity when such requirements are not met. It describes a number of algorithms that have been employed in real implementations to meet such requirements and analyzes their security and privacy properties. Additionally, it provides advice on possible algorithms that could be employed to satisfy the interoperability requirements of each identifier type, while minimizing the security and privacy implications, thus providing guidance to protocol designers and protocol implementers. Finally, it provides recommendations for future protocol specifications regarding the specification of the aforementioned numeric identifiers.
    
draft-gont-taps-address-usage-problem-statement-01.txt
 Problem Statement Regarding IPv6 Address Usage
 
 draft-gont-taps-address-usage-problem-statement-01.txt
 Date: 11/03/2019
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the security and privacy implications of IPv6 addresses based on a number of properties (such as address scope, stability, and usage type), and identifies gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses.
    
draft-gont-tcpm-tcp-seq-validation-04.txt
 On the Validation of TCP Sequence Numbers
 
 draft-gont-tcpm-tcp-seq-validation-04.txt
 Date: 11/03/2019
 Authors: Fernando Gont, David Borman
 Working Group: Individual Submissions (none)
 Formats: txt
When TCP receives packets that lie outside of the receive window, the corresponding packets are dropped and either an ACK, RST or no response is generated due to the out-of-window packet, with no further processing of the packet. Most of the time, this works just fine and TCP remains stable, especially when a TCP connection has unidirectional data flow. However, there are three scenarios in which packets that are outside of the receive window should still have their ACK field processed, or else a packet war will take place. The aforementioned issues have affected a number of popular TCP implementations, typically leading to connection failures, system crashes, or other undesirable behaviors. This document describes the three scenarios in which the aforementioned issues might arise, and formally updates RFC 793 such that these potential problems are mitigated.
    
draft-google-self-published-geofeeds-03.txt
 A Format for Self-published IP Geolocation Feeds
 
 draft-google-self-published-geofeeds-03.txt
 Date: 11/03/2019
 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 prefixes 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. This format intentionally only allows specifying coarse level location. 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, and is using it to allow ISPs to inform them where the prefixes live. [RFC Ed - Please remove publication: The IETF Meeting network currently publishes a feed in this format at: https://noc.ietf.org/geo/google.csv -- this has significantly cut down on the number of "Gah! Why does the network believe I'm in Montreal, that was last meeting! How am I supposed to find a pub?!" complaints. A number of other meeting networks, including RIPE and ICANN publish this information as well, see below. ] [ 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/google/self-published-geo . The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests ]
    
draft-goto-httpbis-preload-frame-01.txt
 The PRELOAD Frame Extension
 
 draft-goto-httpbis-preload-frame-01.txt
 Date: 09/01/2019
 Authors: Hiroyuki Goto
 Working Group: Individual Submissions (none)
 Formats: txt xml
A server can send application data before a client sends data if they are using HTTP/2 with TLS1.3 or HTTP/3. Indicating loading of necessary resources without waiting for the first request from the client may improve page loading performance. This document defines the PRELOAD frame, which is a new extension frame that allows the server to notify of preload information.
    
draft-gould-carney-regext-registry-04.txt
 Registry Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-carney-regext-registry-04.txt
 Date: 22/10/2018
 Authors: James Gould, Lin Jia, Roger Carney, Jody Kolker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning registry zones (e.g. top-level domains) in a Domain Name Registry. The attributes of a registry zone include the features and policies of the registry zone.
    
draft-gould-casanova-regext-unhandled-namespaces-01.txt
 Extensible Provisioning Protocol (EPP) Unhandled Namespaces
 
 draft-gould-casanova-regext-unhandled-namespaces-01.txt
 Date: 26/03/2019
 Authors: James Gould, Martin Casanova
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Extensible Provisioning Protocol (EPP), as defined in RFC 5730, includes a method for the client and server to determine the objects to be managed during a session and the object extensions to be used during a session. The services are identified using namespace URIs. How should the server handle service data that needs to be returned in the response when the client does not support the required service namespace URI, which is referred to as an unhandled namespace? An unhandled namespace is a significant issue for the processing of RFC 5730 poll messages, since poll messages are inserted by the server prior to knowing the supported client services, and the client needs to be capable of processing all poll messages. This document defines an operational practice that enables the server to return information associated with unhandled namespace URIs that is compliant with the negotiated services defined in RFC 5730.
    
draft-gould-regext-login-security-03.txt
 Login Security Extension for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-login-security-03.txt
 Date: 15/01/2019
 Authors: James Gould, Matthew Pozun
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response.
    
draft-gould-regext-login-security-policy-02.txt
 Login Security Policy Extensions Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-login-security-policy-02.txt
 Date: 15/01/2019
 Authors: James Gould
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an Extensible Provisioning Protocol (EPP) extension of the Registry Mapping to define the server policy of the Login Security EPP extension. The server policy of the Login Security EPP extension includes the MAYs, SHOULDs, and options implemented by the server.
    
draft-gs-bess-evpn-l2-attribute-cw-00.txt
 EVPN VPWS layer 2 Attributes Extended community for Control-Word behavior
 
 draft-gs-bess-evpn-l2-attribute-cw-00.txt
 Date: 24/12/2018
 Authors: Gangadhara Chavva, Satishkumar Rodd
 Working Group: Individual Submissions (none)
 Formats: txt
This document aims to define a negotiation mechanism for L2 capabilities in an EVPN scenario spefic to EVPN-VPWS control word behavior.
    
draft-gu-grow-bmp-route-leak-detection-02.txt
 BMP for BGP Route Leak Detection
 
 draft-gu-grow-bmp-route-leak-detection-02.txt
 Date: 02/04/2019
 Authors: Yunan Gu, China Telecom, Di Ma, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
According to RFC7908 [RFC7908], Route leaks refer to case that the delivery range of route advertisements is beyond the expected range. For many current security protection solutions, the ISPs (Internet Service Providers) are focusing on finding ways to detect the happening of route leaks. However, the real-time route leak detection if any occurs is important as well. This document extends the BGP Monitoring Protocol (BMP) [RFC7854] to provide a routing security scheme suitable for ISPs to detect BGP route leaks within their own networks.
    
draft-gu-grow-bmp-vpn-te-00.txt
 VPN Traffic Engineering Using BMP
 
 draft-gu-grow-bmp-vpn-te-00.txt
 Date: 11/03/2019
 Authors: Yunan Gu, iqjie@mail.ustc.edu.cn, Penghui Mi, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: xml txt
The BGP Monitoring Protocol (BMP) is designed to monitor BGP running status, such as BGP peer relationship establishment and termination and route updates. This document provides a traffic engineering (TE) method in the VPN (Virtual Private Network) scenario using BMP.
    
draft-guerra-feminism-00.txt
 Feminism and protocols
 
 draft-guerra-feminism-00.txt
 Date: 11/03/2019
 Authors: Juliana Guerra, Mallory Knodel
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document aims to describe how internet standrds and protocols and its implementations may impact diverse groups and communities. The research on how some protocol can be enabler for specific human rights while possibly restricting others has been documented in [RFC8280]. Similar to how RFC 8280 has taken a human rights lens through which to view engineering and design choices by internet standardisation, this document addreses the opportunities and vulnerabilities embedded within internet protocols for specific, traditionally maginalised groups.
    
draft-guichard-spring-nsh-sr-01.txt
 NSH and Segment Routing Integration for Service Function Chaining (SFC)
 
 draft-guichard-spring-nsh-sr-01.txt
 Date: 11/03/2019
 Authors: Jim Guichard, Haoyu Song, Jeff Tantsura, Joel Halpern, Wim Henderickx, Mohamed Boucadair, Syed Hassan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes two application scenarios where Network Service Header (NSH) and Segment Routing (SR) techniques can be deployed together to support Service Function Chaining (SFC) in an efficient manner while maintaining separation of the service and transport planes as originally intended by the SFC architecture. In the first scenario, an NSH-based SFC is created using SR as the transport between SFFs. SR in this case is just one of many encapsulations that could be used to maintain the transport- independent nature of NSH-based service chains. In the second scenario, SR is used to represent each service hop of the NSH-based SFC as a segment within the segment-list. SR and NSH in this case are integrated. In both scenarios SR is responsible for steering packets between SFFs along a given SFP while NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata. These application scenarios demonstrate that NSH and SR can work jointly and complement each other leaving the network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure, and still maintain an end-to-end service plane using NSH.
    
draft-guichard-spring-srv6-simplified-firewall-00.txt
 Simplifying Firewall Rules with Network Programming and SRH Metadata
 
 draft-guichard-spring-srv6-simplified-firewall-00.txt
 Date: 25/03/2019
 Authors: Jim Guichard, Clarence Filsfils, daniel.bernier@bell.ca, Zhenbin Li, Francois Clad, Pablo Camarillo, Ahmed Abdelsalam
 Working Group: Individual Submissions (none)
 Formats: xml txt
A clear application of the SRv6 Network Programming model consists in steering, in a stateless manner, packets through a Service Function Chain (SFC). Each Service Function (SF) is identified by a segment. Each SF can enrich its operation thanks to metadata present in the SRH. This document describes a practical use-case where the SF is a firewall and the metadata helps to drastically decrease the number of rules that need to be maintained by the operation team.
    
draft-gundogan-icnrg-iotqos-00.txt
 Quality of Service for ICN in the IoT
 
 draft-gundogan-icnrg-iotqos-00.txt
 Date: 28/03/2019
 Authors: Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch, Michael Frey, Felix Shzu-Juraschek, Jakob Pfender
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes manageable resources in ICN IoT deployments and a lightweight traffic classification method for mapping priorities to resources. Management methods are further derived for controlling latency and reliability of traffic flows in constrained environments.
    
draft-gutmann-scep-13.txt
 Simple Certificate Enrolment Protocol
 
 draft-gutmann-scep-13.txt
 Date: 28/01/2019
 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-11.txt
 TLS 1.2 Update for Long-term Support
 
 draft-gutmann-tls-lts-11.txt
 Date: 19/12/2018
 Authors: Peter Gutmann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an update of TLS 1.2 for long-term support on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis.
    
draft-gwerder-messagevortexmain-02.txt
 MessageVortex Protocol
 
 draft-gwerder-messagevortexmain-02.txt
 Date: 10/03/2019
 Authors: Martin Gwerder
 Working Group: Individual Submissions (none)
 Formats: pdf txt
The MessageVortex (referred to as Vortex) protocol achieves different degrees of anonymity, including sender, receiver, and third-party anonymity, by specifying messages embedded within existing transfer protocols, such as SMTP or XMPP, sent via peer nodes to one or more recipients. The protocol outperforms others by decoupling the transport from the final transmitter and receiver. No trust is placed into any infrastructure except for that of the sending and receiving parties of the message. The creator of the routing block has full control over the message flow. Routing nodes gain no non-obvious knowledge about the messages even when collaborating. While third-party anonymity is always achieved, the protocol also allows for either sender or receiver anonymity.
    
draft-gwock-rmcat-ccfs-01.txt
 Congestion Control based on Forward path Status
 
 draft-gwock-rmcat-ccfs-01.txt
 Date: 27/02/2019
 Authors: jungnam.gwock
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes CCFS(Congestion Control based on Forward path Status), a rate adaptation scheme for interactive real-time media applications, such as video conferencing. CCFS classifies the forward paths's status as throttled, competing, probing and default which is managed based on estimated parameters - bottleneck bandwidth, queue delay and loss ratio. Considering only forward path status minimizes influence of backward path's network events such as congestion. It is also free from compatibility issues because it defines generalized feedback message.
    
draft-haberman-iasa20dt-recs-03.txt
 IASA 2.0 Design Team Recommendations
 
 draft-haberman-iasa20dt-recs-03.txt
 Date: 27/11/2018
 Authors: Brian Haberman, Jari Arkko, Leslie Daigle, Jason Livingood, Joseph Hall, Eric Rescorla
 Working Group: Individual Submissions (none)
 Formats: txt
The arrangements relating to administrative support for the IETF were created more than ten years ago. Since then, there has been considerable change in the tasks and in our own expectations. The IETF community has discussed these changes and the problems they cause. The community has some sense of the properties they expect from future arrangements, including those related to structure, organization, personnel, and transparency. This document is a product of a design team, focused on providing additional information to the community about solution options, as well as supporting analysis of the implications of those options. This document reflects the final snapshot of the design team discussion and is published for historical posterity.
    
draft-haindl-lisp-gb-atn-02.txt
 Ground-Based LISP for the Aeronautical Telecommunications Network
 
 draft-haindl-lisp-gb-atn-02.txt
 Date: 04/12/2018
 Authors: Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras, Victor Moreno, Fabio Maino, Balaji Venkatachalapathy
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization. The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures.
    
draft-hall-censorship-tech-07.txt
 A Survey of Worldwide Censorship Techniques
 
 draft-hall-censorship-tech-07.txt
 Date: 11/03/2019
 Authors: Joseph Hall, Michael Aaron, Stan Adams, Ben Jones, Nick Feamster
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the technical mechanisms used by censorship regimes around the world to block or impair Internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties being exploited and mechanisms used to censor end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended to be a reference.
    
draft-hallambaker-jsonbcd-14.txt
 Binary Encodings for JavaScript Object Notation: JSON-B,JSON-C,JSON-D
 
 draft-hallambaker-jsonbcd-14.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
Three binary encodings for JavaScript Object Notation (JSON) are presented. JSON-B (Binary) is a strict superset of the JSON encoding that permits efficient binary encoding of intrinsic JavaScript data types. JSON-C (Compact) is a strict superset of JSON-B that supports compact representation of repeated data strings with short numeric codes. JSON-D (Data) supports additional binary data types for integer and floating-point representations for use in scientific applications where conversion between binary and decimal representations would cause a loss of precision. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html [1] .
    
draft-hallambaker-mesh-architecture-07.txt
 Mathematical Mesh Part I: Architecture Guide
 
 draft-hallambaker-mesh-architecture-07.txt
 Date: 04/04/2019
 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 makes computers easier to use by making them more secure. The Mesh provides a set of protocol and cryptographic building blocks that enable encrypted data stored in the cloud to be accessed, managed and exchanged between users with the same or better ease of use than traditional approaches which leave the data vulnerable to attack. This document provides an overview of the Mesh data structures, protocols and examples of its use. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- architecture.html [1] .
    
draft-hallambaker-mesh-constrained-00.txt
 Mathematical Mesh Part IX: Considerations for use on Constrained Devices
 
 draft-hallambaker-mesh-constrained-00.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-constrained.html [1] .
    
draft-hallambaker-mesh-cryptography-00.txt
 Mathematical Mesh Part VIII: Cryptographic Algorithms
 
 draft-hallambaker-mesh-cryptography-00.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the advanced encryption services supported by the Mesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- cryptography.html [1] .
    
draft-hallambaker-mesh-dare-01.txt
 Mathematical Mesh Part III : Data At Rest Encryption (DARE)
 
 draft-hallambaker-mesh-dare-01.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Data At Rest Encryption (DARE) Message and Container syntax. The DARE Message syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. The DARE Container syntax describes an append-only sequence of data frames, each containing a DARE Message. DARE Containers may support cryptographic integrity verification of the entire data container content by means of a Merkle tree. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-dare.html [1] .
    
draft-hallambaker-mesh-developer-08.txt
 Mathematical Mesh: Reference Implementation
 
 draft-hallambaker-mesh-developer-08.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes the Mesh reference code and how to install, run and make use of it in applications. It does not form a part of the Mesh specifications and is not normative. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-developer.html [1] .
    
draft-hallambaker-mesh-platform-04.txt
 Mathematical Mesh: Platform Configuration
 
 draft-hallambaker-mesh-platform-04.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes how Mesh profiles are stored for application access on Windows, Linux and OSX platforms. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-platform.html [1] .
    
draft-hallambaker-mesh-protocol-00.txt
 Mathematical Mesh Part V: Protocol Reference
 
 draft-hallambaker-mesh-protocol-00.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh 'The Mesh' is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-protocol.html [1] .
    
draft-hallambaker-mesh-quantum-00.txt
 Mathematical Mesh Part X: Considerations for Quantum Cryptanalysis
 
 draft-hallambaker-mesh-quantum-00.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh 'The Mesh' is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-quantum.html [1] .
    
draft-hallambaker-mesh-schema-00.txt
 Mathematical Mesh Part IV: Schema Reference
 
 draft-hallambaker-mesh-schema-00.txt
 Date: 04/04/2019
 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. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-schema.html [1] .
    
draft-hallambaker-mesh-security-00.txt
 Mathematical Mesh Part VII: Security Considerations
 
 draft-hallambaker-mesh-security-00.txt
 Date: 04/04/2019
 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. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-security.html [1] .
    
draft-hallambaker-mesh-trust-01.txt
 Mathematical Mesh Part VI: The Trust Mesh
 
 draft-hallambaker-mesh-trust-01.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This paper extends Shannon's concept of a 'work factor' as applied to evaluation of cryptographic algorithms to provide an objective measure of the practical security offered by a protocol or infrastructure design. Considering the hypothetical work factor based on an informed estimate of the probable capabilities of an attacker with unknown resources provides a better indication of the relative strength of protocol designs than the computational work factor of the best-known attack. The social work factor is a measure of the trustworthiness of a credential issued in a PKI based on the cost of having obtained the credential through fraud at a certain point in time. Use of the social work factor allows evaluation of Certificate Authority based trust models and peer to peer (Web of Trust) models to be evaluated in the same framework. The analysis demonstrates that both approaches have limitations and that in certain applications, a blended model is superior to either by itself. The final section of the paper describes a proposal to realize this blended model using the Mathematical Mesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-trust.html [1] .
    
draft-hallambaker-mesh-udf-02.txt
 Mathematical Mesh Part II: Uniform Data Fingerprint.
 
 draft-hallambaker-mesh-udf-02.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the naming and addressing schemes used in the Mathematical Mesh. The means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs are described. A UDF consists of a binary sequence, the initial eight bits of which specify a type identifier code. Type identifier codes have been selected so as to provide a useful mnemonic indicating their purpose when presented in Base32 encoding. Two categories of UDF are described. Data UDFs provide a compact presentation of a fixed length binary data value in a format that is convenient for data entry. A Data UDF may represent a cryptographic key, a nonce value or a share of a secret. Fingerprint UDFs provide a compact presentation of a Message Digest or Message Authentication Code value. A Strong Internet Name (SIN) consists of a DNS name which contains at least one label that is a UDF fingerprint of a policy document controlling interpretation of the name. SINs allow a direct trust model to be applied to achieve end-to-end security in existing Internet applications without the need for trusted third parties. UDFs may be presented as URIs to form either names or locators for use with the UDF location service. An Encrypted Authenticated Resource Locator (EARL) is a UDF locator URI presenting a service from which an encrypted resource may be obtained and a symmetric key that may be used to decrypt the content. EARLs may be presented on paper correspondence as a QR code to securely provide a machine- readable version of the same content. This may be applied to automate processes such as invoicing or to provide accessibility services for the partially sighted. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-udf.html [1] .
    
draft-hallambaker-web-service-discovery-02.txt
 DNS Web Service Discovery
 
 draft-hallambaker-web-service-discovery-02.txt
 Date: 04/04/2019
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a standardized approach to discovering Web Service Endpoints from a DNS name. Services are advertised using the DNS SRV and TXT records and the HTTP Well Known Service conventions. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-web-service- discovery.html [1] .
    
draft-haluska-sipping-directory-assistance-11.txt
 Considerations for Information Services and Operator Services Using SIP
 
 draft-haluska-sipping-directory-assistance-11.txt
 Date: 15/08/2011
 Authors: John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell
 Working Group: Real-time Applications and Infrastructure Area (rai)
 Formats: txt
Information Services are services whereby information is provided in response to user requests, and may include involvement of a human or automated agent. A popular existing Information Service is Directory Assistance (DA). Moving ahead, Information Services providers envision exciting multimedia services that support simultaneous voice and data interactions with full operator backup at any time during the call. Information Services providers are planning to migrate to SIP based platforms, which will enable such advanced services, while continuing to support traditional DA services. Operator Services are traditional PSTN services which often involve providing human or automated assistance to a caller, and often require the specialized capabilities traditionally provided by an operator services switch. Market and/or regulatory factors in some jurisdictions dictate that some subset of Operator Services continue to be provided going forward. This document aims to identify how Operator and Information Services can be implemented using existing or currently proposed SIP mechanisms, to identity existing protocol gaps, and to provide a set of Best Current Practices to facilitate interoperability. For Operator Services, the intention is to describe how current operator services can continue to be provided to PSTN based subscribers via a SIP based operator services architecture. It also looks at how current operator services might be provided to SIP based subscribers via such an architecture, but does not consider the larger question of the need for or usefulness or suitability of each of these services for SIP based subscribers. This document addresses the needs of current Operator and Information Services providers; as such, the intended audience includes vendors of equipment and services to such providers.
    
draft-hamarsheh-behave-biav2-05.txt
 Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA)
 
 draft-hamarsheh-behave-biav2-05.txt
 Date: 19/01/2011
 Authors: Ala Hamarsheh
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a mechanism for hosts with any network connectivity (IPv4 only, IPv6 only, or dual IPv4/IPv6 connectivity) to run applications of any capability (IPv4 only, IPv6 only, or dual IPv4/IPv6) without any modification to those applications. It is a generalisation of a previous experimental protocol called "Bump-in-the-API" (BIA) [RFC3338]. New mechanism of BIA allows a changeover between the application layer and the IP communication layers from IPv4 to IPv6 and vice versa or IPv6 to IPv4 and vice versa, without requiring those applications to be converted in addressing capabilities, effectively shielding the application layer from IPv4 or IPv6 connectivity. This is considered by the authors to be one of the essential conditions for the transition to IPv6 in the Internet to be successful.
    
draft-han-tsvwg-ip-transport-qos-02.txt
 Resource Reservation Protocol for IP Transport QoS
 
 draft-han-tsvwg-ip-transport-qos-02.txt
 Date: 17/04/2019
 Authors: Lin Han, Yingzhen Qu, Lijun Dong, Renwei Li, Thomas Nadeau, Kevin Smith, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
IP is designed for use in Best Effort Networks, which are networks that provide no guarantee that data is delivered, or that delivery meets any specified quality of service parameters. However there are new applications requiring IP to provide deterministic services in terms of bandwidth and latency, such as network based AR/VR (Augmented Reality and Virtual Reality), industrial internet. This document proposes a solution in IPv6 that can be used by transport layer protocols to guarantee certain level of service quality. This new service is fined-grained and could apply to individual or aggregated TCP/UDP flow(s).
    
draft-hao-bess-evpn-centralized-df-04.txt
 Centralized EVPN DF Election
 
 draft-hao-bess-evpn-centralized-df-04.txt
 Date: 10/04/2019
 Authors: Donald Eastlake, Hao Weiguo, Lili Wang, Li Yizhou, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a centralized DF Designated Forwarder election mechanism to be used between an SDN (Software Defined Network) controller and each PE (Provider Edge) device in an EVPN network. Such a mechanism overcomes some issues with the current standalone DF election defined in RFC 7432. A new BGP capability and an additional DF Election Result Route Type are specified to support this centralized DF election mechanism.
    
draft-hares-lsr-grid-ring-convergence-00.txt
 IPRAN Grid-Ring IGP convergence problems
 
 draft-hares-lsr-grid-ring-convergence-00.txt
 Date: 11/02/2019
 Authors: Susan Hares
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This draft describes problems with IGP convergence time in some IPRAN networks that use a physical topology of grid backbones that connect rings of routers. Part of these IPRAN network topologies exist in data centers with sufficient power and interconnections, but some network equipment sits in remote sites impacted by power loss. In some geographic areas these remote sites may be subject to rolling blackouts. These rolling power blackouts could cause multiple simultaneous node and link failures. In these remote networks with blackouts, it is often critical that the IPRAN phone network re- converge quickly. The IGP running in these networks may run in a single level of the IGP. This document seeks to briefly describe these problems to determine if the emerging IGP technologies (flexible algorithms, dynamic flooding, layers of hierarchy in IGPs) can be applied to help reduce convergence times. It also seeks to determine if the improvements of these algorithms or the IP-Fast re-route algorithms are thwarted by the failure of multiple link and nodes.
    
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-harrison-regext-rdap-mirroring-00.txt
 RDAP Mirroring Protocol (RMP)
 
 draft-harrison-regext-rdap-mirroring-00.txt
 Date: 01/02/2019
 Authors: Tom Harrison, George Michaelson, Andrew Newton
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. While most clients can retrieve the information they need on an ad hoc basis from the public services maintained by each registry, there are instances where local copies of those remote data sources need to be maintained, for various reasons (e.g. performance requirements). This document defines a protocol for transferring bulk RDAP response data and for keeping a local copy of that data up to date.
    
draft-hartke-core-apps-08.txt
 CoRE Applications
 
 draft-hartke-core-apps-08.txt
 Date: 22/10/2018
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The application programmable interfaces of RESTful, hypermedia-driven Web applications consist of a number of reusable components such as Internet media types and link relation types. This document proposes "CoRE Applications", a convention for application designers to build the interfaces of their applications in a structured way, so that implementers can easily build interoperable clients and servers, and other designers can reuse the components in their own applications.
    
draft-hartke-t2trg-ciri-02.txt
 Constrained Internationalized Resource Identifiers
 
 draft-hartke-t2trg-ciri-02.txt
 Date: 11/03/2019
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
Constrained Internationalized Resource Identifiers are an alternate serialization of Uniform Resource Identifiers (URIs) that encodes the URI components in Concise Binary Object Representation (CBOR) instead of a string of characters. This simplifies parsing, reference resolution, and comparison of URIs in environments with severe limitations on processing power, code size, and memory size.
    
draft-hartke-t2trg-coral-08.txt
 The Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-08.txt
 Date: 11/03/2019
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as two specialized serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), as well as simple resource metadata.
    
draft-hartke-t2trg-coral-reef-01.txt
 Resource Discovery in Constrained RESTful Environments (CoRE) Using the Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-reef-01.txt
 Date: 11/03/2019
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document explores how the Constrained RESTful Application Language (CoRAL) might be used for two use cases in Constrained RESTful Environments (CoRE): CoRE Resource Discovery, which allows a client to discover the resources of a server given a host name or IP address, and CoRE Resource Directory, which provides a directory of resources on many servers.
    
draft-hartke-t2trg-data-hub-03.txt
 Thing-to-Thing Data Hub
 
 draft-hartke-t2trg-data-hub-03.txt
 Date: 11/03/2019
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The "Thing-to-Thing Data Hub" is a RESTful, hypermedia-driven Web application that can be used in Thing-to-Thing communications to share data items such as thing descriptions, configurations, resource descriptions, or firmware updates at a central location.
    
draft-hayashi-dots-dms-offload-usecase-00.txt
 DDoS Mitigation Offload: A DOTS Applicability Use Case
 
 draft-hayashi-dots-dms-offload-usecase-00.txt
 Date: 08/03/2019
 Authors: Yuhei Hayashi, Kaname Nishizuka, Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the applicability of DOTS to a DDoS mitigation offload use case. This use case assumes that a DMS (DDoS Mitigation System) whose utilization rate is high sends its blocked traffic information to an orchestrator using DOTS protocols, then the orchestrator requests forwarding nodes such as routers to filter the traffic. Doing so enables service providers to mitigate DDoS attack traffic automatically while ensuring interoperability and distributed filter enforcement.
    
draft-hdevalence-cfrg-ristretto-00.txt
 The ristretto255 Group
 
 draft-hdevalence-cfrg-ristretto-00.txt
 Date: 19/01/2019
 Authors: Henry de Valence, Jack Grigg, George Tankersley, Filippo Valsorda, Isis Lovecruft
 Working Group: Individual Submissions (none)
 Formats: xml txt
This memo specifies a prime-order group, ristretto255, suitable for implementing complex cryptographic protocols such as zero-knowledge proofs. The ristretto255 group can be implemented using Curve25519, allowing existing Curve25519 implementations to be reused and extended to provide a prime-order group.
    
draft-he-coin-managed-networks-00.txt
 In-Network Computing for Managed Networks: Use Cases and Research Challenges
 
 draft-he-coin-managed-networks-00.txt
 Date: 09/03/2019
 Authors: Jianfei(Jeffrey) He, Aini Li, Marie-Jose Montpetit
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft wants to review the existing research and the open issues that relate to the addition of data plane programmability in managed networks. While some of the research hypotheses that are at the center of in-network-computing have been investigated since the time of active networking, recent developments in software defined networking, virtualization programmable switches and new network programming languages like P4 have generated a new enthusiasm in the research community and a flourish of new projects in systems and applications alike. This is what this draft is addressing.
    
draft-hegde-idr-bgp-ls-epe-inter-as-01.txt
 BGP-LS Extensions for Inter-AS TE using EPE based mechanisms
 
 draft-hegde-idr-bgp-ls-epe-inter-as-01.txt
 Date: 19/04/2019
 Authors: Shraddha Hegde, Srihari Ramachandra, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
In certain network deployments, a single operator has multiple Autonomous Systems(AS) to facilitate ease of management. A multiple AS network design could also be a result of network mergers and acquisitions. In such scenarios, a centralized Inter-domain TE approach could provide most optimal allocation of resources and the most controlled path placement. BGP-LS-EPE [I-D.ietf-idr-bgpls-segment-routing-epe] describes an extension to BGP Link State (BGP-LS) for the advertisement of BGP Peering Segments along with their BGP peering node and inter-AS link information, so that efficient BGP Egress Peer Engineering (EPE) policies and strategies can be computed based on Segment Routing. This document describes extensions to the BGP-LS EPE to enable it to be used for inter-AS Traffic-Engineering (TE) purposes.
    
draft-hegde-mpls-spring-epe-oam-01.txt
 Label Switched Path (LSP) Ping/Traceroute for Segment Routing (SR) Egress Peer engineering Segment Identifiers (SIDs) with MPLS Data Planes
 
 draft-hegde-mpls-spring-epe-oam-01.txt
 Date: 26/11/2018
 Authors: Shraddha Hegde, Kapil Arora
 Working Group: Individual Submissions (none)
 Formats: txt xml
Egress Peer Engineering is an application of Segment Routing to solve the problem of egress peer selection. The SR-based BGP-EPE solution allows a centralized (Software Defined Network, SDN)controller to program any egress peer. The EPE solution requires a node to program PeerNodeSID, PeerAdjSID, PeerSetSID as described in [I-D.ietf-spring-segment-routing-central-epe].This document provides Target FEC stack TLV definitions as defined in [RFC8029] for the EPE SIDs.
    
draft-heide-nwcrg-rlnc-01.txt
 Random Linear Network Coding (RLNC)-Based Symbol Representation
 
 draft-heide-nwcrg-rlnc-01.txt
 Date: 15/02/2019
 Authors: Janus Heide, Shirley Shi, Kerim Fouli, Muriel Medard, Vince Chook
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a symbol representation for Random Linear Network Coding (RLNC) schemes used for reliable data transfer. Specifically, the following features are discussed and incorporated: both block RLNC and a sliding window RLNC, varying data frame sizes, and one or multiple symbols associated with a single symbol representation header.
    
draft-heide-nwcrg-rlnc-background-00.txt
 Random Linear Network Coding (RLNC): Background and Practical Considerations
 
 draft-heide-nwcrg-rlnc-background-00.txt
 Date: 11/02/2019
 Authors: Janus Heide, Shirley Shi, Kerim Fouli, Muriel Medard, Vince Chook
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the use of Random Linear Network Coding (RLNC) schemes for reliable data transport. Both block and sliding window RLNC code implementations are described. By providing erasure correction using randomly generated repair symbols, such RLNC-based schemes offer advantages in accommodating varying frame sizes and dynamically changing connections, reducing the need for feedback, and lowering the amount of state information needed at the sender and receiver. The practical considerations' section identifies RLNC- encoded symbol representation as a valuable target for standardization.
    
draft-heitz-idr-diagnostic-attr-01.txt
 BGP Diagnostic Path Attribute
 
 draft-heitz-idr-diagnostic-attr-01.txt
 Date: 25/03/2019
 Authors: Jakob Heitz, Prasad Narasimha, Sameer Gulrajani
 Working Group: Individual Submissions (none)
 Formats: xml txt
A BGP path attribute for the purpose of network diagnostics is described. It is non-transitive, such that BGP speakers will not forward it by default. It is structured as a list of elements. An element begins with the BGP identifier and AS number of the speaker that appends the element and includes a list of TLVs. Any speaker can add or remove an element to/from the list. TLVs for a timestamp and for a checksum are described.
    
draft-heitz-idr-extra-extended-community-02.txt
 BGP Extra Extended Community
 
 draft-heitz-idr-extra-extended-community-02.txt
 Date: 14/01/2019
 Authors: Jakob Heitz, Ali Sajassi, Ignas Bagdonas
 Working Group: Individual Submissions (none)
 Formats: xml txt
Auto-derived identifiers are used by applications to enable zero configuration features. Such identifiers are often a combination of primitive identifiers and are thus longer. In addition, existing identifiers have grown longer. IP addresses have grown from 4 octets to 16. AS numbers have grown from 2 octets to 4. In order to accommodate such longer identifiers in BGP extended communities, this document defines a new BGP path attribute, the Extra Extended Communities attribute. It is similar to the Extended Community, but is 24 octets long. Communities are mostly used within ASes under a single administration or between neighboring ASes. Limiting the spread of communities beyond their intended reach and polluting the internet at large is complex and error prone. To simplify this, enhanced transitivity options are provided.
    
draft-heitz-idr-msdc-bgp-aggregation-00.txt
 Aggregating BGP routes in Massive Scale Data Centers
 
 draft-heitz-idr-msdc-bgp-aggregation-00.txt
 Date: 22/10/2018
 Authors: Jakob Heitz, Dhananjaya Rao
 Working Group: Individual Submissions (none)
 Formats: xml txt
A design for a fabric of switches to connect up to one million servers in a data center is described. At that scale, it is impractical for every switch to maintain knowledge about every other switch and every other link in the fabric. Aggregation of routes is an excellent way to scale such a fabric. However, aggregation presents some problems under link failures or switch failures. This design solves those problems.
    
draft-heitz-idr-msdc-fabric-autoconf-01.txt
 Automatic discovery and configuration of the network fabric in Massive Scale Data Centers
 
 draft-heitz-idr-msdc-fabric-autoconf-01.txt
 Date: 04/11/2018
 Authors: Jakob Heitz, Kausik Majumdar, Acee Lindem
 Working Group: Individual Submissions (none)
 Formats: xml txt
A switching fabric in a massive scale data center can comprise many 10,000's of switches and 100,000's of IP hosts. To connect and configure a network of such size needs automation to avoid errors. Zero Touch Provisioning (ZTP) protocols exist. These can configure IP devices that are reachable by the ZTP agents. A method to combine BGP, DHCPv6 and SRv6 with ZTP that can be used to discover and configure an entire network of devices is described. It is designed to scale well, because each networked device is not required to know about more than its directly connected neighborhood.
    
draft-henry-tsvwg-diffserv-to-qci-01.txt
 Diffserv to QCI Mapping
 
 draft-henry-tsvwg-diffserv-to-qci-01.txt
 Date: 15/04/2019
 Authors: Jerome Henry, Tim Szigeti
 Working Group: Individual Submissions (none)
 Formats: xml txt
As communication devices become more hybrid, smart devices include more media-rich communication applications, and the boundaries between telecommunication and other applications becomes less clear. Simultaneously, as the end-devices become more mobile, application traffic transits more often between enterprise networks, the Internet, and cellular telecommunication networks. In this context, it is crucial that quality of service be aligned between these different environments. However, this is not always the case by default, and cellular communication networks use a different QoS nomenclature from the Internet and enterprise networks. This document specifies a set of 3rd Generation Partnership Project (3GPP) Quality of Service (QoS) Class Identifiers (QCI) to Differentiated Services Code Point (DSCP) mappings, to reconcile the marking recommendations offered by the 3GPP with the recommendations offered by the IETF, so as to maintain a consistent QoS treatment between cellular networks and the Internet.
    
draft-herbert-fast-04.txt
 Firewall and Service Tickets
 
 draft-herbert-fast-04.txt
 Date: 10/04/2019
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Firewalls and Service Tickets protocol. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network services to be applied. Applications request tickets from a local agent in the network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to a packets. A single ticket may provide both firewall and service ticket information. Tickets are sent in IPv6 Hop-by-Hop options.
    
draft-herbert-intarea-ams-01.txt
 Address Mapping System
 
 draft-herbert-intarea-ams-01.txt
 Date: 21/02/2019
 Authors: Tom Herbert, Vikram Siwach
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Address Mapping System that is a generic, extensible, and scalable system for mapping network addresses to other network addresses. The Address Mapping System is intended to be used in conjunction with overlay techniques which facilitate transmission of packets across overlay networks. Information returned by the Address Mapping System can include the particular network overlay method to use, as well as instructions related to using the method. The Address Mapping System has a number of potential use cases including identifier-locator protocols, network virtualization, and promotion of privacy.
    
draft-herbert-ipv4-eh-00.txt
 IPv4 Extension Headers and Flow Label
 
 draft-herbert-ipv4-eh-00.txt
 Date: 08/04/2019
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines extension headers for IPv4 and a definition of an IPv4 flow label. The goal is to provide a uniform and feasible method of extensibility that is shared between IPv4 and IPv6.
    
draft-herbert-ipv4-udpencap-eh-01.txt
 IPv4 Extension Headers and UDP Encapsulated Extension Headers
 
 draft-herbert-ipv4-udpencap-eh-01.txt
 Date: 08/03/2019
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines extension headers for IPv4 and a method to encapsulate extension headers in UDP to facilitate transmission over the Internet, as well as a definition of an IPv4 flow label. The goal is to provide a uniform and feasible method of extensibility that is shared between IPv4 and IPv6.
    
draft-herbert-ipv6-update-opts-01.txt
 Updates to Requirements for IPv6 Options
 
 draft-herbert-ipv6-update-opts-01.txt
 Date: 01/03/2019
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document updates requirements for IPv6 Destination and Hop-by- Hop Options. The requirements that option type and option length cannot change en route, as well as the requirements that options cannot be added or removed, are made explicit. The meaning and requirements of a Destination Option marked as changeable are clarified. Finally, the requirement that all destinations listed in a Routing header must process options in a Destination Options header preceding the Routing header is relaxed.
    
draft-herbert-simple-sr-00.txt
 Simple Segment Routing Header
 
 draft-herbert-simple-sr-00.txt
 Date: 11/03/2019
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This specification defines a simple extension header format for Segment Routing based on the current definition of the Segment Routing extension header defined for IPv6. A Segment Identifier type field is added so that the segment list might contain values other than IPv6 addresses. Optional TLVs in the segment routing header are eliminated; Destination options that precede the routing header are sufficient. Two new destination options are defined: one for Routing header security and another to specify that certain destinations should process certain options.
    
draft-herbert-udp-space-hdr-00.txt
 UDP Surplus Space Header
 
 draft-herbert-udp-space-hdr-00.txt
 Date: 11/03/2019
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines a header for surplus space in UDP. The UDP surplus space is bytes between the end of the UDP payload and the end of the IP packet. The purpose of the header is to disambiguate uses of the surplus space. The UDP surplus space header includes a type, length, and checksum field that covers the space.
    
draft-hinden-6man-mtu-option-01.txt
 IPv6 Minimum Path MTU Hop-by-Hop Option
 
 draft-hinden-6man-mtu-option-01.txt
 Date: 11/03/2019
 Authors: Robert Hinden, Gorry Fairhurst
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a new Hop-by-Hop IPv6 option that is used to record the minimum Path MTU along the forward path between a source to a destination host. This collects a minimum recorded MTU along the path to the destination. The value can then be communicated back to the source host by an ICMPv6 Packet Too Big message. This Hop-by-Hop option is intended to be used in environments like Data Centers and on paths between Data Centers, to allow them to better take advantage of paths able to support a large Path MTU.
    
draft-hodges-webauthn-registries-02.txt
 Registries for Web Authentication (WebAuthn)
 
 draft-hodges-webauthn-registries-02.txt
 Date: 11/03/2019
 Authors: Jeff Hodges, Giridhar Mandyam, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification defines IANA registries for W3C Web Authentication attestation statement format identifiers and extension identifiers.
    
draft-hoehlhubmer-https-addon-07.txt
 Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol
 
 draft-hoehlhubmer-https-addon-07.txt
 Date: 25/11/2013
 Authors: Walter Hoehlhubmer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations.
    
draft-hoehrmann-cp-collation-01.txt
 The i;codepoint collation
 
 draft-hoehrmann-cp-collation-01.txt
 Date: 14/09/2010
 Authors: Bjoern Hoehrmann
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations.
    
draft-hoffman-dns-terminology-ter-00.txt
 Abbreviations for DNS Transports and Location
 
 draft-hoffman-dns-terminology-ter-00.txt
 Date: 23/03/2019
 Authors: Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
This document adds abbreviations to "DNS Terminology" (RFC 8499) that relate to DNS running over various transports, as well as abbreviations for DNS resolution at traditional and non-traditional locations. [[ This is an early attempt at these terms. They will probably be improved over time. []
    
draft-hohendorf-secure-sctp-27.txt
 Secure SCTP
 
 draft-hohendorf-secure-sctp-27.txt
 Date: 06/03/2019
 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-vcarddav-icann-rdap-extensions-01.txt
 vCard Format Extensions: Internet Corporation for Assigned Names and Numbers (ICANN) Extensions for the Registration Data Access Protocol (RDAP)
 
 draft-hollenbeck-vcarddav-icann-rdap-extensions-01.txt
 Date: 12/04/2019
 Authors: Scott Hollenbeck, Roger Carney
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
This document defines extensions to the vCard data format for representing and exchanging contact information used to implement the Internet Corporation for Assigned Names and Numbers (ICANN) operational profile for the Registration Data Access Protocol (RDAP). The property and parameter defined here are used to add values to RDAP responses that are consistent with ICANN policies.
    
draft-holmberg-ice-premature-00.txt
 Preventing Premature Interactive Connectivity Establishment (ICE) Failures
 
 draft-holmberg-ice-premature-00.txt
 Date: 27/02/2019
 Authors: Christer Holmberg, Justin Uberti
 Working Group: Individual Submissions (none)
 Formats: txt xml
...
    
draft-homma-dmm-5gs-id-loc-coexistence-02.txt
 Co-existence of 3GPP 5GS and Identifier-Locator Separation Architecture
 
 draft-homma-dmm-5gs-id-loc-coexistence-02.txt
 Date: 21/10/2018
 Authors: Shunsuke Homma, Kenta Kawakami, Arashmid Akhavain, Alberto Rodriguez-Natal, Ravi Shekhar
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an approach to introduce Identifier Locator Separation architecture into 3GPP 5GS with low-impact on its specifications, and shows the features and considerations of this approach.
    
draft-homma-nmrg-slice-gateway-00.txt
 Gateway Function for Network Slicing
 
 draft-homma-nmrg-slice-gateway-00.txt
 Date: 22/10/2018
 Authors: Shunsuke Homma, Xavier de Foy, A. Galis
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the roles and requirements for a slice gateway that is a function or function group for handling data plane traffic, such as connecting/disconnecting and compose/decompose network slice subnets and providing network slices from end to end. The interworkings between management and control elements at the management and control planes with the gateway function for controlling and orchestrating end-to-end network slices are also presented in this document.
    
draft-homma-slice-provision-models-00.txt
 Network Slice Provision Models
 
 draft-homma-slice-provision-models-00.txt
 Date: 01/02/2019
 Authors: Shunsuke Homma, Hidetaka Nishihara, Takuya Miyasaka, A. Galis, Vishnu OV, Diego Lopez, Luis Contreras, Jose Ordonez-Lucena, Pedro Martinez-Julia, Li Qiang, Reza Rokui, Laurent Ciavaglia, Xavier de Foy
 Working Group: Individual Submissions (none)
 Formats: txt
Network slicing is an approach to provide separate virtual network based on service requirements. It's a fundamental concept of the 5G, and the architecture and specification is under standardization in several organizations. However, the definitions and scopes of network slicing vary to some degree from one organization to another. This document provides classification of provisioning models of network slice for clarifying the differences on the definitions and scopes.
    
draft-hong-iot-edge-computing-02.txt
 Problem Statement of IoT integrated with Edge Computing
 
 draft-hong-iot-edge-computing-02.txt
 Date: 11/03/2019
 Authors: Jungha Hong, Yong-Geun Hong, Joo-Sang Youn
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes new challenges such as strict latency, constrained network bandwidth and devices, intermittent connectivity, privacy and security, for IoT services originated from the IoT environmental changes. In order to address those new challenges, the integration of Edge computing and IoT has been emerged as a promising solution. This document discribes the concept of IoT integrated with Edge computing as well as its use cases. It also discusses benefits and challenges of Edge computing. The direction of Edge computing for IoT should be discussed in the IETF/IRTF.
    
draft-hongcs-t2trg-dfm-00.txt
 Distributed fault management for IoT Networks
 
 draft-hongcs-t2trg-dfm-00.txt
 Date: 27/12/2018
 Authors: Choong Hong, Shashi Pandey, Chit Zaw, Seung Moon, Minh Nguyen
 Working Group: Individual Submissions (none)
 Formats: txt
Recent advances in Internet of Things (IoT) have increased the use of sensing technologies for IoT applications. However, monitoring sensor nodes is still a challenging issue in distributed remote environments, especially wireless environments. Different from conventional centralized mechanism, Fog Computing becomes an essential role in a scalable IoT system. Fog Node can control and monitor its subdomain's devices and perform aggregation tasks to support the central server at the cloud. Since node fault detection can strongly affect the performance and accuracy in most IoT analysis applications, fault detection mechanism should be integrated into IoT Networks. Accordingly, these fault nodes could be detected and replaced by others available nodes in the same domain for the analysis by a distributed fault detection and node replacement mechanism based on their sensory values in a considered domain.
    
draft-hopps-ipsecme-iptfs-00.txt
 IP Traffic Flow Security
 
 draft-hopps-ipsecme-iptfs-00.txt
 Date: 11/03/2019
 Authors: Christian Hopps
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a mechanism to enhance IPsec traffic flow security by adding traffic flow confidentiality to encrypted IP encapsulated traffic. Traffic flow confidentiality is provided by obscuring the size and frequency of IP traffic using a fixed-sized, constant-send-rate IPsec tunnel. The solution allows for congestion control as well.
    
draft-hopps-lsr-yang-isis-reverse-metric-00.txt
 YANG Data Model for the IS-IS Reverse Metric Extension
 
 draft-hopps-lsr-yang-isis-reverse-metric-00.txt
 Date: 31/03/2019
 Authors: Christian Hopps
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG module for managing the reverse metric extension to the the intermediate system to intermediate system routeing protocol.
    
draft-housley-hkdf-oids-01.txt
 Algorithm Identifiers for the HMAC-based Extract-and-Expand Key Derivation Function (HKDF)
 
 draft-housley-hkdf-oids-01.txt
 Date: 05/02/2019
 Authors: Russ Housley
 Working Group: Security Area (sec)
 Formats: txt
RFC 5869 specifies the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm. This document assigns algorithm identifiers to the HKDF algorithm when used with three common one-way hash functions.
    
draft-hsmit-lsr-isis-dnfm-00.txt
 IS-IS Sparse Link-State Flooding
 
 draft-hsmit-lsr-isis-dnfm-00.txt
 Date: 22/10/2018
 Authors: Henk Smit, Gunter Van de Velde
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a technology extension to reduce link-state flooding in highly resilient dense networks. It does this by using simple and backwards-compatible extensions to reduce the number of adjacencies over which link-state flooding takes place. "IS-IS Sparse Link-State Flooding" is an extension to the IS-IS routing protocol. It is relatively easy to understand and implement. It is backwards compatible. It requires no per-node configuration. It uses a distributed algorithm, therefor no centralized computations are required. No complex computations are required on each node in the network. The algorithm has no requirements for the network topology. It can be deployed in a redundant way to improve robustness and convergence-times.
    
draft-httpemaildevphone-01.txt
 Need for associating email address to device address and phone numbers
 
 draft-httpemaildevphone-01.txt
 Date: 27/01/2019
 Authors: pradeep xplorer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the need for associating email address to device address and phone numbers
    
draft-hu-bier-bfd-03.txt
 BIER BFD
 
 draft-hu-bier-bfd-03.txt
 Date: 28/02/2019
 Authors: Quan Xiong, Gregory Mirsky, fangwei hu, Chang Liu
 Working Group: Individual Submissions (none)
 Formats: txt
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the application of P2MP BFD in BIER network.
    
draft-hu-isis-srv6-yang-01.txt
 YANG Data Model for IS-IS SRv6
 
 draft-hu-isis-srv6-yang-01.txt
 Date: 26/03/2019
 Authors: Zhibo Hu, Dan Ye, Yingzhen Qu, Jiajia Dong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage IS-IS SRv6 [I-D.bashandy-isis-srv6-extensions].
    
draft-hu-lsr-ospf-srv6-yang-00.txt
 YANG Data Model for OSPF SRv6
 
 draft-hu-lsr-ospf-srv6-yang-00.txt
 Date: 22/10/2018
 Authors: Zhibo Hu, Kamran Raza, Yingzhen Qu, Jiajia Dong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage OSPF SRv6 [I-D.li-ospf-ospfv3-srv6-extensions].
    
draft-hu-mpls-sr-inter-domain-use-cases-01.txt
 Inter-domain Use Cases of Segment Routing with MPLS Data Plane for Transport Network
 
 draft-hu-mpls-sr-inter-domain-use-cases-01.txt
 Date: 10/03/2019
 Authors: Quan Xiong, Gregory Mirsky, fangwei hu, Weiqiang Cheng
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses the inter-domain scenarios for Transport Profile of SR-MPLS (SR-MPLS-TP), including SR-MPLS-TP inter-working with MPLS-TP network.
    
draft-hu-nvo3-vxlan-gpe-extension-for-vbng-01.txt
 VXLAN GPE Extension for Packets Exchange Between Control and User Plane of vBNG
 
 draft-hu-nvo3-vxlan-gpe-extension-for-vbng-01.txt
 Date: 09/12/2018
 Authors: Shujun Hu, Fengwei Qin, Zhenqiang Li, Zitao Wang, Ting Ao
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document briefly describes the architecture of control plane and user plane separated vBNG and define the extension of VXLAN-GPE for PPPoE/IPoE dialup packets exchange between control plane and user plane.
    
draft-hu-pce-stitching-lsp-association-00.txt
 Stitching LSP Association
 
 draft-hu-pce-stitching-lsp-association-00.txt
 Date: 10/12/2018
 Authors: fangwei hu, Quan Xiong, Gregory Mirsky, Weiqiang Cheng
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the stitching LSP association type and stitching LSP association TLV for the inter-domain Segment Routing MPLS-TP network.
    
draft-hu-rtgwg-srv6-egress-protection-01.txt
 SRv6 Path Egress Protection
 
 draft-hu-rtgwg-srv6-egress-protection-01.txt
 Date: 31/03/2019
 Authors: Zhibo Hu, China Telecom, Huaimo Chen, Peng Wu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes protocol extensions and procedures for protecting the egress node of a Segment Routing for IPv6 (SRv6) path.
    
draft-hu-spring-segment-routing-proxy-forwarding-03.txt
 SR-TE Path Midpoint Protection
 
 draft-hu-spring-segment-routing-proxy-forwarding-03.txt
 Date: 13/04/2019
 Authors: Zhibo Hu, Huaimo Chen, Junda Yao, Chris Bowers, Yongqing Zhu
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing Traffic Engineering (SR-TE) supports the creation of explicit paths using segment lists containing adjacency-sids, node- sids, anycast-sids, and binding-sids. When the segment list defining an SR-TE path contains a node-sid, and the node fails, the network may no longer be able to properly forward traffic on that SR-TE path. [I-D.bashandy-rtgwg-segment-routing-ti-lfa] and [I-D.hegde-spring-node-protection-for-sr-te-paths] describe a mechanism that allows local repair actions on the direct neighbors of the failed node to temporarily route traffic to the node immediately following the failed node on the SR-TE path segment list. However, once the IGP shortest paths have converged, the local repair mechanism is no longer sufficient to continue forwarding traffic using the original segment list of the SR-TE path, since the non- neighbors of the failed node will no longer have a route to reach the failed node. This document describes a mechanism that allows traffic to continue to be forwarded on an SR-TE path for an extended period of time after the failure of a node used in the path's segment list.
    
draft-huang-rsca-sdm-eon-01.txt
 RSCA method with Dividing Frequency Slots Area in Space Division Multiplexing Elastic Optical Networks
 
 draft-huang-rsca-sdm-eon-01.txt
 Date: 13/11/2018
 Authors: Shanguo Huang, Shan Yin, Shuang Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This documentary provides a routing, spectrum and core assignment method with the dividing frequency slots area for space division multiplexing elastic optical networks. This effective RSCA method to solve this problem better. The proposed method utilizes the Frequency Slots Area (FSA) concept and first-last fit policy of frequency slots assignment to have less spectrum fragments, lower crosstalk, smaller traffic blocking probability and higher spectrum resource utilization.
    
draft-huitema-dnssd-tls-privacy-01.txt
 Private Discovery with TLS-ESNI
 
 draft-huitema-dnssd-tls-privacy-01.txt
 Date: 11/03/2019
 Authors: Christian Huitema, Daniel Kaiser
 Working Group: Individual Submissions (none)
 Formats: txt xml
DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. We propose to solve this problem by developing a private discovery profile for UDP based transports using TLS, such as DTLS and QUIC. The profile is based on using the Encrypted SNI extension. We also define a standalone private discovery service, that can be combined with arbitrary applications in the same way as DNS-SD.
    
draft-huitema-quic-dnsoquic-06.txt
 Specification of DNS over Dedicated QUIC Connections
 
 draft-huitema-quic-dnsoquic-06.txt
 Date: 07/03/2019
 Authors: Christian Huitema, Melinda Shore, Allison Mankin, Sara Dickinson, Jana Iyengar
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the use of QUIC to provide transport privacy for DNS. The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of- line blocking issues inherent with TCP and provides more efficient error corrections than UDP. DNS over QUIC (DNS/QUIC) has privacy properties similar to DNS over TLS specified in RFC7858, and performance similar to classic DNS over UDP.
    
draft-hujun-idr-bgp-ipsec-00.txt
 BGP Signaled IPsec Tunnel Configuration
 
 draft-hujun-idr-bgp-ipsec-00.txt
 Date: 05/03/2019
 Authors: Jun Hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a method of using BGP to signal IPsec tunnel configuration along with NLRI, it uses and extends tunnel encapsulation attribute as specified in [I-D.ietf-idr-tunnel-encaps] for IPsec tunnel.
    
draft-hzpa-dprive-xfr-over-tls-01.txt
 DNS Zone Transfer over TLS
 
 draft-hzpa-dprive-xfr-over-tls-01.txt
 Date: 11/03/2019
 Authors: Han Zhang, Pallavi Aras, Willem Toorop, Sara Dickinson, Allison Mankin
 Working Group: Individual Submissions (none)
 Formats: txt
DNS zone transfers are transmitted in clear text, which gives attackers the opportunity to collect the content of a zone by eavesdropping on network connections. The DNS Transaction Signature (TSIG) mechanism is specified to restrict direct zone transfer to authorized clients only, but it does not add confidentiality. This document specifies use of DNS-over-TLS to prevent zone contents collection via passive monitoring of zone transfers.
    
draft-iab-protocol-maintenance-02.txt
 The Harmful Consequences of the Robustness Principle
 
 draft-iab-protocol-maintenance-02.txt
 Date: 10/03/2019
 Authors: Martin Thomson
 Working Group: Internet Architecture Board (iab)
 Formats: xml txt
Jon Postel's famous statement of "Be liberal in what you accept, and conservative in what you send" is a principle that has long guided the design and implementation of Internet protocols. The posture this statement advocates promotes interoperability in the short term, but can negatively affect the protocol ecosystem. For a protocol that is actively maintained, the Postel's robustness principle can, and should, be avoided.
    
draft-iab-rfc7991bis-01.txt
 The "xml2rfc" version 3 Vocabulary
 
 draft-iab-rfc7991bis-01.txt
 Date: 19/10/2018
 Authors: Paul Hoffman
 Working Group: Internet Architecture Board (iab)
 Formats: txt
This document defines the "xml2rfc" version 3 vocabulary: an XML- based language used for writing RFCs and Internet-Drafts. It is heavily derived from the version 2 vocabulary that is also under discussion. This document obsoletes the earlier v3 grammar described in RFC 7991, which in turn obsoleted the v2 grammar in RFC 7749. Editorial Note (To be removed by RFC Editor) Discussion of this draft takes place on the xml2rfc-dev@ietf.org mailing list, which has its home page at .
    
draft-icann-registrar-interfaces-02.txt
 ICANN Registrar Interfaces
 
 draft-icann-registrar-interfaces-02.txt
 Date: 24/03/2019
 Authors: Gustavo Lozano, Eduardo Alvarez
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents in order to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications.
    
draft-iesg-aukc-00.txt
 Audit Un-Known Cash
 
 draft-iesg-aukc-00.txt
 Date: 04/02/2019
 Authors: FIELDS Scott
 Working Group: Individual Submissions (none)
 Formats: txt
The issue concerns auditing financial records from several sources over time. To validate proper legal money usage and flow is a difficult task. Each financial institution has non-common reporting methods. Seek to create a common export record to merge transactions and easily sort by date , time , and institution. The first goal is to create a traceability file of transactions. The second goal is to create a "simple" standard record for "anyone" to sift and sort records.
    
draft-ietf-6lo-ap-nd-12.txt
 Address Protected Neighbor Discovery for Low-power and Lossy Networks
 
 draft-ietf-6lo-ap-nd-12.txt
 Date: 10/04/2019
 Authors: Pascal Thubert, Behcet Sarikaya, Mohit Sethi, Rene Struik
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This document specifies an extension to 6LoWPAN Neighbor Discovery (ND) protocol defined in RFC6775 and updated in RFC8505. The new extension is called Address Protected Neighbor Discovery (AP-ND) and it protects the owner of an address against address theft and impersonation attacks in a low-power and lossy network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto- ID) and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof-of-ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.
    
draft-ietf-6lo-backbone-router-11.txt
 IPv6 Backbone Router
 
 draft-ietf-6lo-backbone-router-11.txt
 Date: 04/02/2019
 Authors: Pascal Thubert, Charles Perkins, Eric Levy-Abegnoli
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This document updates RFC 4861 and RFC 8505 in order to enable proxy services for IPv6 Neighbor Discovery by Routing Registrars called Backbone Routers. Backbone Routers are placed along the wireless edge of a Backbone, and federate multiple wireless links to form a single MultiLink Subnet.
    
draft-ietf-6lo-blemesh-05.txt
 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
 
 draft-ietf-6lo-blemesh-05.txt
 Date: 09/03/2019
 Authors: Carles Gomez, Seyed Darroudi, Teemu Savolainen, Michael Spoerk
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable IPv6 over Bluetooth low energy networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies mechanisms that are needed to enable IPv6 mesh over Bluetooth Low Energy links established by using the Bluetooth Internet Protocol Support Profile. This document does not specify the routing protocol to be used in an IPv6 mesh over Bluetooth LE links.
    
draft-ietf-6lo-deadline-time-04.txt
 Packet Delivery Deadline time in 6LoWPAN Routing Header
 
 draft-ietf-6lo-deadline-time-04.txt
 Date: 08/03/2019
 Authors: Lijo Thomas, Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This document specifies a new type for the 6LoWPAN routing header containing the deadline time for data packets, designed for use over constrained networks. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that operate within time-synchronized networks that agree on the meaning of the time representations used for the deadline time values.
    
draft-ietf-6lo-fragment-recovery-02.txt
 6LoWPAN Selective Fragment Recovery
 
 draft-ietf-6lo-fragment-recovery-02.txt
 Date: 23/01/2019
 Authors: Pascal Thubert
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This draft updates RFC 4944 with a simple protocol to recover individual fragments across a route-over mesh network, with a minimal flow control to protect the network against bloat.
    
draft-ietf-6lo-minimal-fragment-01.txt
 LLN Minimal Fragment Forwarding
 
 draft-ietf-6lo-minimal-fragment-01.txt
 Date: 11/03/2019
 Authors: Thomas Watteyne, Carsten Bormann, Pascal Thubert
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This document gives an overview of LLN Minimal Fragment Forwarding. When employing adaptation layer fragmentation in 6LoWPAN, it may be beneficial for a forwarder not to have to reassemble each packet in its entirety before forwarding it. This has always been possible with the original fragmentation design of RFC4944. This document is a companion document to [I-D.ietf-lwig-6lowpan-virtual-reassembly], which details the virtual Reassembly Buffer (VRB) implementation technique which reduces the latency and increases end-to-end reliability in route-over forwarding.
    
draft-ietf-6lo-nfc-13.txt
 Transmission of IPv6 Packets over Near Field Communication
 
 draft-ietf-6lo-nfc-13.txt
 Date: 10/02/2019
 Authors: Younghwan Choi, Yong-Geun Hong, Joo-Sang Youn, Dongkyun Kim, JinHyeock Choi
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LowPAN techniques.
    
draft-ietf-6lo-plc-00.txt
 Transmission of IPv6 Packets over PLC Networks
 
 draft-ietf-6lo-plc-00.txt
 Date: 03/02/2019
 Authors: Jianqiang Hou, Bing Liu, Yong-Geun Hong, Xiaojun Tang, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt
Power Line Communication (PLC), namely using the electric-power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The inherent advantage of existing electricity infrastructure facilitates the expansion of PLC deployments, and moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as ITU-T G.9903, IEEE 1901.1 and IEEE 1901.2.
    
draft-ietf-6lo-use-cases-06.txt
 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases
 
 draft-ietf-6lo-use-cases-06.txt
 Date: 11/03/2019
 Authors: Yong-Geun Hong, Carles Gomez, Abdur Sangi, Take Aanstoot, Samita Chakrabarti
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt
This document describes the applicability of IPv6 over constrained node networks (6lo) and provides practical deployment examples. In addition to IEEE 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, PLC (IEEE 1901.2), and IEEE 802.15.4e (6tisch) are used as examples. The document targets an audience who like to understand and evaluate running end- to-end IPv6 over the constrained node networks connecting devices to each other or to other devices on the Internet (e.g. cloud infrastructure).
    
draft-ietf-6man-ipv6only-flag-05.txt
 IPv6 Router Advertisement IPv6-Only Flag
 
 draft-ietf-6man-ipv6only-flag-05.txt
 Date: 07/03/2019
 Authors: Robert Hinden, Brian Carpenter, Bjoern Zeeb
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
This document specifies a Router Advertisement Flag to indicate to hosts that the administrator has configured the router to advertise that the link is IPv6-Only. This document updates RFC4861 and RFC5175.
    
draft-ietf-6man-ra-pref64-00.txt
 Discovering PREF64 in Router Advertisements
 
 draft-ietf-6man-ra-pref64-00.txt
 Date: 24/03/2019
 Authors: Lorenzo Colitti, Erik Kline, Jen Linkova
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
This document specifies a Router Advertisement option to communicate NAT64 prefixes to clients.
    
draft-ietf-6man-rfc4941bis-01.txt
 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
 
 draft-ietf-6man-rfc4941bis-01.txt
 Date: 11/03/2019
 Authors: Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. This document describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.
    
draft-ietf-6man-segment-routing-header-18.txt
 IPv6 Segment Routing Header (SRH)
 
 draft-ietf-6man-segment-routing-header-18.txt
 Date: 05/04/2019
 Authors: Clarence Filsfils, Stefano Previdi, John Leddy, Satoru Matsushima, daniel.voyer@bell.ca
 Working Group: IPv6 Maintenance (6man)
 Formats: xml txt
Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header. This document describes the Segment Routing Extension Header and how it is used by Segment Routing capable nodes.
    
draft-ietf-6tisch-architecture-20.txt
 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4
 
 draft-ietf-6tisch-architecture-20.txt
 Date: 01/03/2019
 Authors: Pascal Thubert
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
This document describes a network architecture that provides low- latency, low-jitter and high-reliability packet delivery. It combines a high-speed powered backbone and subnetworks using IEEE 802.15.4 time-slotted channel hopping (TSCH) to meet the requirements of LowPower wireless deterministic applications.
    
draft-ietf-6tisch-dtsecurity-zerotouch-join-03.txt
 6tisch Zero-Touch Secure Join protocol
 
 draft-ietf-6tisch-dtsecurity-zerotouch-join-03.txt
 Date: 22/10/2018
 Authors: Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This document describes a Zero-touch Secure Join (ZSJ) mechanism to enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch signaling mechanisms. The resulting device will obtain a domain specific credential that can be used with either 802.15.9 per-host pair keying protocols, or to obtain the network- wide key from a coordinator. The mechanism describe here is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security], and a constrained version of [I-D.ietf-anima-bootstrapping-keyinfra].
    
draft-ietf-6tisch-enrollment-enhanced-beacon-02.txt
 IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information
 
 draft-ietf-6tisch-enrollment-enhanced-beacon-02.txt
 Date: 25/03/2019
 Authors: Diego Dujovne, Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
In TSCH mode of IEEE802.15.4, as described by [RFC8180], opportunities for broadcasts are limited to specific times and specific channels. Nodes in a TSCH network typically frequently send Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which small details critical for new nodes (pledges) and long sleeping nodes may be carried within the Enhanced Beacon.
    
draft-ietf-6tisch-minimal-security-10.txt
 Minimal Security Framework for 6TiSCH
 
 draft-ietf-6tisch-minimal-security-10.txt
 Date: 05/04/2019
 Authors: Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This document describes the minimal framework required for a new device, called "pledge", to securely join a 6TiSCH (IPv6 over the TSCH mode of IEEE 802.15.4e) network. The framework requires that the pledge and the JRC (join registrar/coordinator, a central entity), share a symmetric key. How this key is provisioned is out of scope of this document. Through a single CoAP (Constrained Application Protocol) request-response exchange secured by OSCORE (Object Security for Constrained RESTful Environments), the pledge requests admission into the network and the JRC configures it with link-layer keying material and other parameters. The JRC may at any time update the parameters through another request-response exchange secured by OSCORE. This specification defines the Constrained Join Protocol and its CBOR (Concise Binary Object Representation) data structures, and configures the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework.
    
draft-ietf-6tisch-msf-03.txt
 6TiSCH Minimal Scheduling Function (MSF)
 
 draft-ietf-6tisch-msf-03.txt
 Date: 08/04/2019
 Authors: Tengfei Chang, Malisa Vucinic, Xavier Vilajosana, Simon Duquennoy, Diego Dujovne
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt xml
This specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH.
    
draft-ietf-ace-actors-07.txt
 An architecture for authorization in constrained environments
 
 draft-ietf-ace-actors-07.txt
 Date: 22/10/2018
 Authors: Stefanie Gerdes, Ludwig Seitz, Goeran Selander, Carsten Bormann
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
Constrained-node networks are networks where some nodes have severe constraints on code size, state memory, processing capabilities, user interface, power and communication bandwidth (RFC 7228). This document provides terminology, and identifies the elements that an architecture needs to address, providing a problem statement, for authentication and authorization in these networks.
    
draft-ietf-ace-coap-est-10.txt
 EST over secure CoAP (EST-coaps)
 
 draft-ietf-ace-coap-est-10.txt
 Date: 08/03/2019
 Authors: Peter van der Stok, Panos Kampanakis, Michael Richardson, Shahid Raza
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: xml txt
Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows constrained devices to use existing EST functionality for provisioning certificates.
    
draft-ietf-ace-cwt-proof-of-possession-06.txt
 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
 
 draft-ietf-ace-cwt-proof-of-possession-06.txt
 Date: 21/02/2019
 Authors: Michael Jones, Ludwig Seitz, Goeran Selander, Samuel Erdtman, Hannes Tschofenig
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt xml
This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs.
    
draft-ietf-ace-dtls-authorize-08.txt
 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
 
 draft-ietf-ace-dtls-authorize-08.txt
 Date: 12/04/2019
 Authors: Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: xml txt
This specification defines a profile of the ACE framework that allows constrained servers to delegate client authentication and authorization. The protocol relies on DTLS for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource-constrained server can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory.
    
draft-ietf-ace-key-groupcomm-01.txt
 Key Provisioning for Group Communication using ACE
 
 draft-ietf-ace-key-groupcomm-01.txt
 Date: 08/03/2019
 Authors: Francesca Palombini, Marco Tiloca
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
This document defines message formats and procedures for requesting and distributing group keying material using the ACE framework, to protect communications between group members.
    
draft-ietf-ace-key-groupcomm-oscore-01.txt
 Key Management for OSCORE Groups in ACE
 
 draft-ietf-ace-key-groupcomm-oscore-01.txt
 Date: 08/03/2019
 Authors: Marco Tiloca, Jiye Park, Francesca Palombini
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
This document describes a method to request and provision keying material in group communication scenarios where communications are based on CoAP and secured with Object Security for Constrained RESTful Environments (OSCORE). The proposed method delegates the authentication and authorization of new client nodes that join an OSCORE group through a Group Manager server. This approach builds on the ACE framework for Authentication and Authorization, and leverages protocol-specific profiles of ACE to achieve communication security, proof-of-possession and server authentication.
    
draft-ietf-ace-oauth-authz-24.txt
 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
 
 draft-ietf-ace-oauth-authz-24.txt
 Date: 27/03/2019
 Authors: Ludwig Seitz, Goeran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined.
    
draft-ietf-ace-oauth-params-05.txt
 Additional OAuth Parameters for Authorization in Constrained Environments (ACE)
 
 draft-ietf-ace-oauth-params-05.txt
 Date: 25/03/2019
 Authors: Ludwig Seitz
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with the framework for authentication and authorization for constrained environments (ACE). These are used to express the proof-of-possession key the client whishes to use, the proof-of-possession key that the AS has selected, and the key the RS should use to authenticate to the client.
    
draft-ietf-ace-oscore-profile-07.txt
 OSCORE profile of the Authentication and Authorization for Constrained Environments Framework
 
 draft-ietf-ace-oscore-profile-07.txt
 Date: 19/02/2019
 Authors: Francesca Palombini, Ludwig Seitz, Goeran Selander, Martin Gunnarsson
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: xml txt
This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.
    
draft-ietf-acme-authority-token-03.txt
 ACME Challenges Using an Authority Token
 
 draft-ietf-acme-authority-token-03.txt
 Date: 25/03/2019
 Authors: Jon Peterson, Mary Barnes, David Hancock, Chris Wendt
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt
Some proposed extensions to the Automated Certificate Management Environment (ACME) rely on proving eligibility for certificates through consulting an external authority that issues a token according to a particular policy. This document specifies a generic Authority Token challenge for ACME which supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications.
    
draft-ietf-acme-authority-token-tnauthlist-03.txt
 TNAuthList profile of ACME Authority Token
 
 draft-ietf-acme-authority-token-tnauthlist-03.txt
 Date: 25/03/2019
 Authors: Chris Wendt, David Hancock, Mary Barnes, Jon Peterson
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for VoIP Telephone Providers to support Secure Telephony Identity (STI) using the TNAuthList defined by STI certificates.
    
draft-ietf-acme-caa-06.txt
 CAA Record Extensions for Account URI and ACME Method Binding
 
 draft-ietf-acme-caa-06.txt
 Date: 15/01/2019
 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-acme-email-smime-04.txt
 Extensions to Automatic Certificate Management Environment for end user S/MIME certificates
 
 draft-ietf-acme-email-smime-04.txt
 Date: 19/10/2018
 Authors: Alexey Melnikov
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.
    
draft-ietf-acme-ip-05.txt
 ACME IP Identifier Validation Extension
 
 draft-ietf-acme-ip-05.txt
 Date: 14/02/2019
 Authors: Roland Shoemaker
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.
    
draft-ietf-acme-star-05.txt
 Support for Short-Term,Automatically-Renewed (STAR) Certificates in Automated Certificate Management Environment (ACME)
 
 draft-ietf-acme-star-05.txt
 Date: 04/03/2019
 Authors: Yaron Sheffer, Diego Lopez, Oscar de Dios, Antonio Pastor, Thomas Fossati
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
Public-key certificates need to be revoked when they are compromised, that is, when the associated private key is exposed to an unauthorized entity. However the revocation process is often unreliable. An alternative to revocation is issuing a sequence of certificates, each with a short validity period, and terminating this sequence upon compromise. This memo proposes an ACME extension to enable the issuance of short-term and automatically renewed (STAR) X.509 certificates. [RFC Editor: please remove before publication] While the draft is being developed, the editor's version can be found at https://github.com/yaronf/I-D/tree/master/STAR.
    
draft-ietf-acme-star-delegation-00.txt
 An ACME Profile for Generating Delegated STAR Certificates
 
 draft-ietf-acme-star-delegation-00.txt
 Date: 13/12/2018
 Authors: Yaron Sheffer, Diego Lopez, Antonio Pastor, Thomas Fossati
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This memo proposes a profile of the ACME protocol that allows the owner of an identifier (e.g., a domain name) to delegate to a third party access to a certificate associated with said identifier. A primary use case is that of a CDN (the third party) terminating TLS sessions on behalf of a content provider (the owner of a domain name). The presented mechanism allows the owner of the identifier to retain control over the delegation and revoke it at any time by cancelling the associated STAR certificate renewal with the ACME CA. Another key property of this mechanism is it does not require any modification to the deployed TLS ecosystem.
    
draft-ietf-acme-tls-alpn-05.txt
 ACME TLS ALPN Challenge Extension
 
 draft-ietf-acme-tls-alpn-05.txt
 Date: 17/08/2018
 Authors: Roland Shoemaker
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
This document specifies a new challenge for the Automated Certificate Management Environment (ACME) protocol which allows for domain control validation using TLS.
    
draft-ietf-alto-cdni-request-routing-alto-05.txt
 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO
 
 draft-ietf-alto-cdni-request-routing-alto-05.txt
 Date: 11/03/2019
 Authors: Jan Seedorf, Yang Yang, Kevin Ma, Jon Peterson, Xiao Lin
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Content Delivery Networks Interconnection (CDNI) framework [RFC6707] defines a set of protocols to interconnect CDNs, to achieve multiple goals such as extending the reach of a given CDN to areas that are not covered by that particular CDN. One component that is needed to achieve the goal of CDNI described in [RFC7336] is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI). [RFC8008] defines precisely the semantics of FCI and provides guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. In this document, we follow the guidelines to define an FCI protocol using the Application-Layer Traffic Optimization (ALTO) protocol.
    
draft-ietf-alto-cost-calendar-11.txt
 ALTO Cost Calendar
 
 draft-ietf-alto-cost-calendar-11.txt
 Date: 27/02/2019
 Authors: Sabine Randriamasy, Yang Yang, Qin Wu, Deng Lingli, Nico Schwan
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
This document is an extension to the base Application-Layer Traffic Optimization (ALTO) protocol. It extends the ALTO cost information service such that applications decide not only 'where' to connect, but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces ALTO Cost Calendars, with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes, are specified in the Information Resources Directory and ALTO Server responses.
    
draft-ietf-alto-incr-update-sse-16.txt
 ALTO Incremental Updates Using Server-Sent Events (SSE)
 
 draft-ietf-alto-incr-update-sse-16.txt
 Date: 11/03/2019
 Authors: Wendy Roome, Yang Yang
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt xml
The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. For example, an ALTO server can provide network and cost maps so that an ALTO client can use the maps to determine the costs between network endpoints when choosing communicating endpoints. However, the ALTO protocol does not define a mechanism to allow an ALTO client to obtain updates to the information resources, other than by periodically re-fetching them. Because some information resources (e.g., the aforementioned maps) may be large (potentially tens of megabytes), and because only parts of the information resources may change frequently (e.g., only some entries in a cost map), complete re-fetching can be extremely inefficient. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients, to achieve two benefits: (1) updates can be immediate, in that the ALTO server can send updates as soon as they are available; and (2) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes.
    
draft-ietf-alto-path-vector-05.txt
 ALTO Extension: Path Vector Cost Type
 
 draft-ietf-alto-path-vector-05.txt
 Date: 11/03/2019
 Authors: Kai Gao, Young Lee, Sabine Randriamasy, Yang Yang, J. Zhang
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] has defined cost maps and endpoint cost maps to provide basic network information. However, they provide only scalar (numerical or ordinal) cost mode values, which are insufficient to satisfy the demands of solving more complex network optimization problems. This document introduces an extension to the base ALTO protocol, namely the path-vector extension, which allows ALTO clients to query information such as the capacity region for a given set of flows (called co-flows). A non-normative example called co-flow scheduling is presented to illustrate the limitations of existing ALTO endpoint cost maps. After that, details of the extension are defined.
    
draft-ietf-alto-performance-metrics-06.txt
 ALTO Performance Cost Metrics
 
 draft-ietf-alto-performance-metrics-06.txt
 Date: 28/11/2018
 Authors: Qin Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: xml txt
Cost Metric is a basic concept in Application-Layer Traffic Optimization (ALTO). It is used in both the Cost Map Service and the Endpoint Cost Service. Different applications may benefit from different Cost Metrics. For example, a Resource Consumer may prefer Resource Providers that offer a low delay delivery to the Resource Consumer. However, the base ALTO protocol has documented only one single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [RFC7285]). This document proposes a set of Cost Metrics, derived and aggregated from routing protocols with different granularity and scope, such as BGP-LS, OSPF-TE and ISIS-TE, or from end-to-end traffic management tools. It currently documents Network Performance Cost Metrics reporting on network delay, jitter, packet loss, hop count, and bandwidth. These metrics may be exposed by an ALTO Server to allow applications to determine "where" to connect based on network performance criteria. Additional Cost Metrics involving ISP specific considerations or other network technologies may be documented in further versions of this draft.
    
draft-ietf-alto-unified-props-new-07.txt
 Unified Properties for the ALTO Protocol
 
 draft-ietf-alto-unified-props-new-07.txt
 Date: 11/03/2019
 Authors: Wendy Roome, Sabine Randriamasy, Yang Yang, J. Zhang
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to domains of other entities, and by presenting those properties as maps, similar to the network and cost maps in ALTO.
    
draft-ietf-alto-xdom-disc-04.txt
 Application Layer Traffic Optimization (ALTO) Cross-Domain Server Discovery
 
 draft-ietf-alto-xdom-disc-04.txt
 Date: 13/11/2018
 Authors: Sebastian Kiesel, Martin Stiemerling
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications that have to select one or several hosts from a set of candidates capable of providing a desired resource. ALTO is realized by a client-server protocol. Before an ALTO client can ask for guidance it needs to discover one or more ALTO servers that can provide suitable guidance. In some deployment scenarios, in particular if the information about the network topology is partitioned and distributed over several ALTO servers, it may be needed to discover an ALTO server outside of the own network domain, in order to get appropriate guidance. This document details applicable scenarios, itemizes requirements, and specifies a procedure for ALTO cross-domain server discovery. Technically, the procedure specified in this document takes one IP address or prefix and a U-NAPTR Service Parameter (typically, "ALTO:https") as parameters. It performs DNS lookups (for NAPTR resource records in the in-addr.arpa. or ip6.arpa. tree) and returns one or more URI(s) of information resources related to that IP address or prefix.
    
draft-ietf-ancp-protocol-access-extension-00.txt
 Access Extensions for the Access Node Control Protocol
 
 draft-ietf-ancp-protocol-access-extension-00.txt
 Date: 11/01/2019
 Authors: Li Hongyu, Thomas Haag, Birgit Witschurke
 Working Group: Individual Submissions (none)
 Formats: txt xml
The purpose of this document is to specify extensions to ANCP (Access Node Control Protocol) (RFC6320) to support PON as described in RFC6934 and some other DSL Technologies including G.fast. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types. This document updates RFC6320 by modifications to terminologies, flows and specifying new TLV types.
    
draft-ietf-anima-autonomic-control-plane-19.txt
 An Autonomic Control Plane (ACP)
 
 draft-ietf-anima-autonomic-control-plane-19.txt
 Date: 11/03/2019
 Authors: Toerless Eckert, Michael Behringer, Steinthor Bjarnason
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that provides automatically configured hop-by-hop authenticated and encrypted communications via automatically configured IPv6 even when the network is not configured, or misconfigured.
    
draft-ietf-anima-bootstrapping-keyinfra-19.txt
 Bootstrapping Remote Secure Key Infrastructures (BRSKI)
 
 draft-ietf-anima-bootstrapping-keyinfra-19.txt
 Date: 07/03/2019
 Authors: Max Pritikin, Michael Richardson, Michael Behringer, Steinthor Bjarnason, Kent Watsen
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document specifies automated bootstrapping of an Autonomic Control Plane. To do this a remote secure key infrastructure (BRSKI) is created using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well.
    
draft-ietf-anima-constrained-voucher-03.txt
 Constrained Voucher Artifacts for Bootstrapping Protocols
 
 draft-ietf-anima-constrained-voucher-03.txt
 Date: 25/03/2019
 Authors: Michael Richardson, Peter van der Stok, Panos Kampanakis
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document builds upon the work in [RFC8366], encoding the resulting artifact in CBOR. Use with two signature technologies are described. Additionally, this document explains how constrained vouchers may be transported in the [I-D.ietf-ace-coap-est] protocol.
    
draft-ietf-anima-grasp-15.txt
 A Generic Autonomic Signaling Protocol (GRASP)
 
 draft-ietf-anima-grasp-15.txt
 Date: 13/07/2017
 Authors: Carsten Bormann, Brian Carpenter, Bing Liu
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.
    
draft-ietf-anima-grasp-api-03.txt
 Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)
 
 draft-ietf-anima-grasp-api-03.txt
 Date: 20/01/2019
 Authors: Brian Carpenter, Bing Liu, Wendong Wang, Xiangyang Gong
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
This document is a conceptual outline of an application programming interface (API) for the Generic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASA) calling the GRASP protocol module to exchange autonomic network messages with other ASAs.
    
draft-ietf-anima-prefix-management-07.txt
 Autonomic IPv6 Edge Prefix Management in Large-scale Networks
 
 draft-ietf-anima-prefix-management-07.txt
 Date: 18/12/2017
 Authors: Sheng Jiang, Zongpeng Du, Brian Carpenter, Qiong Sun
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure.
    
draft-ietf-anima-reference-model-10.txt
 A Reference Model for Autonomic Networking
 
 draft-ietf-anima-reference-model-10.txt
 Date: 22/11/2018
 Authors: Michael Behringer, Brian Carpenter, Toerless Eckert, Laurent Ciavaglia, Jeferson Nobre
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.
    
draft-ietf-avtcore-cc-feedback-message-03.txt
 RTP Control Protocol (RTCP) Feedback for Congestion Control
 
 draft-ietf-avtcore-cc-feedback-message-03.txt
 Date: 23/12/2018
 Authors: Zaheduzzaman Sarker, Colin Perkins, Varun Singh, Michael Ramalho
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt
This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends RTCP feedback packets to the sender containing the information the sender needs to perform congestion control.
    
draft-ietf-avtcore-multi-media-rtp-session-13.txt
 Sending Multiple Types of Media in a Single RTP Session
 
 draft-ietf-avtcore-multi-media-rtp-session-13.txt
 Date: 18/12/2015
 Authors: Magnus Westerlund, Colin Perkins, Jonathan Lennox
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: xml txt
This document specifies how an RTP session can contain RTP Streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session.
    
draft-ietf-avtcore-multiplex-guidelines-08.txt
 Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams
 
 draft-ietf-avtcore-multiplex-guidelines-08.txt
 Date: 14/12/2018
 Authors: Magnus Westerlund, Bo Burman, Colin Perkins, Harald Alvestrand, Roni Even
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: xml txt
The Real-time Transport Protocol (RTP) is a flexible protocol that can be used in a wide range of applications, networks, and system topologies. That flexibility makes for wide applicability, but can complicate the application design process. One particular design question that has received much attention is how to support multiple media streams in RTP. This memo discusses the available options and design trade-offs, and provides guidelines on how to use the multiplexing features of RTP to support multiple media streams.
    
draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt
 Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP Reception Statistics and Other Feedback
 
 draft-ietf-avtcore-rtp-multi-stream-optimisation-12.txt
 Date: 02/03/2016
 Authors: Jonathan Lennox, Magnus Westerlund, Qin Wu, Colin Perkins
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt
RTP allows multiple RTP streams to be sent in a single session, but requires each Synchronisation Source (SSRC) to send RTCP reception quality reports for every other SSRC visible in the session. This causes the number of RTCP reception reports to grow with the number of SSRCs, rather than the number of endpoints. In many cases most of these RTCP reception reports are unnecessary, since all SSRCs of an endpoint are normally co-located and see the same reception quality. This memo defines a Reporting Group extension to RTCP to reduce the reporting overhead in such scenarios.
    
draft-ietf-avtext-framemarking-09.txt
 Frame Marking RTP Header Extension
 
 draft-ietf-avtext-framemarking-09.txt
 Date: 28/03/2019
 Authors: Mo Zanaty, Espen Berger, Suhas Nandakumar
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt xml
This document describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information.
    
draft-ietf-avtext-lrr-07.txt
 The Layer Refresh Request (LRR) RTCP Feedback Message
 
 draft-ietf-avtext-lrr-07.txt
 Date: 02/07/2017
 Authors: Jonathan Lennox, Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman
 Working Group: Audio/Video Transport Extensions (avtext)
 Formats: xml txt
This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats.
    
draft-ietf-avtext-rid-09.txt
 RTP Stream Identifier Source Description (SDES)
 
 draft-ietf-avtext-rid-09.txt
 Date: 06/10/2016
 Authors: Adam Roach, Suhas Nandakumar, Peter Thatcher
 Working Group: Audio/Video Transport Extensions (avtext)
 Formats: txt
This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair.
    
draft-ietf-babel-applicability-05.txt
 Applicability of the Babel routing protocol
 
 draft-ietf-babel-applicability-05.txt
 Date: 14/11/2018
 Authors: Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
Babel is a routing protocol based on the distance-vector algorithm augmented with mechanisms for loop avoidance and starvation avoidance. In this document, we argue that there exist niches where Babel is useful and that are not adequately served by more mature protocols.
    
draft-ietf-babel-dtls-04.txt
 Babel Routing Protocol over Datagram Transport Layer Security
 
 draft-ietf-babel-dtls-04.txt
 Date: 06/02/2019
 Authors: Antonin Decimo, David Schinazi, Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
The Babel Routing Protocol does not contain any means to authenticate neighbours or protect messages sent between them. This documents specifies a mechanism to ensure these properties, using Datagram Transport Layer Security (DTLS). This document updates RFC 6126bis.
    
draft-ietf-babel-hmac-04.txt
 HMAC authentication for the Babel routing protocol
 
 draft-ietf-babel-hmac-04.txt
 Date: 09/03/2019
 Authors: Clara Do, Weronika Kolodziejak, Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
This document describes a cryptographic authentication mechanism for the Babel routing protocol that has provisions for replay avoidance. This document updates RFC 6126bis and obsoletes RFC 7298.
    
draft-ietf-babel-information-model-05.txt
 Babel Information Model
 
 draft-ietf-babel-information-model-05.txt
 Date: 05/03/2019
 Authors: Barbara Stark, Mahesh Jethanandani
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
This Babel Information Model can be used to create data models under various data modeling regimes. It allows a Babel implementation (via a management protocol or interface) to report on its current state and may allow some limited configuration of protocol constants.
    
draft-ietf-babel-rfc6126bis-08.txt
 The Babel Routing Protocol
 
 draft-ietf-babel-rfc6126bis-08.txt
 Date: 27/03/2019
 Authors: Juliusz Chroboczek, David Schinazi
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557.
    
draft-ietf-babel-source-specific-05.txt
 Source-Specific Routing in Babel
 
 draft-ietf-babel-source-specific-05.txt
 Date: 11/04/2019
 Authors: Matthieu Boutier, Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
Source-specific routing (also known as Source-Address Dependent Routing, SADR) is an extension to traditional next-hop routing where packets are forwarded according to both their destination and their source address. This document describes an extension for source- specific routing to the Babel routing protocol.
    
draft-ietf-babel-yang-model-01.txt
 YANG Data Model for Babel
 
 draft-ietf-babel-yang-model-01.txt
 Date: 08/03/2019
 Authors: Mahesh Jethanandani, Barbara Stark
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
This document defines a data model for the Babel routing protocol. The data model is defined using the YANG data modeling language.
    
draft-ietf-behave-syslog-nat-logging-06.txt
 Syslog Format for NAT Logging
 
 draft-ietf-behave-syslog-nat-logging-06.txt
 Date: 24/01/2014
 Authors: Zhonghua Chen, Cathy Zhou, Tina Tsou, Tom Taylor
 Working Group: Individual Submissions (none)
 Formats: txt xml
NAT devices are required to log events like creation and deletion of translations and information about the resources the NAT is managing. The logs are required to identify an attacker or a host that was used to launch malicious attacks, and for various other purposes of accounting and management. Since there is no standard way of logging this information, different NAT devices behave differently. The lack of a consistent way makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the information that is required to be logged by the NAT devices. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 7011). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging.
    
draft-ietf-bess-bgp-vpls-control-flags-08.txt
 Updated processing of Control Flags for BGP VPLS
 
 draft-ietf-bess-bgp-vpls-control-flags-08.txt
 Date: 19/04/2019
 Authors: Ravi Singh, Kireeti Kompella, Senad Palislamovic
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document updates the meaning of the Control Flags field in the Layer2 Info Extended Community used for BGP-VPLS NLRI as defined in RFC4761. This document updates RFC4761.
    
draft-ietf-bess-datacenter-gateway-02.txt
 Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection
 
 draft-ietf-bess-datacenter-gateway-02.txt
 Date: 26/02/2019
 Authors: Adrian Farrel, John Drake, Eric Rosen, Keyur Patel, Luay Jalil
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt xml
Data centers are 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 use within a data center, but also for steering traffic that flows between two data center sites. In order that one data center site may load balance the traffic it sends to another data center site, it needs to know the complete set of gateway routers at the remote data center, the points of connection from those gateways to the backbone network, and the connectivity across the backbone network. Segment Routing may also be operated in other domains, such as access networks. Those domains also need to be connected across backbone networks through gateways. This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the Segment Routing domains to which it provides access, and also to advertise on behalf of each other gateway to the same Segment Routing domain.
    
draft-ietf-bess-dci-evpn-overlay-10.txt
 Interconnect Solution for EVPN Overlay networks
 
 draft-ietf-bess-dci-evpn-overlay-10.txt
 Date: 02/03/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Ali Sajassi, John Drake
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes how Network Virtualization Overlays (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPN) and other L2VPN technologies used in the WAN, such as Virtual Private LAN Services (VPLS), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how the existing technical specifications apply to the Interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, and the use of the Unknown MAC route to avoid MAC scale issues on Data Center Network Virtualization Edge (NVE) devices.
    
draft-ietf-bess-evpn-bum-procedure-updates-05.txt
 Updates on EVPN BUM Procedures
 
 draft-ietf-bess-evpn-bum-procedure-updates-05.txt
 Date: 13/12/2018
 Authors: Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation.
    
draft-ietf-bess-evpn-df-election-framework-09.txt
 Framework for EVPN Designated Forwarder Election Extensibility
 
 draft-ietf-bess-evpn-df-election-framework-09.txt
 Date: 24/01/2019
 Authors: Jorge Rabadan, satyamoh@cisco.com, Ali Sajassi, John Drake, Kiran Nagaraj, Senthil Sathappan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
An alternative to the Default Designated Forwarder (DF) selection algorithm in Ethernet VPN (EVPN) networks is defined. The DF is the Provider Edge (PE) router responsible for sending broadcast, unknown unicast and multicast (BUM) traffic to multi-homed Customer Equipment (CE) on a particular Ethernet Segment (ES) within a VLAN. In addition, the capability to influence the DF election result for a VLAN based on the state of the associated Attachment Circuit (AC) is specified. This document clarifies the DF Election Finite State Machine in EVPN, therefore it updates the EVPN specification.
    
draft-ietf-bess-evpn-inter-subnet-forwarding-08.txt
 Integrated Routing and Bridging in EVPN
 
 draft-ietf-bess-evpn-inter-subnet-forwarding-08.txt
 Date: 05/03/2019
 Authors: Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
EVPN provides an extensible and flexible multi-homing VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and End Devices while maintaining the multi-homing capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements.
    
draft-ietf-bess-evpn-ipvpn-interworking-00.txt
 EVPN Interworking with IPVPN
 
 draft-ietf-bess-evpn-ipvpn-interworking-00.txt
 Date: 06/03/2019
 Authors: Jorge Rabadan, Ali Sajassi, Eric Rosen, John Drake, Wen Lin, Jim Uttaro, Adam Simpson
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
EVPN is used as a unified control plane for tenant network intra and inter-subnet forwarding. When a tenant network spans not only EVPN domains but also domains where IPVPN provides inter-subnet forwarding, there is a need to specify the interworking aspects between both EVPN and IPVPN domains, so that the end to end tenant connectivity can be accomplished. This document specifies how EVPN should interwork with VPN-IPv4/VPN-IPv6 and IPv4/IPv6 BGP families for inter-subnet forwarding.
    
draft-ietf-bess-evpn-irb-extended-mobility-00.txt
 Extended Mobility Procedures for EVPN-IRB
 
 draft-ietf-bess-evpn-irb-extended-mobility-00.txt
 Date: 27/03/2019
 Authors: Neeraj Malhotra, Ali Sajassi, Aparna Pattekar, Avinash Lingala, Jorge Rabadan, John Drake
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The procedure to handle host mobility in a layer 2 Network with EVPN control plane is defined as part of RFC 7432. EVPN has since evolved to find wider applicability across various IRB use cases that include distributing both MAC and IP reachability via a common EVPN control plane. MAC Mobility procedures defined in RFC 7432 are extensible to IRB use cases if a fixed 1:1 mapping between VM IP and MAC is assumed across VM moves. Generic mobility support for IP and MAC that allows these bindings to change across moves is required to support a broader set of EVPN IRB use cases, and requires further consideration. EVPN all-active multi-homing further introduces scenarios that require additional consideration from mobility perspective. Intent of this draft is to enumerate a set of design considerations applicable to mobility across EVPN IRB use cases and define generic sequence number assignment procedures to address these IRB use cases.
    
draft-ietf-bess-evpn-irb-mcast-02.txt
 EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding
 
 draft-ietf-bess-evpn-irb-mcast-02.txt
 Date: 23/01/2019
 Authors: Wen Lin, Zhaohui Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the endusers to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to leave a given router and then reenter that same router. These procedures also accommodate IP multicast traffic that needs to travel to or from systems that are outside the EVPN domain.
    
draft-ietf-bess-evpn-na-flags-02.txt
 Propagation of IPv6 Neighbor Advertisement Flags in EVPN
 
 draft-ietf-bess-evpn-na-flags-02.txt
 Date: 19/10/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. However, if the Neighbor information is learnt via EVPN, the PE would not know if a particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address as this information is not carried in the MAC/IP route advertisements. This document proposes an OPTIONAL advertisement of the Flags defined in [RFC4861] along with the EVPN MAC/IP Advertisement routes, so that an EVPN PE implementing a proxy-ND function can reply to Neighbor Solicitations with the correct Flag information in Neighbor Advertisements.
    
draft-ietf-bess-evpn-oam-req-frmwk-00.txt
 EVPN Operations,Administration and Maintenance Requirements and Framework
 
 draft-ietf-bess-evpn-oam-req-frmwk-00.txt
 Date: 26/02/2019
 Authors: Samer Salam, Ali Sajassi, Sam Aldrin, John Drake, Donald Eastlake
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document specifies the requirements and reference framework for Ethernet VPN (EVPN) Operations, Administration and Maintenance (OAM). The requirements cover the OAM aspects of EVPN and PBB-EVPN. The framework defines the layered OAM model encompassing the EVPN service layer, network layer and underlying Packet Switched Network (PSN) transport layer.
    
draft-ietf-bess-evpn-optimized-ir-06.txt
 Optimized Ingress Replication solution for EVPN
 
 draft-ietf-bess-evpn-optimized-ir-06.txt
 Date: 19/10/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Wen Lin, Mukul Katiyar, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Network Virtualization Overlay (NVO) networks using EVPN as control plane may use Ingress Replication (IR) or PIM (Protocol Independent Multicast) based trees to convey the overlay BUM traffic. PIM provides an efficient solution to avoid sending multiple copies of the same packet over the same physical link, however it may not always be deployed in the NVO core network. IR avoids the dependency on PIM in the NVO network core. While IR provides a simple multicast transport, some NVO networks with demanding multicast applications require a more efficient solution without PIM in the core. This document describes a solution to optimize the efficiency of IR in NVO networks.
    
draft-ietf-bess-evpn-per-mcast-flow-df-election-01.txt
 Per multicast flow Designated Forwarder Election for EVPN
 
 draft-ietf-bess-evpn-per-mcast-flow-df-election-01.txt
 Date: 08/03/2019
 Authors: Ali Sajassi, mankamana mishra, Samir Thoria, Jorge Rabadan, John Drake
 Working Group: BGP Enabled ServiceS (bess)
 Formats: xml txt
[RFC7432] describes mechanism to elect designated forwarder (DF) at the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in case of VLAN bundle or VLAN-aware bundle service). However, the current level of granularity of per-VLAN is not adequate for some applications.[I-D.ietf-bess-evpn-df-election-framework] improves base line DF election by introducing HRW DF election. [I-D.ietf-bess-evpn-igmp-mld-proxy] introduces applicability of EVPN to Multicast flows, routes to sync them and a default DF election. This document is an extension to HRW base draft [I-D.ietf-bess-evpn-df-election-framework] and further enhances HRW algorithm for the Multicast flows to do DF election at the granularity of (ESI, VLAN, Mcast flow).
    
draft-ietf-bess-evpn-pref-df-03.txt
 Preference-based EVPN DF Election
 
 draft-ietf-bess-evpn-pref-df-03.txt
 Date: 21/12/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Tony Przygienda, Wen Lin, John Drake, Ali Sajassi, satyamoh@cisco.com
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The Designated Forwarder (DF) in Ethernet Virtual Private Networks (EVPN) is defined as the PE responsible for sending Broadcast, Unknown unicast and Broadcast traffic (BUM) to a multi-homed device/network in the case of an all-active multi-homing Ethernet Segment (ES), or BUM and unicast in the case of single-active multi- homing. The DF is selected out of a candidate list of PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network, according to the Default DF Election algorithm. While the Default Algorithm provides an efficient and automated way of selecting the DF across different Ethernet Tags in the ES, there are some use-cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on-demand DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes an extension to the Default DF election procedures so that the above requirements can be met.
    
draft-ietf-bess-evpn-prefix-advertisement-11.txt
 IP Prefix Advertisement in EVPN
 
 draft-ietf-bess-evpn-prefix-advertisement-11.txt
 Date: 18/05/2018
 Authors: Jorge Rabadan, Wim Henderickx, John Drake, Wen Lin, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The BGP MPLS-based Ethernet VPN (EVPN) [RFC7432] mechanism provides a flexible control plane that allows intra-subnet connectivity in an MPLS and/or NVO (Network Virtualization Overlay) [RFC7365] network. In some networks, there is also a need for a dynamic and efficient inter-subnet connectivity across Tenant Systems and End Devices that can be physical or virtual and do not necessarily participate in dynamic routing protocols. This document defines a new EVPN route type for the advertisement of IP Prefixes and explains some use-case examples where this new route-type is used.
    
draft-ietf-bess-evpn-proxy-arp-nd-05.txt
 Operational Aspects of Proxy-ARP/ND in EVPN Networks
 
 draft-ietf-bess-evpn-proxy-arp-nd-05.txt
 Date: 04/11/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Wim Henderickx, Greg Hankins, Thomas King, Daniel Melzer, Erik Nordmark
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The EVPN MAC/IP Advertisement route can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast-forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs. This document describes how the EVPN Proxy-ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains.
    
draft-ietf-bess-evpn-unequal-lb-01.txt
 Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing
 
 draft-ietf-bess-evpn-unequal-lb-01.txt
 Date: 25/03/2019
 Authors: Neeraj Malhotra, Ali Sajassi, Samir Thoria, Jorge Rabadan, John Drake, Avinash Lingala
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
In an EVPN-IRB based network overlay, EVPN all-active multi-homing enables multi-homing for a CE device connected to two or more PEs via a LAG bundle, such that bridged and routed traffic from remote PEs can be equally load balanced (ECMPed) across the multi-homing PEs. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi- homing PEs in order to: o provide greater flexibility, with respect to adding or removing individual PE-CE links within the access LAG o handle PE-CE LAG member link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs
    
draft-ietf-bess-evpn-virtual-eth-segment-04.txt
 EVPN Virtual Ethernet Segment
 
 draft-ietf-bess-evpn-virtual-eth-segment-04.txt
 Date: 18/01/2019
 Authors: Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
EVPN and PBB-EVPN introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced features among which their multi-homing capabilities. These solutions define two types of multi-homing for an Ethernet Segment (ES): 1) Single- Active and 2) All-Active, where an Ethernet Segment is defined as a set of links between the multi-homed device/network and a set of PE devices that they are connected to. Some Service Providers want to extend the concept of the physical links in an ES to Ethernet Virtual Circuits (EVCs) where many of such EVCs can be aggregated on a single physical External Network-to- Network Interface (ENNI). An ES that consists of a set of EVCs instead of physical links is referred to as a virtual ES (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN.
    
draft-ietf-bess-evpn-vpls-seamless-integ-07.txt
 (PBB-)EVPN Seamless Integration with (PBB-)VPLS
 
 draft-ietf-bess-evpn-vpls-seamless-integ-07.txt
 Date: 01/02/2019
 Authors: Ali Sajassi, Samer Salam, Nick Regno, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document specifies mechanisms for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB- EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions. It also provides mechanisms for seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this document enables service providers to introduce EVPN/PBB-EVPN PEs in their brown-field deployments of VPLS/PBB-VPLS networks. This document specifies control-plane and forwarding behavior needed for auto-discovery of a VPN instance, multicast and unicast operation, as well as MAC-mobility operation in order to enable seamless integration between EVPN and VPLS PEs as well as between PBB-VPLS and PBB-EVPN PEs.
    
draft-ietf-bess-evpn-yang-07.txt
 Yang Data Model for EVPN
 
 draft-ietf-bess-evpn-yang-07.txt
 Date: 11/03/2019
 Authors: Patrice Brissette, Himanshu Shah, Iftekhar Hussain, Kishore Tiruveedhula, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes a YANG data model for Ethernet VPN services. The model is agnostic of the underlay. It apply to MPLS as well as to VxLAN encapsulation. The model is also agnostic of the services including E-LAN, E-LINE and E-TREE services. This document mainly focuses on EVPN and Ethernet-Segment instance framework.
    
draft-ietf-bess-l2vpn-yang-09.txt
 YANG Data Model for MPLS-based L2VPN
 
 draft-ietf-bess-l2vpn-yang-09.txt
 Date: 22/10/2018
 Authors: Himanshu Shah, Patrice Brissette, Ing-When Chen, Iftekhar Hussain, Bin Wen, Kishore Tiruveedhula
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes a YANG data model for Layer 2 VPN (L2VPN) services over MPLS networks. These services include point-to-point Virtual Private Wire Service (VPWS) and multipoint Virtual Private LAN service (VPLS) that uses LDP and BGP signaled Pseudowires. It is expected that this model will be used by the management tools run by the network operators in order to manage and monitor the network resources that they use to deliver L2VPN services. This document also describes the YANG data model for the Pseudowires. The independent definition of the Pseudowires facilitates its use in Ethernet Segment and EVPN data models defined in separate document.
    
draft-ietf-bess-l3vpn-yang-04.txt
 Yang Data Model for BGP/MPLS L3 VPNs
 
 draft-ietf-bess-l3vpn-yang-04.txt
 Date: 19/10/2018
 Authors: Dhanendra Jain, Keyur Patel, Patrice Brissette, Zhenbin Li, Shunwan Zhuang, Xufeng Liu, Jeffrey Haas, Santosh Esale, Bin Wen
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage BGP Layer 3 VPNs.
    
draft-ietf-bess-mvpn-evpn-aggregation-label-02.txt
 MVPN/EVPN Tunnel Aggregation with Common Labels
 
 draft-ietf-bess-mvpn-evpn-aggregation-label-02.txt
 Date: 18/12/2018
 Authors: Zhaohui Zhang, Eric Rosen, Wen Lin, Zhenbin Li, IJsbrand Wijnands
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The MVPN specifications allow a single Point-to-Multipoint (P2MP) tunnel to carry traffic of multiple VPNs. The EVPN specifications allow a single P2MP tunnel to carry traffic of multiple Broadcast Domains (BDs). These features require the ingress router of the P2MP tunnel to allocate an upstream-assigned MPLS label for each VPN or for each BD. A packet sent on a P2MP tunnel then carries the label that is mapped to its VPN or BD. (In some cases, a distinct upstream-assigned is needed for each flow.) Since each ingress router allocates labels independently, with no coordination among the ingress routers, the egress routers may need to keep track of a large number of labels. The number of labels may need to be as large (or larger) than the product of the number of ingress routers times the number of VPNs or BDs. However, the number of labels can be greatly reduced if the association between a label and a VPN or BD is made by provisioning, so that all ingress routers assign the same label to a particular VPN or BD. New procedures are needed in order to take advantage of such provisioned labels. These new procedures also apply to Multipoint-to-Multipoint (MP2MP) tunnels. This document updates RFCs 6514, 7432 and 7582 by specifying the necessary procedures.
    
draft-ietf-bess-mvpn-fast-failover-05.txt
 Multicast VPN fast upstream failover
 
 draft-ietf-bess-mvpn-fast-failover-05.txt
 Date: 14/02/2019
 Authors: Thomas Morin, Robert Kebler, Gregory Mirsky
 Working Group: BGP Enabled ServiceS (bess)
 Formats: xml txt
This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a standby upstream PE.
    
draft-ietf-bess-mvpn-msdp-sa-interoperation-02.txt
 MVPN and MSDP SA Interoperation
 
 draft-ietf-bess-mvpn-msdp-sa-interoperation-02.txt
 Date: 28/01/2019
 Authors: Zhaohui Zhang, Leonard Giuliano
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document specifies the procedures for interoperation between MVPN Source Active routes and customer MSDP Source Active routes, which is useful for MVPN provider networks offering services to customers with an existing MSDP infrastructure. Without the procedures described in this document, VPN-specific MSDP sessions are required among the PEs that are customer MSDP peers.
    
draft-ietf-bess-mvpn-yang-01.txt
 Yang Data Model for Multicast in MPLS/BGP IP VPNs
 
 draft-ietf-bess-mvpn-yang-01.txt
 Date: 05/03/2019
 Authors: Yisong Liu, Feng Guo, Stephane Litkowski, Xufeng Liu, Robert Kebler, Mahesh Sivakumar
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage multicast in MPLS/BGP IP VPNs.
    
draft-ietf-bess-nsh-bgp-control-plane-09.txt
 BGP Control Plane for NSH SFC
 
 draft-ietf-bess-nsh-bgp-control-plane-09.txt
 Date: 06/03/2019
 Authors: Adrian Farrel, John Drake, Eric Rosen, Jim Uttaro, Luay Jalil
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt xml
This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC AFI/SAFI with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header defined in RFC 8300. This document adopts the SFC architecture described in RFC 7665.
    
draft-ietf-bess-service-chaining-06.txt
 Service Function Chaining using Virtual Networks with BGP VPNs
 
 draft-ietf-bess-service-chaining-06.txt
 Date: 04/12/2018
 Authors: Rex Fernando, Stuart Mackie, Dhananjaya Rao, Bruno Rijsman, Maria Napierala, Thomas Morin
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt xml
This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain.
    
draft-ietf-bess-vpls-multihoming-03.txt
 BGP based Multi-homing in Virtual Private LAN Service
 
 draft-ietf-bess-vpls-multihoming-03.txt
 Date: 26/03/2019
 Authors: Bhupesh Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, Jim Uttaro
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions.
    
draft-ietf-bfcpbis-bfcp-websocket-15.txt
 The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)
 
 draft-ietf-bfcpbis-bfcp-websocket-15.txt
 Date: 08/02/2017
 Authors: Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo Salgueiro, Ram R
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies the use of Binary Floor Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliable transport mechanism between BFCP entities in new scenarios.
    
draft-ietf-bfcpbis-rfc4582bis-16.txt
 The Binary Floor Control Protocol (BFCP)
 
 draft-ietf-bfcpbis-rfc4582bis-16.txt
 Date: 13/11/2015
 Authors: Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16.
    
draft-ietf-bfcpbis-rfc4583bis-27.txt
 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
 
 draft-ietf-bfcpbis-rfc4583bis-27.txt
 Date: 08/12/2018
 Authors: Gonzalo Camarillo, Tom Kristensen, Christer Holmberg
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: xml txt
This document defines the Session Description Protocol (SDP) offer/ answer procedures for negotiating and establishing Binary Floor Control Protocol (BFCP) streams. This document obsoletes RFC 4583. Changes from RFC 4583 are summarized in Section 14.
    
draft-ietf-bfd-large-packets-00.txt
 BFD Encapsulated in Large Packets
 
 draft-ietf-bfd-large-packets-00.txt
 Date: 26/02/2019
 Authors: Jeffrey Haas, Albert Fu
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: xml txt
The Bidirectional Forwarding Detection (BFD) protocol is commonly used to verify connectivity between two systems. BFD packets are typically very small. It is desirable in some circumstances to know that not only is the path between two systems reachable, but also that it is capable of carrying a payload of a particular size. This document discusses thoughts on how to implement such a mechanism using BFD in Asynchronous mode.
    
draft-ietf-bfd-optimizing-authentication-07.txt
 Optimizing BFD Authentication
 
 draft-ietf-bfd-optimizing-authentication-07.txt
 Date: 08/11/2018
 Authors: Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC5880.
    
draft-ietf-bfd-secure-sequence-numbers-03.txt
 Secure BFD Sequence Numbers
 
 draft-ietf-bfd-secure-sequence-numbers-03.txt
 Date: 19/02/2019
 Authors: Mahesh Jethanandani, Sonal Agarwal, Ashesh Mishra, Ankur Saxena, Alan DeKok
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document describes a security enhancements for the BFD packet's sequence number.
    
draft-ietf-bfd-stability-03.txt
 BFD Stability
 
 draft-ietf-bfd-stability-03.txt
 Date: 21/02/2019
 Authors: Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Juniper Networks, Mach Chen, Peng Fan
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: pdf 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-ietf-bfd-unsolicited-00.txt
 Unsolicited BFD for Sessionless Applications
 
 draft-ietf-bfd-unsolicited-00.txt
 Date: 26/02/2019
 Authors: Enke Chen, Naiming Shen, Robert Raszuk, Reshad Rahman
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt
For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies).
    
draft-ietf-bfd-vxlan-06.txt
 BFD for VXLAN
 
 draft-ietf-bfd-vxlan-06.txt
 Date: 26/12/2018
 Authors: Juniper Networks, Sudarsan Paragiri, Vengada Govindan, Mallik Mudigonda, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay networks.
    
draft-ietf-bfd-yang-17.txt
 YANG Data Model for Bidirectional Forwarding Detection (BFD)
 
 draft-ietf-bfd-yang-17.txt
 Date: 02/08/2018
 Authors: Reshad Rahman, Lianshu Zheng, Mahesh Jethanandani, Juniper Networks, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).
    
draft-ietf-bier-bar-ipa-03.txt
 BIER Underlay Path Calculation Algorithm and Constraints
 
 draft-ietf-bier-bar-ipa-03.txt
 Date: 16/11/2018
 Authors: Zhaohui Zhang, Tony Przygienda, Andrew Dolganow, Hooman Bidgoli, IJsbrand Wijnands, Arkadiy Gulko
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
This document specifies general rules for interaction between the BAR (BIER Algorithm) and IPA (IGP Algorithm) fields defined in ISIS/ OSPFv2 Extensions for BIER.
    
draft-ietf-bier-entropy-staged-dc-clos-00.txt
 Use of BIER Entropy for Data Center CLOS Networks
 
 draft-ietf-bier-entropy-staged-dc-clos-00.txt
 Date: 05/11/2018
 Authors: Jingrong Xie, Xiaohu Xu, Gang Yan, Mike McBride
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) introduces a new multicast- specific BIER Header. BIER can be applied to the Multi Protocol Label Switching (MPLS) data plane or Non-MPLS data plane. Entropy is a technique used in BIER to support load-balancing. This document examines and describes how BIER Entropy is to be applied to Data Center CLOS networks for path selection.
    
draft-ietf-bier-idr-extensions-06.txt
 BGP Extensions for BIER
 
 draft-ietf-bier-idr-extensions-06.txt
 Date: 23/01/2019
 Authors: Xiaohu Xu, Mach Chen, Keyur Patel, IJsbrand Wijnands, Tony Przygienda
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
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-mtud-00.txt
 BIER MTU Discovery
  </
 draft-ietf-bier-mtud-00.txt
 Date: 27/02/2019
 Authors: Stig Venaas, IJsbrand Wijnands, Les Ginsberg, Mahesh Sivakumar
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt