Internet Drafts - Sorted by name


    
draft-6tisch-enrollment-enhanced-beacon-00.txt
 IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information
 
 draft-6tisch-enrollment-enhanced-beacon-00.txt
 Date: 16/07/2018
 Authors: Diego Dujovne, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml
In TSCH mode of IEEE802.15.4, as described by [RFC8180], opportunities for broadcasts are limited to specific times and specific channels. Nodes in a TSCH network typically frequently send Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which small details critical for new nodes (pledges) and long sleeping nodes may be carried within the Enhanced Beacon.
    
draft-abr-twitter-reply-00.txt
 A reply to a specific tweet
 
 draft-abr-twitter-reply-00.txt
 Date: 07/09/2018
 Authors: Adam Roach
 Working Group: Individual Submissions (none)
 Formats: txt
This document is a response to a tweet. It is of very limited interest.
    
draft-accilent-at-sign-00.txt
 Clarification of Proper Use of "@" (at sign) in URI-style Components
 
 draft-accilent-at-sign-00.txt
 Date: 30/07/2010
 Authors: Robert Simpson
 Working Group: Individual Submissions (none)
 Formats: xml txt
Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses.
    
draft-acee-idr-lldp-peer-discovery-03.txt
 BGP Logical Link Discovery Protocol (LLDP) Peer Discovery
 
 draft-acee-idr-lldp-peer-discovery-03.txt
 Date: 30/06/2018
 Authors: Acee Lindem, Keyur Patel, Shawn Zandi, Jeffrey Haas, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: txt
Link Layer Discovery Protocol (LLDP) or IEEE 802.1AB is implemented in networking equipment from many vendors. It is natural for IETF protocols to avail this protocol for simple discovery tasks. This document describes how BGP would use LLDP to discover directly connected and 2-hop peers when peering is based on loopback addresses.
    
draft-acee-lsr-ospf-admin-tags-00.txt
 Extensions to OSPF for Advertising Prefix/Link Administrative Tags
 
 draft-acee-lsr-ospf-admin-tags-00.txt
 Date: 23/07/2018
 Authors: Acee Lindem, Peter Psenak
 Working Group: Individual Submissions (none)
 Formats: txt
It is useful for routers in an OSPFv2 or OSPFv3 routing domain to be able to associate tags with prefixes and links. Previously, OSPFv2 and OSPFv3 were relegated to a single tag for AS External and Not-So- Stubby-Area (NSSA) prefixes. With the flexible encodings provided by OSPFv2 Prefix/Link Attribute Advertisement and OSPFv3 Extended LSAs, multiple administrative tags may advertised for all types of prefixes and links. These administrative tags can be used for many applications including route redistribution policy, selective prefix prioritization, selective IP Fast-ReRoute (IPFRR) prefix protection, and many others. The ISIS protocol supports a similar mechanism that is described in RFC 5130.
    
draft-acee-lsr-ospfv3-extended-lsa-yang-00.txt
 Yang Model for OSPFv3 Extended LSAs
 
 draft-acee-lsr-ospfv3-extended-lsa-yang-00.txt
 Date: 27/06/2018
 Authors: Acee Lindem, Sharmila Palani
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model augmenting the IETF OSPF YANG model to provide support for OSPFv3 Link State Advertisment (LSA) Extensibility as defined in RFC 8263. OSPFv3 Extended LSAs provide extensible TLV-based LSAs for the base LSA types defined in RFC 5340.
    
draft-acee-rtgwg-yang-rib-extend-08.txt
 RIB YANG Data Model
 
 draft-acee-rtgwg-yang-rib-extend-08.txt
 Date: 16/08/2018
 Authors: Acee Lindem, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
The Routing Information Base (RIB) is a list of routes and their corresponding administrative data and operational state. RFC 8349 defines the basic building blocks for RIB, and this model augments it to support multiple next-hops (aka, paths) for each route as well as additional attributes.
    
draft-acg-mboned-deprecate-interdomain-asm-02.txt
 Deprecating ASM for Interdomain Multicast
 
 draft-acg-mboned-deprecate-interdomain-asm-02.txt
 Date: 02/07/2018
 Authors: Mikael Abrahamsson, Tim Chown, Leonard Giuliano, Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document recommends deprecation of the use of Any-Source Multicast (ASM) for interdomain multicast. It recommends the use of Source-Specific Multicast (SSM) for interdomain multicast applications, and that hosts and routers that are expected to handle such applications fully support SSM. The recommendations in this document do not preclude the continued use of ASM within a single organisation or domain, and are especially easy to adopt when already using the preferred ASM protocol options there (PIM-SM).
    
draft-alavarez-hamelin-tictoc-sic-01.txt
 Synchronizing Internet Clock frequency protocol (sic)
 
 draft-alavarez-hamelin-tictoc-sic-01.txt
 Date: 29/06/2018
 Authors: Jose Alvarez-Hamelin, David Samaniego, Alfredo Ortega, Ruediger Geib
 Working Group: Individual Submissions (none)
 Formats: txt xml
Synchronizing Internet Clock Frequency specifies a new secure method to synchronize difference clocks on the Internet, assuring smoothness (i.e., frequency stability) and robustness to man-in-the-middle attacks. In 90% of all cases, Synchronized Internet Clock Frequency is highly accurate, with a Maximum Time Interval Error less than 25 microseconds by a minute. Synchronized Internet Clock Frequency is based on a regular packet exchange and works with commodity terminal hardware.
    
draft-ali-spring-network-slicing-building-blocks-00.txt
 Building blocks for Slicing in Segment Routing Network
 
 draft-ali-spring-network-slicing-building-blocks-00.txt
 Date: 02/07/2018
 Authors: Zafar Ali, Clarence Filsfils, Pablo Camarillo
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how to build network slice using the Segment Routing based technology. It explains how the existing building blocks specified for the Segment Routing can be used for this purpose.
    
draft-ali-spring-sr-traffic-accounting-02.txt
 Traffic Accounting in Segment Routing Networks
 
 draft-ali-spring-sr-traffic-accounting-02.txt
 Date: 07/06/2018
 Authors: Zafar Ali, Clarence Filsfils, Ketan Talaulikar, Siva Sivabalan, Martin Horneffer, Robert Raszuk, Stephane Litkowski, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
Capacity planning is the continuous art of forecasting traffic load and failures to evolve the network topology, its capacity, and its routing to meet a defined Service-Level Agreement (SLA). This document takes a holistic view of network capacity planning and identifies the role of traffic accounting in network operation and capacity planning, without creating any additional states in the SR fabric.
    
draft-ali-spring-srv6-oam-01.txt
 Operations,Administration,and Maintenance (OAM) in Segment Routing Networks with IPv6 Data plane (SRv6)
 
 draft-ali-spring-srv6-oam-01.txt
 Date: 02/07/2018
 Authors: Zafar Ali, Clarence Filsfils, Nagendra Kumar, Carlos Pignataro, faiqbal@cisco.com, Rakesh Gandhi, John Leddy, Satoru Matsushima, Robert Raszuk, daniel.voyer@bell.ca, Gaurav Dawra, Bart Peirens, Mach Chen, Gaurav Naik
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines building blocks that can be used for Operations, Administration, and Maintenance (OAM) in Segment Routing Networks with IPv6 Dataplane (SRv6). The document also describes some SRv6 OAM mechanisms that can be realized using these building blocks.
    
draft-allan-pim-sr-mpls-multicast-framework-00.txt
 A Framework for Computed Multicast Applied to SR-MPLS
 
 draft-allan-pim-sr-mpls-multicast-framework-00.txt
 Date: 01/06/2018
 Authors: Dave Allan, Jeff Tantsura, Ian Duncan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a multicast solution for SR-MPLS. It is consistent with the Segment Routing architecture in that an IGP is augmented to distribute information in addition to the link state. In this solution it is multicast group membership information sufficient to synchronize state in a given network domain. Computation is employed to determine the topology of any loosely specified multicast distribution tree.
    
draft-an-savi-mib-15.txt
 Definition of Managed Objects for SAVI Protocol
 
 draft-an-savi-mib-15.txt
 Date: 18/07/2018
 Authors: Changqing An, Jiahai Yang, Jianping Wu, Jun Bi
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing SAVI (Source Address Validation Improvements) protocol instance.
    
draft-an-savi-yang-04.txt
 A Yang Data Model for SAVI Management
 
 draft-an-savi-yang-04.txt
 Date: 10/08/2018
 Authors: Changqing An, Jiahai Yang, Jianping Wu, Jun Bi
 Working Group: Individual Submissions (none)
 Formats: txt
This document contains a specification of YANG modules for the management of SAVI (Source Address Validation Improvements) protocol. The core SAVI data module ietf-savi serves as a framework for configuring and managing SAVI instance and provides common building blocks. It is expected to be augmented by additional YANG modules for specific IP address assignment methods. The other four modules augment the core SAVI data module and define data models for different IP address assignment methods. Module ietf-savi-fcfs defines module specific for Stateless Address Auto Configuration (SLAAC), module ietf-savi-dhcpv4 and ietf-savi-dhcpv6 define modules specific for Dynamic Host Configuration Protocol version 4 and version 6 (DHCPv4 and DHCPv6), and module ietf-savi- send defines module specific for Secure Neighbor Discovery (SEND).
    
draft-anand-ippm-po-ioam-01.txt
 Integrated Packet-Optical In-Situ OAM
 
 draft-anand-ippm-po-ioam-01.txt
 Date: 21/08/2018
 Authors: Madhukar Anand, Sanjoy Bardhan, Radha Valiveti, Ramesh Subrahmaniam, Carlos Pignataro, Shwetha Bhandari, Randy Zhang, Rajiv Asati
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a way to extend in-situ OAM techniques to include operational data from multiple network layers with a view to create an integrated record of OAM information as the data flows between two network entities. An instance of this technique that is elaborated here focuses on packet-optical networks that are traditionally transport centric. The mechanisms described are general enough to allow future extensibility of in-situ OAM techniques into other non-packet domains.
    
draft-anand-spring-poi-sr-06.txt
 Packet-Optical Integration in Segment Routing
 
 draft-anand-spring-poi-sr-06.txt
 Date: 30/07/2018
 Authors: Madhukar Anand, Sanjoy Bardhan, Ramesh Subrahmaniam, Jeff Tantsura, Utpal Mukhopadhyaya, Clarence Filsfils
 Working Group: Individual Submissions (none)
 Formats: txt
This document illustrates a way to integrate a new class of nodes and links in segment routing to represent transport networks in an opaque way into the segment routing domain. An instance of this class would be optical networks that are typically transport centric. In the IP centric network, this will help in defining a common control protocol for packet optical integration that will include optical paths as 'transport segments' or sub-paths as an augmentation to packet paths. The transport segment option also defines a general mechanism to allow for future extensibility of segment routing into non-packet domains.
    
draft-andersdotter-intarea-update-to-rfc6302-00.txt
 An update to RFC6302 on Logging Recommendations for Internet-Facing Servers
 
 draft-andersdotter-intarea-update-to-rfc6302-00.txt
 Date: 22/04/2018
 Authors: Amelia Andersdotter
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft seeks to update RFC6302 on Logging Recommendations for Internet-Facing Servers. The new recommendations aim to be a best practice for service providers and server maintainers, by following recommendations outlined in RFC6973 and taking into account new regulatory requirements in the privacy area.
    
draft-andersen-historic-4406-etal-01.txt
 Status Change for RFCs 4405,4406,4407 to Historic
 
 draft-andersen-historic-4406-etal-01.txt
 Date: 24/03/2018
 Authors: Kurt Andersen
 Working Group: Applications and Real-Time Area (art)
 Formats: xml txt
This document acknowledges that Sender ID did not pass its experiment, and changes the status of RFCs 4405 [RFC4405], 4406 [RFC4406], and 4407 [RFC4407] to Historic.
    
draft-anilj-icnrg-icn-qos-00.txt
 Supporting QoS aware Data Delivery in Information Centric Networks
 
 draft-anilj-icnrg-icn-qos-00.txt
 Date: 14/07/2018
 Authors: Anil Jangam, Prakash suthar, Milan Stolic
 Working Group: Individual Submissions (none)
 Formats: txt
Information Centric Networking (ICN) is shaping up as an alternative networking mechanism for the TCP/IP based host-centric networking paradigm. Content delivery or streaming is one of important use cases where the real value and potential of ICN architecture is being investigated. While a number of studies on an optimal and efficient routing of Interest requests have been published, more discussion is needed on the mechanisms for implementation and enforcement of the quality of service (QoS) in the ICN based data delivery path. In this document, we focus on two most popular ICN architectures, CCN (Content Centric Networking) and NDN (Named Data Networking) and describe how we can achieve the QoS aware data delivery in the ICN network. We propose to use the differentiated services (DiffServ) QoS model based on DSCP codes, which is also used in the IP based Internet design. We further present how QoS parameter syntax can be added to the current CCNx messages.
    
draft-annee-dprive-oblivious-dns-00.txt
 Oblivious DNS - Strong Privacy for DNS Queries
 
 draft-annee-dprive-oblivious-dns-00.txt
 Date: 02/07/2018
 Authors: Annie Edmundson, Paul Schmitt, Nick Feamster, Allison Mankin
 Working Group: Individual Submissions (none)
 Formats: txt
Recognizing the privacy vulnerabilities associated with DNS queries, a number of standards have been developed and services deployed that that encrypt a user's DNS queries to the recursive resolver and thus obscure them from some network observers and from the user's Internet service provider. However, these systems merely transfer trust to a third party. We argue that no single party should be able to associate DNS queries with a client IP address that issues those queries. To this end, this document specifies Oblivious DNS (ODNS), which introduces an additional layer of obfuscation between clients and their queries. To accomplish this, ODNS uses its own authoritative namespace; the authoritative servers for the ODNS namespace act as recursive resolvers for the DNS queries that they receive, but they never see the IP addresses for the clients that initiated these queries. The ODNS experimental protocol is compatible with existing DNS infrastructure.
    
draft-annu-t2trg-ike-for-wsn-security-00.txt
 ike for wsn security
 
 draft-annu-t2trg-ike-for-wsn-security-00.txt
 Date: 03/08/2018
 Authors: annusin@cisco.com, karan.verma.phd@gmail.com
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an internet key exchange(ike) protocol for wireless sensor network.IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations.This document preassumed that readers are familier with basic concept of sensor network.
    
draft-aranda-dispatch-q4s-06.txt
 The Quality for Service Protocol
 
 draft-aranda-dispatch-q4s-06.txt
 Date: 15/07/2018
 Authors: Jose Garcia, Monica Cortes, Joaquin Salvachua, Tecnalia Innovation, Inaki Sarriegui
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This memo describes an application level protocol for the standard communication of e2e QoS compliance information using a protocol based on Hypertext Transfer Protocol (HTTP), which forms the basis for the World Wide Web, and Session Description Protocol (SDP). Quality for Service Protocol (Q4S) provides a mechanism for latency, jitter, bandwidth and packet loss negotiation and monitoring, alerting whenever one of the negotiated conditions is violated. Implementation details on the actions to be triggered upon reception/detection of QoS alerts exchanged by the protocol are out of scope of this draft, it is application dependent (e.g. increase quality, reduce bit-rate) or even network dependent (e.g. change connection's quality profile).
    
draft-aranda-nfvrg-recursive-vnf-06.txt
 High-level VNF Descriptors using NEMO
 
 draft-aranda-nfvrg-recursive-vnf-06.txt
 Date: 21/08/2018
 Authors: Pedro Gutierrez, Diego Lopez, Stefano Salsano, Elena Batanero
 Working Group: Individual Submissions (none)
 Formats: txt xml
Current efforts in the scope of Network Function Virtualisation(NFV) propose YAML-based descriptors for Virtual Network Functions (VNFs) and for their composition in Network Services (NS) These descriptors are human-readable but hardly understandable by humans. On the other hand, there has been an effort proposed to the IETF to define a human-readable (and understandable) representation for networks, known as NEMO. In this draft, we propose a simple extension to NEMO to accommodate VNF Descriptors (VNFDs) in a similar manner as inline assembly is integrated in higher-level programming languages. This approach enables the creation of recursive VNF forwarding graphs in Service Descriptors, practically making them recursive. An implementation generating VNF Descriptors (VNFDs) for OpenMANO and OSM is available.
    
draft-arciszewski-xchacha-00.txt
 XChaCha: eXtended-nonce ChaCha and AEAD_XChaCha20_Poly1305
 
 draft-arciszewski-xchacha-00.txt
 Date: 07/09/2018
 Authors: Scott Arciszewski
 Working Group: Individual Submissions (none)
 Formats: txt xml
The eXtended-nonce ChaCha cipher construction (XChaCha) allows for ChaCha-based ciphersuites to accept a 192-bit nonce with similar guarantees to the original construction, except with a much lower probability of nonce misuse occurring. This enables XChaCha constructions to be stateless, while retaining the same security assumptions as ChaCha. This document defines XChaCha20, which uses HChaCha20 to convert the key and part of the nonce into a subkey, which is in turn used with the remainder of the nonce with ChaCha20 to generate a pseudorandom keystream (e.g. for message encryption). This document also defines AEAD_XChaCha20_Poly1305, a variant of [RFC7539] that utilizes the XChaCha20 construction in place of ChaCha20.
    
draft-arias-noguchi-dnrd-objects-mapping-09.txt
 Domain Name Registration Data (DNRD) Objects Mapping
 
 draft-arias-noguchi-dnrd-objects-mapping-09.txt
 Date: 28/06/2018
 Authors: Gustavo Lozano, James Gould, Chethan Thippeswamy
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the format, contents and semantics of Domain Name Registration Data (DNRD) Escrow deposits for a Domain Name Registry.
    
draft-arias-noguchi-registry-data-escrow-10.txt
 Registry Data Escrow Specification
 
 draft-arias-noguchi-registry-data-escrow-10.txt
 Date: 28/06/2018
 Authors: Gustavo Lozano
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the format and contents of data escrow deposits targeted primarily for domain name registries. However, the specification was designed to be independent of the underlying objects that are being escrowed, therefore it could be used for purposes other than domain name registries.
    
draft-arkko-eap-aka-pfs-02.txt
 Perfect-Forward Secrecy for the Extensible Authentication Protocol Method for Authentication and Key Agreement (EAP-AKA' PFS)
 
 draft-arkko-eap-aka-pfs-02.txt
 Date: 02/07/2018
 Authors: Jari Arkko, Karl Norrman, Vesa Torvinen
 Working Group: Individual Submissions (none)
 Formats: txt
Many different attacks have been reported as part of revelations associated with pervasive surveillance. Some of the reported attacks involved compromising smart cards, such as attacking SIM card manufacturers and operators in an effort to compromise shared secrets stored on these cards. Since the publication of those reports, manufacturing and provisioning processes have gained much scrutiny and have improved. However, the danger of resourceful attackers for these systems is still a concern. This specification is an optional extension to the EAP-AKA' authentication method which was defined in RFC 5448. The extension provides Perfect Forward Secrecy for the session key generated as a part of the authentication run in EAP-AKA'. This prevents an attacker who has gained access to the long-term pre-shared secret in a SIM card from merely passively eavesdropping the EAP-AKA' exchanges and deriving associated session keys, forcing attackers to use active attacks instead.
    
draft-arkko-trip-registry-update-00.txt
 Update to the TRIP IANA Registry Rules Regarding Postal Addresses
 
 draft-arkko-trip-registry-update-00.txt
 Date: 18/07/2018
 Authors: Jari Arkko, Ted Hardie
 Working Group: Individual Submissions (none)
 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-asaeda-icnrg-ccninfo-01.txt
 CCNinfo: Discovering Content and Network Information in Content-Centric Networks
 
 draft-asaeda-icnrg-ccninfo-01.txt
 Date: 30/06/2018
 Authors: Hitoshi Asaeda, Xun Shao
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a mechanism named "CCNinfo" that discovers information about the network topology and in-network cache in Content-Centric Networks (CCN). CCNinfo investigates: 1) the CCN routing path information per name prefix, device name, and function/ application, 2) the Round-Trip Time (RTT) between content forwarder and consumer, and 3) the states of in-network cache per name prefix. In addition, it discovers a gateway that supports different protocols such as CCN and Named-Data Networks (NDN).
    
draft-asciirfc-minimal-02.txt
 A Minimal Internet-Draft In AsciiRFC
 
 draft-asciirfc-minimal-02.txt
 Date: 12/04/2018
 Authors: Josiah Carberry, Truman Grayson
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides a template on how to author (or migrate!) a new Internet-Draft / RFC in the AsciiRFC format. This template requires usage of the "asciidoctor-rfc" Ruby gem.
    
draft-asechoud-rtgwg-qos-model-07.txt
 YANG Model for QoS
 
 draft-asechoud-rtgwg-qos-model-07.txt
 Date: 14/07/2018
 Authors: Aseem Choudhary, Mahesh Jethanandani, Norm Strahle, Ebben Aries, Ing-Wher Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG model for Quality of Service (QoS) configuration and operational parameters.
    
draft-asechoud-rtgwg-qos-oper-model-02.txt
 YANG Model for QoS Operational Parameters
 
 draft-asechoud-rtgwg-qos-oper-model-02.txt
 Date: 02/07/2018
 Authors: Aseem Choudhary, Ing-Wher Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG model for Quality of Service (QoS) operational parameters.
    
draft-asechoud-rtgwg-qos-telemetry-req-00.txt
 QoS Telemetry Requirements
 
 draft-asechoud-rtgwg-qos-telemetry-req-00.txt
 Date: 12/05/2018
 Authors: Aseem Choudhary
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses QoS requirements for data model based network telemetry. QoS configuration and operational models have been defined as part of [I-D.asechoud-rtgwg-qos-model] and [I-D.asechoud-rtgwg-qos-oper-model] respectively. This document describes the requirement to extend the models to support QoS Telemetry.
    
draft-asmithee-tls-dnssec-downprot-00.txt
 TLS Downgrade protection extension for TLS DNSSEC Authentication Chain Extension
 
 draft-asmithee-tls-dnssec-downprot-00.txt
 Date: 15/05/2018
 Authors: Paul Wouters, Viktor Dukhovni
 Working Group: Individual Submissions (none)
 Formats: txt xml
This draft specifies a TLS extension that adds downgrade protection for another TLS extension, [dnssec-chain-extension]. Without the downgrade protection specified in this TLS extension, the only effect of deploying [dnssec-chain-extension] is to reduce TLS security from the standard "WebPKI security" to "WebPKI or DANE, whichever is weaker". This draft dictates that [dnssec-chain-extension] MUST only be used in combination with this TLS extension, whose only content is a two octet SupportLifetime value. A value of 0 prohibits the TLS client from unilaterally requiring ongoing use of both TLS extensions based on prior observation of their use (pinning). A non-zero value is the value in hours for which this TLS extension as well as [dnssec-chain-extension] MUST appear in subsequent TLS handshakes to the same TLS hostname and port. If this TLS extention or [dnssec-chain-extension] is missing from the TLS handshake within this observed pinning time, the TLS client MUST assume it is under attack and abort the TLS connection.
    
draft-asveren-dispatch-http-overload-control-00.txt
 HTTP Overload Control Mechanism
 
 draft-asveren-dispatch-http-overload-control-00.txt
 Date: 14/04/2018
 Authors: Tolga Asveren
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a generic overload control mechanism for HTTP/HTTPS applications.
    
draft-asveren-stir-p-charge-info-00.txt
 PASSPorT Extension for P-Charge-Info Header
 
 draft-asveren-stir-p-charge-info-00.txt
 Date: 08/05/2018
 Authors: Tolga Asveren
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document extends the PASSporT (Personal Assertion Token) specification defined in [RFC8225] to allow the inclusion of cryptographically signed assertions of authorization for the values populated in the 'Session Initiation Protocol (SIP) P-Charge-Info' header, which is used for conveying information about the entity to be charged for a particular real time session.
    
draft-auge-dmm-hicn-mobility-00.txt
 Anchorless mobility through hICN
 
 draft-auge-dmm-hicn-mobility-00.txt
 Date: 20/06/2018
 Authors: Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents how mobility management is handled in Hybrid- ICN [I-D.muscariello-intarea-hicn]. The objective of the document is to present how end-points mobility is managed in two main cases: the end-point sends data (data producer ) or the end-point receive data (data consumer). These two cases are taken into account entirely to provide anchorless mobility management in hICN.
    
draft-auge-dmm-hicn-mobility-deployment-options-00.txt
 Anchorless mobility management through hICN (hICN-AMM): Deployment options
 
 draft-auge-dmm-hicn-mobility-deployment-options-00.txt
 Date: 19/06/2018
 Authors: Jordan Auge, Giovanna Carofiglio, Luca Muscariello, Michele Papalini
 Working Group: Individual Submissions (none)
 Formats: txt
A novel mobility management approach is described in [I-D.auge-dmm-hicn-mobility], that leverages routable location- independent identifiers (IDs) and an Information-Centric Networking (ICN) communication model integrated in IPv6, (also referred to as Hybrid ICN, hICN, [I-D.muscariello-intarea-hicn]. Such approach belongs to the category of pure ID-based mobility management schemes whose objective is (i) to overcome the limitations of traditional locator-based solutions like Mobile IP, (ii) to remove the need for a global mapping system as the one required by locator- identifier separation solutions like LISP [I-D.ietf-lisp-introduction] or ILA [I-D.herbert-intarea-ila]. ID-based networking as proposed by ICN architectures allows to disentangle forwarding operations from changes of network location, hence removing tunnels and user plane or control plane anchors. In virtue of its anchorless property, we denote this approach as hICN- AMM (hICN Anchorless Mobility Management) hereinafter. This document discusses hICN-AMM deployment options and related tradeoffs in terms of cost/benefits. Particular attention is devoted to the insertion in the recently proposed 5G Service Based Architecture under study at 3GPP where an hICN-AMM solution might present a more efficient alternative to the traditional tunnel-based mobility architecture through GTP-U.
    
draft-aura-eap-noob-03.txt
 Nimble out-of-band authentication for EAP (EAP-NOOB)
 
 draft-aura-eap-noob-03.txt
 Date: 02/07/2018
 Authors: Tuomas Aura, Mohit Sethi
 Working Group: Individual Submissions (none)
 Formats: txt xml
Extensible Authentication Protocol (EAP) provides support for multiple authentication methods. This document defines the EAP-NOOB authentication method for nimble out-of-band (OOB) authentication and key derivation. This EAP method is intended for bootstrapping all kinds of Internet-of-Things (IoT) devices that have a minimal user interface and no pre-configured authentication credentials. The method makes use of a user-assisted one-directional OOB channel between the peer device and authentication server.
    
draft-authors-lpwan-schc-802154-00.txt
 SCHC for 802.15.4 lpwan applications
 
 draft-authors-lpwan-schc-802154-00.txt
 Date: 16/07/2018
 Authors: Joerg Robert, Charles Perkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides guidelines for creating Rules for Static Context Header Compression for IEEE 802.15.4. Since 802.15.4 provides layer-2 acknowledgements, some complexities that were designed for more general systems can be avoided.
    
draft-ayers-low-power-interop-00.txt
 Design Considerations For Low Power Internet Protocols
 
 draft-ayers-low-power-interop-00.txt
 Date: 29/06/2018
 Authors: Hudson Ayers, Paul Crews, Hubert Teo, Conor McAvity, Amit Levy, Philip Levis
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses guidelines for specifying low-power Internet protocols in order to improve implementation interoperability. These guidelines are based around the importance of balancing memory usage and energy efficiency, and the importance of not relying on Postel's law when dealing with low resource devices. This document applies these guidelines to the IPv6 over low-power wireless personal area networks (6LoWPAN) Internet Standard, suggesting changes that would make it more likely for implementations to interoperate.
    
draft-azgin-icnrg-mobility-00.txt
 DMS: Dynamic Inter- and Intra-Domain Mobility Support Framework for Information Centric Networking
 
 draft-azgin-icnrg-mobility-00.txt
 Date: 02/07/2018
 Authors: Aytac Azgin, Ravi Ravindran
 Working Group: Individual Submissions (none)
 Formats: xml txt
The objective of this proposal is to introduce a mobility support framework for information centric networking (ICN) that is capable of supporting dynamic mobility scenarios associated with both consumer and producer applications, in a mobile device connected to a wireless LAN or WAN point of attachment (PoA). Due to rapidly evolving user trends that shift towards increased mobility and increased access to mobile content delivery (as both content producer and consumer), it is essential for an ICN architecture to offer active mobility support to end hosts, and present them with varying degrees of quality of experience. We enable this through the use of a network-driven mobility support architecture, which operates in a distributed and anchorless manner, and relies on late-binding and in--band signaling with the use of forwarding labels.
    
draft-azimov-sidrops-aspa-profile-00.txt
 A Profile for Autonomous System Provider Authorization
 
 draft-azimov-sidrops-aspa-profile-00.txt
 Date: 28/06/2018
 Authors: Alexander Azimov, Eugene Uskov, Randy Bush, Keyur Patel, Job Snijders, Russell Housley
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a standard profile for Autonomous System Provider Authorization in the Resource Public Key Infrastructure. An Autonomous System Provider Authorization is a digitally signed object that provides a means of verifying that a Customer Autonomous System holder has authorized a Provider Autonomous System to be its upstream provider and for the Provider to send prefixes received from the Customer Autonomous System in all directions including providers and peers.
    
draft-azimov-sidrops-aspa-verification-00.txt
 Verification of AS_PATH Using the Resource Certificate Public Key Infrastructure and Autonomous System Provider Authorization
 
 draft-azimov-sidrops-aspa-verification-00.txt
 Date: 28/06/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-00.txt
 Study Report on a Framework for Cloud Inter-connection toward the Realization of IoT
 
 draft-baba-iot-interconnection-00.txt
 Date: 02/07/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-05.txt
 Problems in and among industries for the prompt realization of IoT and safety considerations
 
 draft-baba-iot-problems-05.txt
 Date: 01/05/2018
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Koichi KUNITAKE, Kaoru Maeda
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document contains opinions gathered from enterprises engaging in the IoT business as stated in the preceding version hereof, and also examines the possibilities of new social problems in the IoT era. Recognition of the importance of information security has grown in step with the rising use of the Internet. Closer examination reveals that the IoT era may see a new direct physical threat to users. For instance, the situation at a smart house may lead it to judge that the owner has only temporarily stepped out, causing it to unlock the front door, which in turn makes it easier for thieves to enter. These kinds of scenarios may occur without identity fraud, hacking, and other means of compromising information security. Therefore, for the purpose of this document, this issue shall be referred to as "IoT Safety" to distinguish it from Information Security. We believe that it is necessary to deepen our understanding of these new IoT-related threats through discussion and ensure there are measures to address these threats in the future. At the same time, we must also coordinate these measures with the solutions to the problems described in the previous version of this document.
    
draft-baba-iot-webapi-03.txt
 Report on Problem Solving Experiment for Realization of Web-API-based IoT
 
 draft-baba-iot-webapi-03.txt
 Date: 01/05/2018
 Authors: Hiroyuki BABA, Yoshiki Ishida, Takayuki Amatsu, Hiroshi Masuda, Shintaro Ogura, Koichi KUNITAKE
 Working Group: Individual Submissions (none)
 Formats: xml txt
The University of Tokyo (UOT) is currently performing a demonstration experiment in COMMA House, the experimental smart-house owned by UOT and used as a connected house. The things installed in the house (Things) are operated using applications on smartphones and other devices. The various Things in the smart-house are operated online via a Web API that has been created as a prototype. This report is an overview of the experimental demonstration, which is gradually clarifying that Web API should be effective for solving issues for IoT.
    
draft-balarajah-bmwg-ngfw-performance-04.txt
 Benchmarking Methodology for Network Security Device Performance
 
 draft-balarajah-bmwg-ngfw-performance-04.txt
 Date: 02/07/2018
 Authors: Balamuhunthan Balarajah, Carsten Rossenhoevel
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides benchmarking terminology and methodology for next-generation network security devices including next-generation firewalls (NGFW), intrusion detection and prevention solutions (IDS/ IPS) and unified threat management (UTM) implementations. The document aims to strongly improve the applicability, reproducibility and transparency of benchmarks and to align the test methodology with today's increasingly complex layer 7 application use cases. The main areas covered in this document are test terminology, traffic profiles and benchmarking methodology for NGFWs to start with.
    
draft-baraq-roll-drizzle-00.txt
 Drizzle Algorithm
 
 draft-baraq-roll-drizzle-00.txt
 Date: 23/03/2018
 Authors: Baraq Ghaleb, Ahmed Al-Dubai, Imed Romdhani, Mamoun Qasem
 Working Group: Individual Submissions (none)
 Formats: txt
Trickle algorithm used in RPL routing protocol suffers from some issues related to power, network convergence time and overhead and load-distribution. To optimize this algorithm for Low-power and Lossy Networks (LLNs), a new algorithm called Drizzle is introduced. Drizzle uses an adaptive suppression mechanism that permits the nodes to have different transmission probabilities, which are consistent with their transmission history. Compared to Trickle, Drizzle removes the listen-only period from Drizzle's intervals, thus, leading to faster convergence time. Furthermore, a new policy for setting the redundancy coefficient has been used to mitigate the negative effect of the short-listen problem presented when removing the listen-only period and to further boost the fairness in the network.
    
draft-barkai-lisp-nfv-12.txt
 LISP Based FlowMapping for Scaling NFV
 
 draft-barkai-lisp-nfv-12.txt
 Date: 18/06/2018
 Authors: Sharon Barkai, Dino Farinacci, David Meyer, Fabio Maino, Vina Ermagan, Alberto Rodriguez-Natal, Albert Cabellos-Aparicio
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes an RFC 6830 Locator ID Separation Protocol (LISP) based distributed flow-mapping-fabric for dynamic scaling of virtualized network functions (NFV). Network functions such as subscriber-management, content-optimization, security and quality of service, are typically delivered using proprietary hardware appliances embedded into the network as turn-key service-nodes or service-blades within routers. Next generation network functions are being implemented as pure software instances running on standard servers - unbundled virtualized components of capacity and functionality. LISP-SDN based flow-mapping, dynamically assembles these components to whole solutions by steering the right traffic in the right sequence to the right virtual function instance.
    
draft-barnes-stir-passport-div-hi-callflows-01.txt
 Session Initiation Protocol (SIP) Call Flow Examples with PASSporT Diversion and History-Info
 
 draft-barnes-stir-passport-div-hi-callflows-01.txt
 Date: 02/07/2018
 Authors: Mary Barnes
 Working Group: Individual Submissions (none)
 Formats: txt
This document focuses on use cases and call flows which include the History-Info header field and a SIP Identity header field with a PASSport with a "div" claim in cases of retargeting. These use cases are derived from those provided in the SIP History-Info call flows document. The objective is to describe the optimal way to correlate the History-Info header fields with a PASSporT with diversion information to increase the level of confidence in the History-Info header field by the terminating entity making use of the information.
    
draft-barnes-tls-pake-04.txt
 Usage of PAKE with TLS 1.3
 
 draft-barnes-tls-pake-04.txt
 Date: 16/07/2018
 Authors: Richard Barnes, Owen Friel
 Working Group: Individual Submissions (none)
 Formats: xml txt
The pre-shared key mechanism available in TLS 1.3 is not suitable for usage with low-entropy keys, such as passwords entered by users. This document describes an extension that enables the use of password-authenticated key exchange protocols with TLS 1.3.
    
draft-barre-mptcp-tfo-03.txt
 TFO support for Multipath TCP
 
 draft-barre-mptcp-tfo-03.txt
 Date: 29/05/2018
 Authors: Sebastien Barre, Gregory Detal, Olivier Bonaventure, Christoph Paasch
 Working Group: Individual Submissions (none)
 Formats: txt xml
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-00.txt
 PCEP extension to support Segment Routing Policy Candidate Paths
 
 draft-barth-pce-segment-routing-policy-cp-00.txt
 Date: 18/06/2018
 Authors: Colby Barth, Mike Koldychev, Dhruv Dhody, Siva Sivabalan
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a mechanism to specify an SR policy, as a collection of SR candidate paths. An SR policy is identified by tuple. An SR policy can be associated with one or more candidate paths where each candidate path is represented in PCEP by an LSP. 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 plane.
    
draft-bashandy-isis-srv6-extensions-03.txt
 IS-IS Extensions to Support Routing over IPv6 Dataplane
 
 draft-bashandy-isis-srv6-extensions-03.txt
 Date: 29/06/2018
 Authors: Les Ginsberg, Peter Psenak, Clarence Filsfils, Ahmed Bashandy, Bruno Decraene, Zhibo Hu
 Working Group: Individual Submissions (none)
 Formats: txt xml
Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological sub-paths, called "segments". Segment routing architecture can be implemented over an MPLS data plane as well as an IPv6 data plane. This draft describes the IS-IS extensions required to support Segment Routing over an IPv6 data plane.
    
draft-bashandy-rtgwg-segment-routing-ti-lfa-04.txt
 Topology Independent Fast Reroute using Segment Routing
 
 draft-bashandy-rtgwg-segment-routing-ti-lfa-04.txt
 Date: 02/04/2018
 Authors: Ahmed Bashandy, Clarence Filsfils, Bruno Decraene, Stephane Litkowski, Pierre Francois, daniel.voyer@bell.ca
 Working Group: Routing Area Working Group (rtgwg)
 Formats: txt
This document presents Topology Independent Loop-free Alternate Fast Re-route (TI-LFA), aimed at providing protection of node and adjacency segments within the Segment Routing (SR) framework. This Fast Re-route (FRR) behavior builds on proven IP-FRR concepts being LFAs, remote LFAs (RLFA), and remote LFAs with directed forwarding (DLFA). It extends these concepts to provide guaranteed coverage in any IGP network. A key aspect of TI-LFA is the FRR path selection approach establishing protection over post-convergence paths from the point of local repair, dramatically reducing the operational need to control the tie-breaks among various FRR options.
    
draft-bashandy-rtgwg-segment-routing-uloop-03.txt
 Loop avoidance using Segment Routing
 
 draft-bashandy-rtgwg-segment-routing-uloop-03.txt
 Date: 02/04/2018
 Authors: Ahmed Bashandy, Clarence Filsfils, Stephane Litkowski, Pierre Francois
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a mechanism aimed at providing loop avoidance in the case of IGP network convergence event. The solution relies on the temporary use of SR policies ensuring loop-freeness over the post-convergence paths from the converging node to the destination.
    
draft-bellis-dnsext-multi-qtypes-06.txt
 DNS Multiple QTYPEs
 
 draft-bellis-dnsext-multi-qtypes-06.txt
 Date: 02/07/2018
 Authors: Ray Bellis
 Working Group: Domain Name System Operations (dnsop)
 Formats: xml txt
This document specifies a method for a DNS client to request additional DNS record types to be delivered alongside the primary record type specified in the question section of a DNS query.
    
draft-belyavskiy-certificate-limitation-policy-06.txt
 Certificate Limitation Policy
 
 draft-belyavskiy-certificate-limitation-policy-06.txt
 Date: 28/05/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-benhadjsaid-detnet-gptp-yang-00.txt
 YANG Model of IEEE 802.1AS
 
 draft-benhadjsaid-detnet-gptp-yang-00.txt
 Date: 29/03/2018
 Authors: Siwar Sad, Michael Boc
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a YANG data model for the management of IEEE 802.1AS module in network devices. This data model includes configuration data and state data (status information and counters for the collection of statistics).
    
draft-berger-manet-dlep-ether-credit-extension-01.txt
 DLEP IEEE 802.1Q Aware Credit Window Extension
 
 draft-berger-manet-dlep-ether-credit-extension-01.txt
 Date: 02/08/2018
 Authors: David Wiggins, Lou Berger
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an extension to the DLEP protocol that enables a Ethernet IEEE 802.1Q aware credit-window scheme for destination- specific and shared flow control.
    
draft-bernardos-intarea-vim-discovery-00.txt
 IPv6-based discovery and association of Virtualization Infrastructure Manager (VIM) and Network Function Virtualization Orchestrator (NFVO)
 
 draft-bernardos-intarea-vim-discovery-00.txt
 Date: 22/08/2018
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Virtualized resources do not need to be limited to those available in traditional data centers, where the infrastructure is stable, static, typically homogeneous and managed by a single admin entity. Computational capabilities are becoming more and more ubiquitous, with terminal devices getting extremely powerful, as well as other types of devices that are close to the end users at the edge (e.g., vehicular onboard devices for infotainment, micro data centers deployed at the edge, etc.). It is envisioned that these devices would be able to offer storage, computing and networking resources to nearby network infrastructure, devices and things (the fog paradigm). These resources can be used to host functions, for example to offload/complement other resources available at traditional data centers, but also to reduce the end-to-end latency or to provide access to specialized information (e.g., context available at the edge) or hardware. This document describes mechanisms allowing dynamic discovery of virtualization resources and orchestrators in IPv6-based networks. New IPv6 neighbor discovery options are defined.
    
draft-bernardos-nfvrg-multidomain-05.txt
 Multi-domain Network Virtualization
 
 draft-bernardos-nfvrg-multidomain-05.txt
 Date: 03/09/2018
 Authors: Carlos Bernardos, Luis Contreras, Ishan Vaishnavi, Robert Szabo, Xi Li, Francesco Paolucci, Andrea Sgambelluri, Barbara Martini, Luca Valcarenghi, Giada Landi, Dmitriy Andrushko, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the problem of multi-provider multi-domain orchestration, by first scoping the problem, then looking into potential architectural approaches, and finally describing the solutions being developed by the European 5GEx and 5G-TRANSFORMER projects.
    
draft-bernardos-sfc-discovery-01.txt
 Service Function discovery in fog environments
 
 draft-bernardos-sfc-discovery-01.txt
 Date: 03/09/2018
 Authors: Carlos Bernardos, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Service function chaining (SFC) allows the instantiation of an ordered set of service functions and subsequent "steering" of traffic through them. Service functions provide an specific treatment of received packets, therefore they need to be known so they can be used in a given service composition via SFC. This document discusses the need for service function discovery mechanisms and propose some solutions for sfc-aware nodes to discover available service functions in fog environments.
    
draft-bernardos-sfc-fog-ran-04.txt
 Service Function Chaining Use Cases in Fog RAN
 
 draft-bernardos-sfc-fog-ran-04.txt
 Date: 03/09/2018
 Authors: Carlos Bernardos, Akbar Rahman, Alain Mourad
 Working Group: Individual Submissions (none)
 Formats: txt
Fog Radio Access Networks (RAN) refers to the part of the RAN that is virtualized at the very edge of the network, even at the end-user device. Fog RAN support is considered critical for the 5G mobile network architectures currently being developed in various research, standardization and industry forums. Since fog RAN builds on top of virtualization and can involve several virtual functions running on different virtualized resources, Service function chaining (SFC) support for the fog RAN will be critical. This document describes the overall fog RAN approach and also gives some use cases. Finally it proposes some requirements to be considered in the development of the SFC architecture and related protocols.
    
draft-bertz-dime-policygroups-06.txt
 Diameter Policy Groups and Sets
 
 draft-bertz-dime-policygroups-06.txt
 Date: 18/06/2018
 Authors: Lyle Bertz, Mark Bales
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines optional Diameter attributes for efficient policy provisioning.
    
draft-bertz-dime-predictunits-04.txt
 Diameter Predicted Units
 
 draft-bertz-dime-predictunits-04.txt
 Date: 18/06/2018
 Authors: Lyle Bertz
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the conveyance of predicted usage information for proper dimensioning of network services that use Diameter based authorization.
    
draft-bhjl-x509-srv-04.txt
 Using a DNS SRV Record to Locate an X.509 Certificate Store
 
 draft-bhjl-x509-srv-04.txt
 Date: 16/07/2018
 Authors: Brian Haberman, John Levine
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a method to allow parties to locate X.509 certificate stores with Domain Name System Service records in order to retrieve certificates and certificate revocation lists. The primary purpose of such retrievals is to facilitate the association of X.509 and PGP public keys with e-mail addresses to allow for encrypted e-mail exchanges.
    
draft-bi-savi-wlan-15.txt
 A SAVI Solution for WLAN
 
 draft-bi-savi-wlan-15.txt
 Date: 28/06/2018
 Authors: Jun Bi, Jianping Wu, You Wang, Tao Lin
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a source address validation solution for WLAN enabling 802.11i or other security mechanisms. This mechanism snoops NDP and DHCP packets to bind IP address to MAC address, and relies on the security of MAC address guaranteed by 802.11i or other mechanisms to filter IP spoofing packets. It can work in the special situations described in the charter of SAVI(Source Address Validation Improvements) workgroup, such as multiple MAC addresses on one interface. This document describes three different deployment scenarios, with solutions for migration of binding entries when hosts move from one access point to another.
    
draft-birk-pep-02.txt
 pretty Easy privacy (pEp): Privacy by Default
 
 draft-birk-pep-02.txt
 Date: 26/06/2018
 Authors: Volker Birk, Hernani Marques, Shelburn
 Working Group: Individual Submissions (none)
 Formats: xml txt
Building on already available security formats and message transports (like PGP/MIME for email), and with the intention to stay interoperable to systems widespreadly deployed, pretty Easy privacy (pEp) describes protocols to automatize operations (key management, key discovery, private key handling including peer-to-peer synchronization of private keys and other user data across devices) that have been seen to be barriers to deployment of end-to-end secure interpersonal messaging. pEp also relies on "Trustwords" (as a word mapping of of fingerprints) to verify communication peers and proposes a trust rating system to denote secure types of communications and signal the privacy level available on a per-user and per-message level. In this document, the general design choices and principles of pEp are outlined.
    
draft-birk-pep-trustwords-02.txt
 IANA Registration of Trustword Lists: Guide,Template and IANA Considerations
 
 draft-birk-pep-trustwords-02.txt
 Date: 26/06/2018
 Authors: Volker Birk, Hernani Marques, Bernie Hoeneisen
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the IANA Registration Guidelines for Trustwords, describes corresponding registration procedures, and provides a guideline for creating Trustword list specifications. Trustwords are common words in a natural language (e.g., English) to which the hexadecimal strings are mapped to. This makes verification processes (e.g., comparison of fingerprints), more practical and less prone to misunderstandings.
    
draft-birkholz-attestation-terminology-02.txt
 Reference Terminology for Remote Attestation Procedures
 
 draft-birkholz-attestation-terminology-02.txt
 Date: 02/07/2018
 Authors: Henk Birkholz, Monty Wiseman, Hannes Tschofenig
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is intended to illustrate and remediate the impedance mismatch of terms related to remote attestation procedures used in different domains today. New terms defined by this document provide a consolidated basis to support future work on attestation procedures in the IETF and beyond.
    
draft-birkholz-core-coid-00.txt
 Concise Identities
 
 draft-birkholz-core-coid-00.txt
 Date: 02/07/2018
 Authors: Henk Birkholz, Carsten Bormann, Max Pritikin, Robert Moskowitz
 Working Group: Individual Submissions (none)
 Formats: txt
There is an increased demand of trustworthy claim sets -- a set of system entity characteristics tied to an entity via signatures -- in order to provide information. Claim sets represented via CBOR Web Tokens (CWT) can compose a variety of evidence suitable for constrained-node networks and to support secure device automation. This document focuses on sets of identifiers and attributes that are tied to a system entity and are typically used to compose identities appropriate for Constrained RESTful Environment (CoRE) authentication needs.
    
draft-birkholz-i2nsf-tuda-03.txt
 Time-Based Uni-Directional Attestation
 
 draft-birkholz-i2nsf-tuda-03.txt
 Date: 02/05/2018
 Authors: Andreas Fuchs, Henk Birkholz, Ira McDonald, Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt xml
This memo documents the method and bindings used to conduct time- based uni-directional attestation between distinguishable endpoints over the network.
    
draft-birkholz-reference-ra-interaction-model-00.txt
 Reference Interaction Model for Challenge-Response-based Remote Attestation
 
 draft-birkholz-reference-ra-interaction-model-00.txt
 Date: 02/07/2018
 Authors: Henk Birkholz, Michael Eckel
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an interaction model for a basic remote attestation procedure. Additionally, the required information elements are illustrated.
    
draft-birkholz-suit-coswid-manifest-00.txt
 A SUIT Manifest Extension for Concise Software Identifiers
 
 draft-birkholz-suit-coswid-manifest-00.txt
 Date: 17/07/2018
 Authors: Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a resource extension for Concise Software Identifiers (CoSWID) that represents a SUIT firmware manifest. This extension combines the information elements of the SUIT information model with the semantic expressiveness of Software Identifiers. In consequence, this composite enables the integration of Firmware Updates for the Internet of Things (SUIT) in existing work-flows for updates of software components in general.
    
draft-birkholz-yang-basic-remote-attestation-00.txt
 YANG Module for Basic Challenge-Response-based Remote Attestation Procedures
 
 draft-birkholz-yang-basic-remote-attestation-00.txt
 Date: 02/07/2018
 Authors: Henk Birkholz, Michael Eckel, Shwetha Bhandari, Bill Sulzen, Eric Voit, Guy Fedorkow
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines YANG RPC and a minimal datastore required to retrieve integrity evidence about software from the device running the YANG datastore. The module presented requires a TPM 2.0 and corresponding Trusted Software Stack included in the system entity the YANG datastore is running on.
    
draft-birkholz-yang-core-telemetry-01.txt
 Concise YANG Telemetry
 
 draft-birkholz-yang-core-telemetry-01.txt
 Date: 16/07/2018
 Authors: Henk Birkholz, Eric Voit
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines CoAP operations that implement the capabilities of YANG Datastore Subscriptions and YANG Customized Subscriptions for the CoAP Management Interface (CoMI). The '/s' resource, as defined in CoMI, is extended analogously to include a set of sub-resources, each of them representing an observable resource identified by its subscription-id. Specific additions include but are not limited to new FETCH Body definitions and simplified subtree subscriptions to intermediate data nodes in YANG datastore modules using SID.
    
draft-birkholz-yang-swid-01.txt
 YANG module for Software Identifiers
 
 draft-birkholz-yang-swid-01.txt
 Date: 02/05/2018
 Authors: Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document provides a YANG module definition that enables a computing context to provide detailed information about installed software components. The structure of the module is based on the Concise Software Identifier draft and therefore also strongly related to the ISO 19770-2:2015 Software Identifiers standard. Both standards provide no interface to transport the SWID tag information between system entities and this document leverages the wide adoption of YANG based management interfaces.
    
draft-birrane-dtn-adm-03.txt
 AMA Application Data Model
 
 draft-birrane-dtn-adm-03.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a physical data model that captures the information necessary to asynchronously manage applications. This model provides a set of common type definitions, data structures, and a template for publishing standardized representations of model elements.
    
draft-birrane-dtn-adm-agent-04.txt
 Asynchronous Management Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-agent-04.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an Application Data Model (ADM) for an Asynchronous Management Protocol (AMP) Agent. The AMP Agent represents a managed device in the Asynchronous Management Architecture. This document is in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-bp-02.txt
 Bundle Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-bp-02.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Application Data Model (ADM) for a Bundle Protocol Agent (BPA) in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-bpsec-01.txt
 Bundle Protocol Security Application Data Model
 
 draft-birrane-dtn-adm-bpsec-01.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Application Data Model (ADM) for the Bundle Protocol Security (BPSEC) in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ion-bpadmin-00.txt
 Bundle Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-ion-bpadmin-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the administration of Bundle Protocol (BP) ION in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ion-ipnadmin-00.txt
 ION Application Data Model
 
 draft-birrane-dtn-adm-ion-ipnadmin-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the configuration of the routing of bundles to ipn endpoint ID scheme conformant endpoints from a local ION node. provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ion-ltpadmin-00.txt
 ION Licklider Transmission Protocol Admin Application Data Model
 
 draft-birrane-dtn-adm-ion-ltpadmin-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the configuration of licklider transmission protocol (LTP) in ION in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ionadmin-00.txt
 ION Administration Application Data Model
 
 draft-birrane-dtn-adm-ionadmin-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for the administration of ION in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ionsec-00.txt
 ION Security Application Data Model
 
 draft-birrane-dtn-adm-ionsec-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Application Data Model (ADM) for ION Security in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-adm-ltp-00.txt
 Licklider Transmission Protocol Agent Application Data Model
 
 draft-birrane-dtn-adm-ltp-00.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the Application Data Model (ADM) for a Licklider Transmission Protocol Agent (LTPA) in compliance with the template provided by [I-D.birrane-dtn-adm].
    
draft-birrane-dtn-ama-07.txt
 Asynchronous Management Architecture
 
 draft-birrane-dtn-ama-07.txt
 Date: 24/06/2018
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an asynchronous management architecture (AMA) suitable for providing application-level network management services in a challenged networking environment. Challenged networks are those that require fault protection, configuration, and performance reporting while unable to provide humans-in-the-loop with synchronous feedback or otherwise preserve transport-layer sessions. In such a context, networks must exhibit behavior that is both determinable and autonomous while maintaining compatibility with existing network management protocols and operational concepts.
    
draft-birrane-dtn-amp-05.txt
 Asynchronous Management Protocol
 
 draft-birrane-dtn-amp-05.txt
 Date: 02/07/2018
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a binary encoding of the Asynchronous Management Model (AMM) and a protocol for the exchange of these encoded items over a network. This Asynchronous Management Protocol (AMP) does not require transport-layer sessions, operates over unidirectional links, and seeks to reduce the energy and compute power necessary for performing network management on resource constrained devices.
    
draft-birrane-dtn-ampmgr-sql-01.txt
 AMP Manager SQL Interface
 
 draft-birrane-dtn-ampmgr-sql-01.txt
 Date: 02/07/2018
 Authors: Edward Birrane, Evana DiPietro, David Linko, Mark Sinkiat
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a proposed public interface through which an application, such as a network management console, interacts with an Asynchronous Management Protocol (AMP) Manager via a database supporting the Structured Query Language (SQL). The use of SQL as an interfacing layer provides a natural way to describe interactions with an AMP Manager independent of a particular implementation of either the Manager or the application. Specifically, this document presents a database schema capturing how to send controls to a Manager and how to accept reports received by a Manager from one or more AMP Agents.
    
draft-birrane-dtn-bpsec-interop-cs-02.txt
 BPSec Interoperability Cipher Suites
 
 draft-birrane-dtn-bpsec-interop-cs-02.txt
 Date: 02/07/2018
 Authors: Edward Birrane
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a set of integrity and confidentiality cipher suites suitable for testing the interoperability of Bundle Protocol Security (BPSec) implementations.
    
draft-bishop-httpbis-grease-00.txt
 GREASE for HTTP/2
 
 draft-bishop-httpbis-grease-00.txt
 Date: 24/05/2018
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: txt xml
Reserves several values in the HTTP/2 registries to exercise the requirement that clients and servers ignore unknown values.
    
draft-bishop-httpbis-push-cases-00.txt
 HTTP/2 Server Push Use Cases
 
 draft-bishop-httpbis-push-cases-00.txt
 Date: 29/06/2018
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: xml txt
HTTP/2 defines the wire mechanics of Server Push. Though the mechanics of how a pushed resource is delivered are well-specified, the use cases that describe which resources can be pushed, in what states, and for what purpose are not described in HTTP/2. As a result, support between implementations varies widely. This document attempts to enumerate interesting scenarios, in hopes that a more concrete taxonomy can assist the community in arriving at a standard set of supported scenarios.
    
draft-bishop-httpbis-sni-altsvc-02.txt
 The "SNI" Alt-Svc Parameter
 
 draft-bishop-httpbis-sni-altsvc-02.txt
 Date: 24/05/2018
 Authors: Mike Bishop
 Working Group: Individual Submissions (none)
 Formats: txt xml
HTTP Alternative Services provides a mechanism for an origin to declare that its content is accessible via some other combination of host, port, and protocol. In the process of using such an alternative, an observer can identify that the client is requesting resources from a particular hostname. This document extends HTTP Alternative Services, in combination with Secondary Certificate Authentication, to enable clients not to disclose the origin to which they intend to connect.
    
draft-bng-radext-virtual-nas-for-dnas-02.txt
 Virtual NAS (vNAS) Support for DNAS
 
 draft-bng-radext-virtual-nas-for-dnas-02.txt
 Date: 04/06/2018
 Authors: Raghunadha Pocha, Chandrashekhar Jamadarkhani, Satyanarayana Danda, Nishad M, Nagappa Chinnannavar
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines a framework for interacting North bound (AAA/Policy) servers of the Client resides in Cloud and/or Distributed Network environment with High-Availability to achieve fewer use-cases. First, NAS Client resides in Cloud or Virtualized or Distributed Network Access System to perform Authorization, Authentication and Accounting procedures with AAA Servers. Second, AAAA/Policy Servers provide dynamic policy information for subscribers of supporting in NAS Clients resides in Cloud or Virtualized or Distributed Network environment. Finally, Handling of Accounting related issues in better way for subscribers supported in Cloud or Virtualized or Distributed Network environment under High- Available conditions.
    
draft-bogineni-dmm-optimized-mobile-user-plane-01.txt
 Optimized Mobile User Plane Solutions for 5G
 
 draft-bogineni-dmm-optimized-mobile-user-plane-01.txt
 Date: 29/06/2018
 Authors: Kalyani Bogineni, Arashmid Akhavain, Tom Herbert, Dino Farinacci, Alberto Rodriguez-Natal, Giovanna Carofiglio, Jordan Auge, Luca Muscariello, Pablo Camarillo, Shunsuke Homma
 Working Group: Individual Submissions (none)
 Formats: txt
3GPP CT4 has approved a study item to study different mobility management protocols for potential replacement of GTP tunnels between UPFs (N9 Interface) in the 3GPP 5G system architecture. This document provides an overview of 5G system architecture in the context of N9 Interface which is the scope of the 3GPP CT4 study item [CP-173160-1], [TS.23.501-3GPP], [TS.23.502-3GPP], [TS.23.503-3GPP], [TS.29.244-3GPP], [TS.29.281-3GPP], [TS.38.300-3GPP], and [TS.38.401-3GPP]. Architecture requirements for evaluation of candidate protocols are provided. Optimization of the user plane can be in different ways - packet overhead, transport integration, etc. Several IETF protocols are considered for comparison: SRv6, LISP, ILA and several combinations of control plane and user plane protocols.
    
draft-bonica-6man-unrecognized-opt-03.txt
 The IPv6 Probe Option
 
 draft-bonica-6man-unrecognized-opt-03.txt
 Date: 09/08/2018
 Authors: Ron Bonica, John Leddy
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a new IPv6 option, called the Probe option. The Probe option elicits an ICMPv6 Parameter Problem message from all nodes that process it. When a node sends a packet that contains the Probe option and receives an ICMPv6 Parameter Problem message in response, it has verified the network's ability to convey packets that contain the Probe option.
    
draft-bonica-6man-vpn-dest-opt-00.txt
 The IPv6 Virtual Private Network (VPN) Context Information Option
 
 draft-bonica-6man-vpn-dest-opt-00.txt
 Date: 11/06/2018
 Authors: Ron Bonica, Chris Lenart, Greg Presbury
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines a new IPv6 Destination Option that can be used to encode Virtual Private Network (VPN) context information. It is applicable when VPN payload is transported over IPv6.
    
draft-bormann-cbor-cddl-freezer-01.txt
 A feature freezer for the Concise Data Definition Language (CDDL)
 
 draft-bormann-cbor-cddl-freezer-01.txt
 Date: 09/08/2018
 Authors: Carsten Bormann
 Working Group: Individual Submissions (none)
 Formats: txt
In defining the Concise Data Definition Language (CDDL), some features have turned up that would be nice to have. In the interest of completing this specification in a timely manner, the present document collects nice-to-have features that did not make it into the first RFC for CDDL.
    
draft-bormann-core-proactive-ct-00.txt
 Proactively Assigning CoAP Content-Format Numbers to Registered Media Types
 
 draft-bormann-core-proactive-ct-00.txt
 Date: 02/07/2018
 Authors: Carsten Bormann, Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
In order to use a media type with the Constrained Application Protocol (CoAP), a numeric identifier needs to be registered for it, the Content-Format number. RFC 7252 defines registration procedures for Content-Format numbers. The present document defines a proactive procedure to register a Content-Format number for many of the media types that are registered and discusses the benefits and limitations of that approach.
    
draft-bormann-lwig-7228bis-03.txt
 Terminology for Constrained-Node Networks
 
 draft-bormann-lwig-7228bis-03.txt
 Date: 02/07/2018
 Authors: Carsten Bormann, Mehmet Ersue, Ari Keranen, Carles Gomez
 Working Group: Individual Submissions (none)
 Formats: txt
The Internet Protocol Suite is increasingly used on small devices with severe constraints on power, memory, and processing resources, creating constrained-node networks. This document provides a number of basic terms that have been useful in the standardization work for constrained-node networks.
    
draft-bormann-t2trg-stp-01.txt
 The Series Transfer Pattern (STP)
 
 draft-bormann-t2trg-stp-01.txt
 Date: 02/07/2018
 Authors: Carsten Bormann, Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
Many applications make use of Series of data items, i.e., an array of data items where new items can be added over time. Where such Series are to be made available using REST protocols such as CoAP or HTTP, the Series has to be mapped into a structure of one or more resources and a protocol for a client to obtain the Series and to learn about new items. Various protocols have been standardized that make Series-shaped data available, with rather different properties and objectives. The present document is an attempt to extract a common underlying pattern and to define media types and an access scheme that can be used right away for further protocols that provide Series-shaped data.
    
draft-bortzmeyer-dprive-resolver-to-auth-01.txt
 Encryption and authentication of the DNS resolver-to-authoritative communication
 
 draft-bortzmeyer-dprive-resolver-to-auth-01.txt
 Date: 20/03/2018
 Authors: Stephane Bortzmeyer
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a mechanism for securing (privacy-wise) the communication between the DNS resolver and the authoritative name server. REMOVE BEFORE PUBLICATION: this document should be discussed in the IETF DPRIVE group, through its mailing list. The source of the document, as well as a list of open issues, is currently kept at Github [1].
    
draft-bortzmeyer-dprive-rfc7626-bis-01.txt
 DNS Privacy Considerations
 
 draft-bortzmeyer-dprive-rfc7626-bis-01.txt
 Date: 16/07/2018
 Authors: Stephane Bortzmeyer, Sara Dickinson
 Working Group: DNS PRIVate Exchange (dprive)
 Formats: txt
This document describes the privacy issues associated with the use of the DNS by Internet users. It is intended to be an analysis of the present situation and does not prescribe solutions.
    
draft-boucadair-dots-multihoming-03.txt
 Multi-homing Deployment Considerations for Distributed-Denial-of-Service Open Threat Signaling (DOTS)
 
 draft-boucadair-dots-multihoming-03.txt
 Date: 09/04/2018
 Authors: Mohamed Boucadair, Tirumaleswar Reddy
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document discusses multi-homing considerations for Distributed- Denial-of-Service Open Threat Signaling (DOTS). The goal is to provide a set of guidance for DOTS clients/gateways when multihomed.
    
draft-boucadair-dots-server-discovery-04.txt
 Distributed-Denial-of-Service Open Threat Signaling (DOTS) Server Discovery
 
 draft-boucadair-dots-server-discovery-04.txt
 Date: 09/04/2018
 Authors: Mohamed Boucadair, Tirumaleswar Reddy, Prashanth Patil
 Working Group: Individual Submissions (none)
 Formats: txt xml
It may not be possible for a network to determine the cause for an attack, but instead just realize that some resources seem to be under attack. To fill that gap, Distributed-Denial-of-Service Open Threat Signaling (DOTS) allows a network to inform a DOTS server that it is under a potential attack so that appropriate mitigation actions are undertaken. This document specifies mechanisms to configure nodes with DOTS servers.
    
draft-boucadair-ipsecme-ipv6-ipv4-codes-03.txt
 IKEv2 Notification Codes for IPv4/IPv6 Coexistence
 
 draft-boucadair-ipsecme-ipv6-ipv4-codes-03.txt
 Date: 19/09/2018
 Authors: Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies new IKEv2 notification codes to better manage IPv4 and IPv6 co-existence.
    
draft-boucadair-lisp-bulk-07.txt
 LISP Mapping Bulk Retrieval
 
 draft-boucadair-lisp-bulk-07.txt
 Date: 03/04/2018
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document extends Locator/ID Separation Protocol (LISP) with a capability for bulk mapping retrieval. It does so by defining new LISP messages that are meant to facilitate state recovery of mapping tables and improve Ingress Tunnel Routers (ITR) recovery times, in particular. Unlike base LISP, these new messages are transported over TCP. In addition, this document allows to request mappings that match destination IP prefixes, names, or AS numbers.
    
draft-boucadair-lisp-rfc8113bis-01.txt
 Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations
 
 draft-boucadair-lisp-rfc8113bis-01.txt
 Date: 19/09/2018
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension. This document obsoletes RFC 8113.
    
draft-boucadair-radext-tcpm-converter-00.txt
 RADIUS Extensions for 0-RTT TCP Converters
 
 draft-boucadair-radext-tcpm-converter-00.txt
 Date: 03/04/2018
 Authors: Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: xml txt
Because of the lack of Multipath TCP (MPTCP) support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called Converters. Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document specifies a new Remote Authentication Dial-In User Service (RADIUS) attributes that carry the IP addresses that will be returned to authorized users to reach one or multiple Converters.
    
draft-boucadair-tcpm-dhc-converter-00.txt
 DHCP Options for 0-RTT TCP Converters
 
 draft-boucadair-tcpm-dhc-converter-00.txt
 Date: 03/04/2018
 Authors: Mohamed Boucadair, Christian Jacquenet, Tirumaleswar Reddy
 Working Group: Individual Submissions (none)
 Formats: txt xml
Because of the lack of Multipath TCP (MPTCP) support at the server side, some service providers now consider a network-assisted model that relies upon the activation of a dedicated function called Converters. Network-assisted MPTCP deployment models are designed to facilitate the adoption of MPTCP for the establishment of multi-path communications without making any assumption about the support of MPTCP by the communicating peers. Converters located in the network are responsible for establishing multi-path communications on behalf of endpoints, thereby taking advantage of MPTCP capabilities to achieve different goals that include (but are not limited to) optimization of resource usage (e.g., bandwidth aggregation), of resiliency (e.g., primary/backup communication paths), and traffic offload management. This document focuses on the explicit deployment scheme where the identity of the Converters is explicitly configured on connected hosts. This document specifies DHCP (IPv4 and IPv6) options to configure hosts with Converters parameters.
    
draft-bourbaki-6man-classless-ipv6-04.txt
 IPv6 is Classless
 
 draft-bourbaki-6man-classless-ipv6-04.txt
 Date: 15/09/2018
 Authors: Nicolas Bourbaki
 Working Group: Individual Submissions (none)
 Formats: txt
Over the history of IPv6, various classful address models have been proposed, none of which has withstood the test of time. The last remnant of IPv6 classful addressing is a rigid network interface identifier boundary at /64. This document removes the fixed position of that boundary for interface addressing.
    
draft-boutros-bess-evpn-geneve-03.txt
 EVPN control plane for Geneve
 
 draft-boutros-bess-evpn-geneve-03.txt
 Date: 14/09/2018
 Authors: Sami Boutros, Ali Sajassi, John Drake, Jorge Rabadan
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how Ethernet VPN (EVPN) control plane can be used with Network Virtualization Overlay over Layer 3 (NVO3) Generic Network Virtualization Encapsulation (Geneve) encapsulation for NVO3 solutions. EVPN control plane can also be used by a Network Virtualization Endpoints (NVEs) to express Geneve tunnel option TLV(s)supported in transmission and/or reception of Geneve encapsulated data packets.
    
draft-boutros-nvo3-geneve-applicability-for-sfc-02.txt
 Geneve applicability for service function chaining
 
 draft-boutros-nvo3-geneve-applicability-for-sfc-02.txt
 Date: 14/09/2018
 Authors: Sami Boutros, Dharma Rajan, Philip Kippen, Pierluigi Rolando
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of using Generic Network Virtualization Encapsulation (Geneve), to carry the service function path (SFP) information, and the network service header (NSH) encapsulation. The SFP information will be carried in Geneve option TLV(s).
    
draft-bradley-oauth-stateless-client-id-06.txt
 Stateless Client Identifier for OAuth 2
 
 draft-bradley-oauth-stateless-client-id-06.txt
 Date: 02/08/2018
 Authors: John Bradley, Justin Richer
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft provides a method for communicating information about an OAuth client through its client identifier allowing for fully stateless operation.
    
draft-briscoe-tsvwg-l4s-diffserv-01.txt
 Interactions between Low Latency,Low Loss,Scalable Throughput (L4S) and Differentiated Services
 
 draft-briscoe-tsvwg-l4s-diffserv-01.txt
 Date: 02/07/2018
 Authors: Bob Briscoe
 Working Group: Individual Submissions (none)
 Formats: txt xml
L4S and Diffserv offer somewhat overlapping services (low latency and low loss), but bandwidth allocation is out of scope for L4S. Therefore there is scope for the two approaches to complement each other, but also to conflict. This informational document explains how the two approaches interact, how they can be arranged to complement each other and in which cases one can stand alone without needing the other.
    
draft-brockners-ippm-ioam-geneve-01.txt
 Geneve encapsulation for In-situ OAM Data
 
 draft-brockners-ippm-ioam-geneve-01.txt
 Date: 27/06/2018
 Authors: Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, David Mozes, Petr Lapukhov, Remy Chang
 Working Group: Individual Submissions (none)
 Formats: xml txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in Geneve.
    
draft-brockners-ippm-ioam-vxlan-gpe-01.txt
 VXLAN-GPE Encapsulation for In-situ OAM Data
 
 draft-brockners-ippm-ioam-vxlan-gpe-01.txt
 Date: 27/06/2018
 Authors: Frank Brockners, Shwetha Bhandari, Vengada Govindan, Carlos Pignataro, Hannes Gredler, John Leddy, Stephen Youell, Tal Mizrahi, Aviv Kfir, Barak Gafni, Petr Lapukhov, Mickey Spiegel
 Working Group: Individual Submissions (none)
 Formats: xml txt
In-situ Operations, Administration, and Maintenance (IOAM) records operational and telemetry information in the packet while the packet traverses a path between two points in the network. This document outlines how IOAM data fields are encapsulated in VXLAN-GPE.
    
draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-01.txt
 Elliptic curve 2y^2=x^3+x over field size 8^91+5
 
 draft-brown-ec-2y2-x3-x-mod-8-to-91-plus-5-01.txt
 Date: 13/04/2018
 Authors: Dan Brown
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a special elliptic curve with complex multiplication (by i) and a compact description (see title). This curve is recommended for cryptographic use in a strongest-link combination with dissimilar elliptic curves (e.g. NIST P-256, Curve25519, extension-field curves, etc.) as a defense in depth against an unlikely, unforeseen attack on otherwise preferred elliptic curves. The curve equation 2y^2=x^3+x is the Montgomery form of a curve y^2=x^3-x in a class of curves y^2=x^3-ax suggested by Miller in the first published paper elliptic curve cryptography, and an endomorphism usable for efficiency, an idea of Koblitz. The field size 8^91+5 is prime, and is relatively efficient and compactly described for its bit-size (273 bits). The document specifies some practical details such as: encoding a point (on the curve) into 34 bytes, public key validation, encoding a private key into 34 bytes, and encoding 34 bytes into a point. The document also provides pseudocode, motivation, and security considerations.
    
draft-brown-whoami-02.txt
 WHOAMI: A Method For Identifying a Domain Operator's Contact Information
 
 draft-brown-whoami-02.txt
 Date: 01/06/2018
 Authors: Gavin Brown
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes a method by which the operator of a domain may publish their contact information in a discoverable and machine- readable format.
    
draft-browne-sfc-nsh-kpi-stamp-05.txt
 A Key Performance Indicators (KPI) Stamping for the Network Service Header (NSH)
 
 draft-browne-sfc-nsh-kpi-stamp-05.txt
 Date: 27/08/2018
 Authors: Rory Browne, Andrey Chilikin, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an experimenal method of carrying Key Performance Indicators (KPIs) using the Network Service Header (NSH). This method may be used, for example, to monitor latency and QoS marking to identify problems on some links or service functions.
    
draft-bruckert-brainpool-for-tls13-00.txt
 ECC Brainpool Curves for Transport Layer Security (TLS) Version 1.3
 
 draft-bruckert-brainpool-for-tls13-00.txt
 Date: 30/08/2018
 Authors: Leonie Bruckert, Johannes Merkle, Manfred Lochter
 Working Group: Individual Submissions (none)
 Formats: txt pdf
This document specifies the use of several ECC Brainpool curves for authentication and key exchange in the Transport Layer Security (TLS) protocol version 1.3.
    
draft-bryskin-netconf-automation-yang-02.txt
 Generalized Network Control Automation YANG Model
 
 draft-bryskin-netconf-automation-yang-02.txt
 Date: 29/06/2018
 Authors: Igor Bryskin, Xufeng Liu, Alexander Clemm, Henk Birkholz, Tianran Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a YANG data model for the Generalized Network Control Automation (GNCA), aimed to define an abstract and uniform semantics for NETCONF/YANG scripts in the form of Event-Condition- Action (ECA) containers.
    
draft-burleigh-dtn-stcp-00.txt
 Simple TCP Convergence-Layer Protocol
 
 draft-burleigh-dtn-stcp-00.txt
 Date: 14/09/2018
 Authors: Scott Burleigh
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a Simple TCP (STCP) "convergence-layer" protocol for the Delay-Tolerant Networking (DTN) Bundle Protocol (BP). STCP uses Transmission Control Protocol (TCP) to transmit BP "bundles" from one BP node to another node to which it is topologically adjacent in the BP network. The services provided by the STCP convergence-layer protocol adapter utilize a standard TCP connection for the purposes of bundle transmission.
    
draft-burleigh-dtnwg-dtka-02.txt
 Architecture for Delay-Tolerant Key Administration
 
 draft-burleigh-dtnwg-dtka-02.txt
 Date: 28/08/2018
 Authors: Scott Burleigh, David Horres, Kapali Viswanathan, michael.w.benson@boeing.com, Fred Templin
 Working Group: Individual Submissions (none)
 Formats: xml txt
Delay-Tolerant Key Administration (DTKA) is a system of public-key management protocols intended for use in Delay Tolerant Networking (DTN). This document outlines a DTKA proposal for space-based communications, which are characterized by long communication delays and planned communication contacts.
    
draft-busi-pals-pw-cw-stitching-00.txt
 Pseudowire (PW) Control Word (CW) Stitching
 
 draft-busi-pals-pw-cw-stitching-00.txt
 Date: 02/07/2018
 Authors: Italo Busi, Stewart Bryant, Andrew Malis, Jie Dong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the behavior of a new type of Multi-Segment Pseudowire (MS-PW) Switching PE (S-PE) which enhances the S-PE functions defined in [RFC 6073], with the capability to switch an Ethernet pseudowire (PW) segment that uses the PW Control Word (CW) [RFC 4385] with an Ethernet PW segment that does not use the CW. This new type of S-PE can be deployed in the network one hop away, at the MPLS layer, from a Terminating PE (T-PE) which does not support CW for Ethernet PW encapsulation [RFC 4448]. In this way, all the Ethernet PW packets sent though the MPLS network will have the CW and be protected against incorrect equal-cost-multi-path (ECMP) behavior as described in [I-D ETH-CW].
    
draft-bvtm-dhc-mac-assign-01.txt
 Link-Layer Addresses Assignment Mechanism for DHCPv6
 
 draft-bvtm-dhc-mac-assign-01.txt
 Date: 14/05/2018
 Authors: Bernie Volz, Tomek Mrugalski
 Working Group: Individual Submissions (none)
 Formats: txt xml
In certain environments, e.g. large scale virtualization deployments, new devices are created in an automated manner. Such devices typically have their link-layer (MAC) addresses randomized. With sufficient scale, the likelihood of collision is not acceptable. Therefore an allocation mechanism is required. This draft proposes an extension to DHCPv6 that allows a scalable approach to link-layer address assignments.
    
draft-byrne-v6ops-dnssecaaaa-00.txt
 DNSSEC Resource Record Should Include AAAA
 
 draft-byrne-v6ops-dnssecaaaa-00.txt
 Date: 01/07/2018
 Authors: Cameron Byrne
 Working Group: Individual Submissions (none)
 Formats: txt
DNS64 is a widely deployed technology allowing hundreds of millions of IPv6-only hosts to reach IPv4-only resources. DNSSEC is a technology used to validate the authenticity of information in the DNS. Currently, there are scenarios where DNS64 and DNSSEC do not work well together. This document states that any DNSSEC signed resources record should include a native IPv6 resource record as the most complete and expedient path to solve any deployment conflict with DNS64 and DNSSEC.
    
draft-bz-v4goawayflag-00.txt
 IPv6 Router Advertisement IPv4 GoAway Flag
 
 draft-bz-v4goawayflag-00.txt
 Date: 31/03/2018
 Authors: Bjoern Zeeb
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a Router Advertisement Flag to indicate to end nodes that IPv4 support must be disabled on this link. In addition this document presents a policy and a timeline on how to deal with this flag and the going-away of IPv4. This document updates RFC5175.
    
draft-calconnect-vobject-i18n-00.txt
 vObject Internationalization
 
 draft-calconnect-vobject-i18n-00.txt
 Date: 07/06/2018
 Authors: Ronald Tse, Peter Tam, Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies mechanisms for the internationalization of vObject content and its realization in vFormat. This document updates the following specifications: o I-D.calconnect-vobject-vformat, The vObject Model and vFormat Syntax o RFC 6350, vCard version 4.0 o RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar) o RFC 7953, Calendar Availability Extensions This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.
    
draft-calconnect-vobject-integrity-01.txt
 Integrity Protection for vObject,vCard and iCalendar
 
 draft-calconnect-vobject-integrity-01.txt
 Date: 19/04/2018
 Authors: Ronald Tse, Peter Tam
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an integrity checking mechanism and related properties for: o vObject (I-D.calconnect-vobject-vformat) o vCard version 4 (vCard v4) (RFC 6350); and o iCalendar (Internet Calendaring and Scheduling Core Object Specification) (RFC 5545) This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.
    
draft-calconnect-vobject-vformat-04.txt
 The vObject Model and vFormat Syntax
 
 draft-calconnect-vobject-vformat-04.txt
 Date: 07/06/2018
 Authors: Ronald Tse, Peter Tam, Ken Murchison, Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the vObject data model and its corresponding syntax vFormat. vObject represents the generalized data model, and vFormat the generalized data format, of the following specifications and fully covers them: o RFC 6350, vCard version 4.0: the VCARD component; o RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar): the VCALENDAR, VEVENT, VJOURNAL, VFREEBUSY, VTIMEZONE, VALARM, VTODO, STANDARD and DAYLIGHT components; o RFC 7953, Calendar Availability Extensions: the VAVAILABILITY and AVAILABLE components; o I-Ddaboo-icalendar-vpatch, iCalendar Patching: the VPATCH component; and o alternative formats for iCalendar and vCard, including RFC 6321, xCal; RFC 7265, jCal; RFC 6351, xCard; and RFC 7095, jCard. This work is produced by the CalConnect TC-VCARD and TC-CALENDAR committees.
    
draft-camarillo-dmm-srv6-mobile-pocs-00.txt
 Segment Routing IPv6 for mobile user-plane PoCs
 
 draft-camarillo-dmm-srv6-mobile-pocs-00.txt
 Date: 02/07/2018
 Authors: Pablo Camarillo, Clarence Filsfils, Lyle Bertz, Arashmid Akhavain, Satoru Matsushima, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the ongoing proof of concepts of [I-D.ietf-dmm-srv6-mobile-uplane] and their progress.
    
draft-camarilloelmalky-springdmm-srv6-mob-usecases-00.txt
 SRv6 Mobility Use-Cases
 
 draft-camarilloelmalky-springdmm-srv6-mob-usecases-00.txt
 Date: 15/07/2018
 Authors: Pablo Camarillo, Clarence Filsfils, Hani Elmalky, Dave Allan, Satoru Matsushima, daniel.voyer@bell.ca, Anna Cui, Bart Peirens
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the SRv6 use-cases in the mobile network in association with different mobile generations (3G, 4G, and 5G). It also highlights potential interworking with SR-MPLS in relevant use- cases.
    
draft-camelot-holy-grenade-01.txt
 The Holy Hand Grenade of Antioch
 
 draft-camelot-holy-grenade-01.txt
 Date: 15/04/2018
 Authors: Arthur Pendragon
 Working Group: Individual Submissions (none)
 Formats: xml txt
The menagerie of beasts and artefacts depicted in RFC8140 may be usefully supplemented by other renowned figures of Internet and more general lore. This document extends the menagerie to the seminal fable of the "Holy Hand Grenade of Antioch", as depicted in the Monty Python film "Monty Python and the Holy Grail", as well as "Spamalot", the musical inspired by the movie. Spamalot The relevance of the musical "Spamalot" to Internet lore should be obvious to the reader; but in case of doubt, see also Section 1 ("What is Spam*?") of RFC2635.
    
draft-campbell-sip-messaging-smime-03.txt
 Securing Session Initiation Protocol (SIP) based Messaging with S/MIME
 
 draft-campbell-sip-messaging-smime-03.txt
 Date: 25/06/2018
 Authors: Ben Campbell, Russell Housley
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
Mobile messaging applications used with the Session Initiation Protocol (SIP) commonly use some combination of the SIP MESSAGE method and the Message Session Relay Protocol (MSRP). While these provide mechanisms for hop-by-hop security, neither natively provides end-to-end protection. This document offers guidance on how to provide end-to-end authentication, integrity protection, and confidentiality using the Secure/Multipurpose Internet Mail Extensions (S/MIME). It updates and provides clarifications for RFC 3261, RFC 3428, and RFC 4975.
    
draft-camwinget-tls-ts13-macciphersuites-00.txt
 TLS 1.3 Authentication and Integrity only Ciphersuites
 
 draft-camwinget-tls-ts13-macciphersuites-00.txt
 Date: 28/06/2018
 Authors: Nancy Cam-Winget, Jack Visoky
 Working Group: Individual Submissions (none)
 Formats: xml txt
There are use cases, specifically in Internet of Things (IoT) and constrained environments that do not require confidentiality, though mutual authentication during tunnel establishment and message integrity is still mandated. This document defines the use of HMAC only as ciphersuites in TLS 1.3.
    
draft-camwinget-tls-use-cases-02.txt
 TLS 1.3 Impact on Network-Based Security
 
 draft-camwinget-tls-use-cases-02.txt
 Date: 02/07/2018
 Authors: Flemming Andreasen, Nancy Cam-Winget, Eric Wang
 Working Group: Individual Submissions (none)
 Formats: txt
Network-based security solutions are used by enterprises, public sector, and cloud service providers today in order to both complement and augment host-based security solutions. TLS 1.3 introduces several changes to TLS 1.2 with a goal to improve the overall security and privacy provided by TLS. However some of these changes have a negative impact on network-based security solutions. While this may be viewed as a feature, there are several real-life use case scenarios that are not easily solved without such network-based security solutions. In this document, we identify the TLS 1.3 changes that may impact network-based security solutions and provide a set of use case scenarios that are not easily solved without such solutions.
    
draft-carpenter-6man-lap-01.txt
 The Longest Acceptable Prefix for IPv6 Links
 
 draft-carpenter-6man-lap-01.txt
 Date: 19/06/2018
 Authors: Brian Carpenter
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the concepts of a Longest Acceptable Prefix (LAP) and a Shortest Acceptable Identifier Length (SAIL) for an IPv6 link.
    
draft-carpenter-anima-asa-guidelines-05.txt
 Guidelines for Autonomic Service Agents
 
 draft-carpenter-anima-asa-guidelines-05.txt
 Date: 29/06/2018
 Authors: Brian Carpenter, Laurent Ciavaglia, Sheng Jiang, Peloso Pierre
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes guidelines for the design of Autonomic Service Agents for autonomic networks. It is based on the Autonomic Network Infrastructure outlined in the ANIMA reference model, making use of the Autonomic Control Plane and the Generic Autonomic Signaling Protocol.
    
draft-carpenter-anima-grasp-bulk-02.txt
 Transferring Bulk Data over the GeneRic Autonomic Signaling Protocol (GRASP)
 
 draft-carpenter-anima-grasp-bulk-02.txt
 Date: 29/06/2018
 Authors: Brian Carpenter, Sheng Jiang, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes how bulk data may be transferred between Autonomic Service Agents via the GeneRic Autonomic Signaling Protocol (GRASP).
    
draft-carpenter-community-leaders-00.txt
 Some Thoughts on IETF Community Leadership
 
 draft-carpenter-community-leaders-00.txt
 Date: 07/09/2018
 Authors: Brian Carpenter
 Working Group: Individual Submissions (none)
 Formats: txt xml
This is a personal view of what the IETF community might expect of its members who serve in leadership positions such as Area Directors and IAB members. It is intended as personal input to the Nominating Committee, but posted as a draft since there is nothing private about it.
    
draft-carpenter-limited-domains-03.txt
 Limited Domains and Internet Protocols
 
 draft-carpenter-limited-domains-03.txt
 Date: 11/09/2018
 Authors: Brian Carpenter, Bing Liu
 Working Group: Individual Submissions (none)
 Formats: xml txt
There is a noticeable trend towards network requirements, behaviours and semantics that are specific to a limited region of the Internet and a particular set of requirements. Policies, default parameters, the options supported, the style of network management and security requirements may vary. This document reviews examples of such limited domains and emerging solutions, and develops a related taxonomy. It shows the needs for a precise definition of a limited domain boundary and for a corresponding protocol to allow nodes to discover where such a boundary exists.
    
draft-carpenter-request-for-comments-00.txt
 Request for Comments
 
 draft-carpenter-request-for-comments-00.txt
 Date: 05/06/2018
 Authors: Brian Carpenter
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses the Internet technical community's common document series.
    
draft-carrel-ipsecme-controller-ike-00.txt
 IPsec Key Exchange using a Controller
 
 draft-carrel-ipsecme-controller-ike-00.txt
 Date: 02/07/2018
 Authors: David Carrel, Brian Weis
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents a key exchange method allowing devices managed by a controller (e.g., an SDN management station) to create private pair-wise IPsec SAs without IKEv2 or any other direct peer-to-peer session establishment messages.
    
draft-cavage-http-signatures-10.txt
 Signing HTTP Messages
 
 draft-cavage-http-signatures-10.txt
 Date: 15/05/2018
 Authors: Mark Cavage, Manu Sporny
 Working Group: Individual Submissions (none)
 Formats: txt xml
When communicating over the Internet using the HTTP protocol, it can be desirable for a server or client to authenticate the sender of a particular message. It can also be desirable to ensure that the message was not tampered with during transit. This document describes a way for servers and clients to simultaneously add authentication and message integrity to HTTP messages by using a digital signature.
    
draft-cbrt-pce-stateful-local-protection-01.txt
 PCEP Extensions for RSVP-TE Local-Protection with PCE-Stateful
 
 draft-cbrt-pce-stateful-local-protection-01.txt
 Date: 29/06/2018
 Authors: Colby Barth, Raveendra Torvi
 Working Group: Individual Submissions (none)
 Formats: xml txt
Stateful PCE [RFC8231] can apply global concurrent optimizations to optimize LSP placement. In a deployment where a PCE is used to compute all the paths, it may be beneficial for the local protection paths to also be computed by the PCE. This document defines extensions needed for the setup and management of RSVP-TE protection paths by the PCE.
    
draft-cc-isis-flooding-reduction-01.txt
 ISIS Flooding Reduction
 
 draft-cc-isis-flooding-reduction-01.txt
 Date: 29/04/2018
 Authors: Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an approach to flood ISIS link state protocol data units on a topology that is a subgraph of the complete ISIS topology per underline physical network, so that the amount of flooding traffic in the network is greatly reduced, and it would reduce convergence time with a more stable and optimized routing environment. The approach can be applied to any network topology in a single ISIS area.
    
draft-cc-ospf-flooding-reduction-04.txt
 LS Flooding Reduction
 
 draft-cc-ospf-flooding-reduction-04.txt
 Date: 20/09/2018
 Authors: Huaimo Chen, Dean Cheng, Mehmet Toy, Yi Yang
 Working Group: Individual Submissions (none)
 Formats: txt pdf
This document proposes an approach to flood link states on a topology that is a subgraph of the complete topology per underline physical network, so that the amount of flooding traffic in the network is greatly reduced, and it would reduce convergence time with a more stable and optimized routing environment. The approach can be applied to any network topology in a single area.
    
draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
 Linux-related Extensions to NFS version 4.2 Security Labels
 
 draft-cel-nfsv4-linux-seclabel-xtensions-00.txt
 Date: 10/04/2018
 Authors: Chuck Lever
 Working Group: Individual Submissions (none)
 Formats: xml txt
NFS version 4.2 introduces an optional feature known as NFSv4 Security Labels. This document extends NFSv4 Security Labels to support Linux file capabilities and the Linux Integrity Measurement Architecture.
    
draft-cel-nfsv4-reminv-design-08.txt
 Using Remote Invalidation With RPC-Over-RDMA Transports
 
 draft-cel-nfsv4-reminv-design-08.txt
 Date: 17/07/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-03.txt
 Improving the Performance and Reliability of RPC Replies on RPC-over-RDMA Transports
 
 draft-cel-nfsv4-rpcrdma-reliable-reply-03.txt
 Date: 16/07/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-07.txt
 RPC-over-RDMA Version 2 Protocol
 
 draft-cel-nfsv4-rpcrdma-version-two-07.txt
 Date: 16/07/2018
 Authors: Chuck Lever, David Noveck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies an improved protocol for conveying Remote Procedure Call (RPC) messages on physical transports capable of Remote Direct Memory Access (RDMA), based on RPC-over-RDMA version 1.
    
draft-chandra-mpls-rsvp-shared-labels-np-00.txt
 Node Protection for RSVP-TE tunnels on a shared MPLS forwarding plane
 
 draft-chandra-mpls-rsvp-shared-labels-np-00.txt
 Date: 02/07/2018
 Authors: Chandrasekar R, Vishnu Beeram, Harish Sitaraman
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routed RSVP-TE tunnels provide the ability to use a shared MPLS forwarding plane at every hop of the Label Switched Path (LSP). The shared forwarding plane is realized with the use of 'Traffic Engineering (TE) link labels' that get shared by LSPs traversing these TE links. This paradigm helps significantly reduce the forwarding plane state required to support a large number of LSPs on a Label Switching Router (LSR). These tunnels require the ingress Label Edge Router (LER) to impose a stack of labels. If the ingress LER cannot impose the full label stack, it can use the assistance of one or more delegation hops along the path of the LSP to impose parts of the label stack. The procedures for a Point of Local Repair (PLR) to provide local protection against link failures using facility backup for Segment Routed RSVP-TE tunnels are well defined and do not require specific protocol extensions. This document defines the procedures for a PLR to provide local protection against transit node failures using facility backup for these tunnels. The procedures defined in this document include protection against delegation hop failures.
    
draft-chang-6tisch-msf-02.txt
 6TiSCH Minimal Scheduling Function (MSF)
 
 draft-chang-6tisch-msf-02.txt
 Date: 02/07/2018
 Authors: Tengfei Chang, Malisa Vucinic, Xavier Vilajosana, Simon Duquennoy, Diego Dujovne
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH.
    
draft-chen-alto-survey-00.txt
 ALTO Implementations and Use Cases: A Brief Survey
 
 draft-chen-alto-survey-00.txt
 Date: 02/07/2018
 Authors: Shiwei Chen, Xiao Lin, Danny Perez, Yang Yang, Christian Rothenberg
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides a comprehensive survey of ALTO, including current ALTO implementations and ALTO used in the literature work. This document identifies possible challenges and future opportunities of ALTO.
    
draft-chen-ati-adaptive-ipv4-address-space-03.txt
 Adaptive IPv4 Address Space
 
 draft-chen-ati-adaptive-ipv4-address-space-03.txt
 Date: 10/06/2018
 Authors: Abraham Chen, Ramamurthy Ati, Abhay Karandikar
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a solution to the Internet address depletion issue through the use of an existing Option mechanism that is part of the original IPv4 protocol. This proposal, named EzIP (phonetic for Easy IPv4), outlines the IPv4 public address pool expansion and the Internet system architecture enhancement considerations. The EzIP may expand an IPv4 address by a factor of 256M without affecting the existing IPv4 based Internet, nor the current private networks. The EzIP is in full conformance with the IPv4 protocol, and supports not only both direct and private network connectivities, but also their interoperability. The EzIP deployment may coexist with the current Internet traffic and the IoT (Internet of Things) operations without perturbing their setups, while offering end-users the freedom to choose either. If the IPv4 public pool allocations were allowed to be reorganized, the assignable pool could be multiplied by 512M times or even more. The EzIP may be implemented as a software / firmware enhancement to the Internet edge routers or private network routing gateways wherever needed, or simply installed as an inline adjunct hardware module between the two, enabling a seamless introduction. The 256M case detailed herein establishes a complete sphere of routers for interfacing between the Internet core fabic and the end user premises. Incorporating the caching proxy technology in the gateway, a fairly large geographical area may enjoy an EzIP based sub-Internet operating from as few as one ordinary IPv4 public address. This will immediately resolve the IPv4 address shortage anywhere, while transparent to the current Internet operation. Under the Dual-Stack environment, these proposed interim facilities will relieve the IPv4 address shortage issue, while affording the IPv6 more time to orderly reach the maturity and the availability levels required for delivering a long-term general service.
    
draft-chen-bfd-unsolicited-03.txt
 Unsolicited BFD for Sessionless Applications
 
 draft-chen-bfd-unsolicited-03.txt
 Date: 03/08/2018
 Authors: Enke Chen, Naiming Shen, Robert Raszuk
 Working Group: Individual Submissions (none)
 Formats: txt
For operational simplification of "sessionless" applications using BFD, in this document we present procedures for "unsolicited BFD" that allow a BFD session to be initiated by only one side, and be established without explicit per-session configuration or registration by the other side (subject to certain per-interface or per-router policies).
    
draft-chen-bier-rpcs-yang-01.txt
 YANG Data Model for BIER RPCs
 
 draft-chen-bier-rpcs-yang-01.txt
 Date: 28/08/2018
 Authors: Ran Chen, Min Gu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for BIER RPCs.
    
draft-chen-isis-black-hole-avoid-03.txt
 Avoiding Traffic Black-Holes for Route Aggregation in IS-IS
 
 draft-chen-isis-black-hole-avoid-03.txt
 Date: 06/09/2018
 Authors: Zhe Chen, Xiaohu Xu, Dean Cheng
 Working Group: Individual Submissions (none)
 Formats: xml txt
When the Intermediate System to Intermediate System (IS-IS) routing protocol is adopted by a highly symmetric network such as the Leaf- Spine or Fat-Tree network, the Leaf nodes (e.g., Top of Rack switches in datacenters) are recommended to be prevented from receiving other nodes' explicit routes in order to achieve scalability. However, such a setup would cause traffic black-holes or suboptimal routing if link failure happens in the network. This document introduces INFINITE cost to IS-IS LSPs to solve this problem.
    
draft-chen-nfsv4-rocev2-cm-problem-statement-00.txt
 Problem Statement of RoCEv2 Congestion Management
 
 draft-chen-nfsv4-rocev2-cm-problem-statement-00.txt
 Date: 10/08/2018
 Authors: Fei Chen, Wenhao Sun
 Working Group: Individual Submissions (none)
 Formats: txt
On IP-routed datacenter networks, RDMA is deployed using RoCEv2 protocol. RoCEv2 specification does not define the congestion management and load balancing methods. RoCEv2 relies on the existing Link-Layer Flow-Control IEEE 802.1Qbb(Priority-based Flow Control, PFC)to provide a lossless network. RoCEv2 Congestion Management(RCM) use ECN(Explicit Congestion Notification, defined in RFC3168) to signal the congestion to the destination and use the congestion notification to reduce the rate of injection and increase the injection rate when the extent of congestion decreases. More and more practice of congestion management for RoCEv2 appear in the industry, such as DCQCN(Data Center Quantized Congestion Notification). There is a demanding for the new RoCE protocol(temporary alias RoCEv3) to provide stronger congestion management and load balancing mechanisms for RDMA deployment in modern datacenter.
    
draft-chen-nvo3-vxlan-yang-07.txt
 YANG Data Model for VxLAN Protocol
 
 draft-chen-nvo3-vxlan-yang-07.txt
 Date: 28/08/2018
 Authors: fangwei hu, Ran Chen, Mallik Mahalingam, Zu Qiang, Shahram Davari, Xufeng Liu
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model for VxLAN protocol.
    
draft-chen-pce-compute-backup-egress-13.txt
 Extensions to the Path Computation Element Communication Protocol (PCEP) for Backup Egress of a Traffic Engineering Label Switched Path
 
 draft-chen-pce-compute-backup-egress-13.txt
 Date: 30/04/2018
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup egress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup egress and reply to the PCC with a computation result for the backup egress.
    
draft-chen-pce-compute-backup-ingress-13.txt
 Extensions to Path Computation Element Communication Protocol (PCEP) for Backup Ingress of a Traffic Engineering Label Switched Path
 
 draft-chen-pce-compute-backup-ingress-13.txt
 Date: 30/04/2018
 Authors: Huaimo Chen
 Working Group: Individual Submissions (none)
 Formats: txt
This document presents extensions to the Path Computation Element Communication Protocol (PCEP) for a PCC to send a request for computing a backup ingress for an MPLS TE P2MP LSP or an MPLS TE P2P LSP to a PCE and for a PCE to compute the backup ingress and reply to the PCC with a computation result for the backup ingress.
    
draft-chen-pce-forward-search-p2mp-path-14.txt
 A Forward-Search P2MP TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2mp-path-14.txt
 Date: 30/04/2018
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents a forward search procedure for computing a path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP) crossing a number of domains through using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described.
    
draft-chen-pce-forward-search-p2p-path-computation-15.txt
 A Forward-Search P2P TE LSP Inter-Domain Path Computation
 
 draft-chen-pce-forward-search-p2p-path-computation-15.txt
 Date: 30/04/2018
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents a forward search procedure for computing paths for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched Paths (LSPs) crossing a number of domains using multiple Path Computation Elements (PCEs). In addition, extensions to the Path Computation Element Communication Protocol (PCEP) for supporting the forward search procedure are described.
    
draft-chen-pce-label-x-domains-08.txt
 Extensions to PCEP for Distributing Label Cross Domains
 
 draft-chen-pce-label-x-domains-08.txt
 Date: 30/04/2018
 Authors: Huaimo Chen, Autumn Liu, Fengman Xu, Mehmet Toy, Vic liu
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies extensions to PCEP for distributing labels crossing domains for an inter-domain Point-to-Point (P2P) or Point- to-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path (LSP).
    
draft-chen-pce-protection-applicability-12.txt
 The Applicability of the PCE to Computing Protection and Recovery Paths for Single Domain and Multi-Domain Networks.
 
 draft-chen-pce-protection-applicability-12.txt
 Date: 30/04/2018
 Authors: Huaimo Chen, Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. A link or node failure can significantly impact network services in large-scale networks. Therefore it is important to ensure the survivability of large scale networks which consist of various connections provided over multiple interconnected networks with varying technologies. This document examines the applicability of the PCE architecture, protocols, and procedures for computing protection paths and restoration services, for single and multi-domain networks. This document also explains the mechanism of Fast Re-Route (FRR) where a point of local repair (PLR) needs to find the appropriate merge point (MP) to do bypass path computation using PCE.
    
draft-chen-spring-anycast-sid-frr-00.txt
 Anycast-SID FRR in SR
 
 draft-chen-spring-anycast-sid-frr-00.txt
 Date: 28/08/2018
 Authors: Ran Chen, Shaofu Peng, Jie Han
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the fast redundancy protection mechanism, aimed at providing protection of the links and domain boundary nodes for network that use segment routing.
    
draft-cheng-spring-mpls-path-segment-02.txt
 Path Segment in MPLS Based Segment Routing Network
 
 draft-cheng-spring-mpls-path-segment-02.txt
 Date: 02/07/2018
 Authors: Weiqiang Cheng, Lei Wang, Han Li, Mach Chen, Royi Zigler, Shuangping Zhan, Rakesh Gandhi
 Working Group: Individual Submissions (none)
 Formats: txt
An SR path is identified by an SR segment list, one or partial segments of the list cannot uniquely identify the SR path. Path identification is the precondition of performance measurement (PM) of an SR path. This document introduces the concept of Path Segment that is used to identify an SR path. When used, it is inserted at the ingress node of the SR path and immediately follows the last segment of the SR path. The Path Segment will not be popped off until it reaches the egress of the SR path. Path segment can be used by the egress node to implement path identification hence to support SR path PM, end-2-end SR path protection and bidirectional SR paths correlation.
    
draft-cheshire-dnssd-roadmap-01.txt
 Service Discovery Road Map
 
 draft-cheshire-dnssd-roadmap-01.txt
 Date: 21/03/2018
 Authors: Stuart Cheshire
 Working Group: Extensions for Scalable DNS Service Discovery (dnssd)
 Formats: txt
Over the course of several years, a rich collection of technologies has developed around DNS-Based Service Discovery, described across multiple documents. This "Road Map" document gives an overview of how these related but separate technologies (and their documents) fit together, to facilitate service discovery in various environments.
    
draft-cheshire-sudn-ipv4only-dot-arpa-10.txt
 Special Use Domain Name 'ipv4only.arpa'
 
 draft-cheshire-sudn-ipv4only-dot-arpa-10.txt
 Date: 02/07/2018
 Authors: Stuart Cheshire, David Schinazi
 Working Group: Individual Submissions (none)
 Formats: txt xml
The specification for how a client discovers its network's NAT64 prefix [RFC7050] defines the special name 'ipv4only.arpa' for this purpose, but declares it to be a non-special name in that specification's Domain Name Reservation Considerations section. Consequently, despite the well articulated special purpose of the name, '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 formally declares the actual special properties of the name, and adds similar declarations for the corresponding reverse mapping names.
    
draft-chodorek-traffic-flow-option-09.txt
 An IP option for describing the traffic flow
 
 draft-chodorek-traffic-flow-option-09.txt
 Date: 25/07/2018
 Authors: Robert Chodorek
 Working Group: Individual Submissions (none)
 Formats: txt
Information about the behavior of the stream that will be transmitted in the near future will allow for better management of queues in the router and thus improve QoS and reduce the potential for a serious overload. Such information is often available in the transmitter. The proposed IP option allows for the sending of information about forthcoming traffic from the transmitter to the intermediate nodes.
    
draft-chodorek-tsvwg-rsvp-dynamic-resv-06.txt
 RSVP Extensions for Dynamic Reservation
 
 draft-chodorek-tsvwg-rsvp-dynamic-resv-06.txt
 Date: 13/05/2018
 Authors: Robert Chodorek, Agnieszka Chodorek
 Working Group: Individual Submissions (none)
 Formats: txt
RSVP reservations are static in nature and typically last for the whole session. The proposed extension to the RSVP allows the RSVP to make elastic adjustments to reservations for the current demand of network resources. The proposed method dynamically changes the RSVP reservations on the basis of knowledge about transmitted traffic.
    
draft-choi-anima-trust-networking-00.txt
 Trust networking and procedures for Autonomic Networking
 
 draft-choi-anima-trust-networking-00.txt
 Date: 02/07/2018
 Authors: Taesang Choi, Taesoo Chung, Junkyun Choi, Jaeseob Han, Woo Chun
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes trust networking as an application of autonomic networking. The objective of trustworthy autonomic networking is providing trust networking environment where all autonomic nodes can communicate without any security concern. It defines a trust networking domain and describes how to configure and maintain the trust networking domain. While communication within the trust networking domain is done with trust, the communication with external nodes should be done via a specific autonomic service agent (ASA) called "trust gateway". The trust gateway ASA performs trust evaluation of the external nodes and enforces domain specific policies to keep the domain trustworthy.
    
draft-chuang-bimi-certificate-00.txt
 Brand Indicator for Message Identification in X.509 certificates
 
 draft-chuang-bimi-certificate-00.txt
 Date: 07/05/2018
 Authors: Wei Chuang, Thede Loder
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a X.509 certificate profile to distinguish those carrying logotypes and using email domain based authentication from other usages.
    
draft-chunduri-idr-bgp-ls-nspfid-00.txt
 BGP Link-State extensions for NSPF ID
 
 draft-chunduri-idr-bgp-ls-nspfid-00.txt
 Date: 02/04/2018
 Authors: Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: txt
Non Shortest Paths (NSPs) used in routing protocols e.g. by the link state routing protocols (IS-IS, OSPFv2 and OSPFv3) within IGP topologies. NSPs help to reduce the data plane path overhead, mitigate from MTU issues as well as performance related issues in certain data planes and allows granular traffic accounting in the network. NSPs are created locally by operator or can be provisioned through PCE or Yang from outside. This document describes a mechanism by which NSP information currently active in the network using the BGP routing protocol by defining extensions to BGP Link- state address-family.
    
draft-chunduri-isis-preferred-path-routing-00.txt
 Preferred Path Routing (PPR) in IS-IS
 
 draft-chunduri-isis-preferred-path-routing-00.txt
 Date: 18/06/2018
 Authors: Uma Chunduri, Richard Li, Russ White, Jeff Tantsura, Luis Contreras, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR) mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to IS-IS advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chunduri-lsr-isis-mt-deployment-cons-00.txt
 IS-IS Multi Topology Deployment Considerations
 
 draft-chunduri-lsr-isis-mt-deployment-cons-00.txt
 Date: 24/04/2018
 Authors: Uma Chunduri, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes IS-IS Multi Topology (MT) considerations in various deployments (Core/Mobile Backhaul/Data Center underlay). This document explores nuances around various IS-IS address families, topologies and considerations while choosing the right combination for a specific DC/mobile backhaul deployment.
    
draft-chunduri-lsr-isis-preferred-path-routing-01.txt
 Preferred Path Routing (PPR) in IS-IS
 
 draft-chunduri-lsr-isis-preferred-path-routing-01.txt
 Date: 02/07/2018
 Authors: Uma Chunduri, Renwei Li, Russ White, Jeff Tantsura, Luis Contreras, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR) mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to IS-IS advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chunduri-lsr-isis-prefix-multi-algo-00.txt
 Multiple Algorithm support for IS-IS Prefixes
 
 draft-chunduri-lsr-isis-prefix-multi-algo-00.txt
 Date: 17/04/2018
 Authors: Uma Chunduri, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies an extension to Intermediate System to Intermediate System (IS-IS) protocol by adding an Algorithm support for prefixes advertised. This allows multiple independent algorithm usage for computing the reachability of nodes and prefixes as opposed to only one algorithm.
    
draft-chunduri-lsr-ospf-preferred-path-routing-01.txt
 Preferred Path Routing (PPR) in OSPF
 
 draft-chunduri-lsr-ospf-preferred-path-routing-01.txt
 Date: 02/07/2018
 Authors: Uma Chunduri, Yingzhen Qu, Russ White, Jeff Tantsura, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR) mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments with OSPFv2 and OSPFv3 protocols. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to OSPF advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chunduri-ospf-lsr-preferred-path-routing-00.txt
 Preferred Path Routing (PPR) in OSPF
 
 draft-chunduri-ospf-lsr-preferred-path-routing-00.txt
 Date: 18/06/2018
 Authors: Uma Chunduri, Yingzhen Qu, Russ White, Jeff Tantsura, Luis Contreras
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a Preferred Path Routing (PPR) mechanism to simplify the path description of data plane traffic in Segment Routing (SR) deployments with OSPFv2 and OSPFv3 protocols. PPR aims to mitigate the MTU and data plane processing issues that may result from SR packet overheads; and also supports traffic measurement, accounting statistics and further attribute extensions along the paths. Preferred Path Routing is achieved through the addition of descriptions to OSPF advertised prefixes, and mapping those to a PPR data-plane identifier.
    
draft-chung-dtn-extension-prophet-icn-02.txt
 Extension of Probabilistic Routing Protocol using History of Encounters and Transitivity for Information Centric Network
 
 draft-chung-dtn-extension-prophet-icn-02.txt
 Date: 02/07/2018
 Authors: Yun Chung, Min Kang, Young-Han Kim
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes extension of probabilistic routing protocol using history of encounters and transitivity (PRoPHET) for information centric network.
    
draft-clacla-netmod-model-catalog-03.txt
 YANG module for yangcatalog.org
 
 draft-clacla-netmod-model-catalog-03.txt
 Date: 03/04/2018
 Authors: Joe Clarke, Benoit Claise
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document specifies a YANG module that contains metadata related to YANG modules and vendor implementations of those YANG modules.
    
draft-clacla-netmod-yang-model-update-06.txt
 New YANG Module Update Procedure
 
 draft-clacla-netmod-yang-model-update-06.txt
 Date: 02/07/2018
 Authors: Benoit Claise, Joe Clarke, Balazs Lengyel, Kevin D'Souza
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies a new YANG module update procedure in case of backward-incompatible changes, as an alternative proposal to the YANG 1.1 specifications. This document updates RFC 7950.
    
draft-clausen-lln-rpl-experiences-11.txt
 Observations on RPL: IPv6 Routing Protocol for Low power and Lossy Networks
 
 draft-clausen-lln-rpl-experiences-11.txt
 Date: 27/03/2018
 Authors: Thomas Clausen, Axel Verdiere, Jiazi Yi, Ulrich Herberg, Yuichi Igarashi
 Working Group: Individual Submissions (none)
 Formats: txt
With RPL - the "IPv6 Routing Protocol for Low-power Lossy Networks" - published as a Proposed Standard after a ~2-year development cycle, this document presents an observation of the resulting protocol, of its applicability, and of its limits. The documents presents a selection of observations on the protocol characteristics, exposes experiences acquired when producing various prototype implementations of RPL, and presents results obtained from testing this protocol - by way of network simulations, in network testbeds and in deployments. The document aims at providing a better understanding of possible limits of RPL, notably the possible directions that further protocol developments should explore, in order to address these.
    
draft-clemm-netmod-nmda-diff-00.txt
 Comparison of NMDA datastores
 
 draft-clemm-netmod-nmda-diff-00.txt
 Date: 12/06/2018
 Authors: Alexander Clemm, Yingzhen Qu, Jeff Tantsura, Andy Bierman
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines an RPC operation to compare management datastores that comply with the NMDA architecture.
    
draft-clemm-netmod-push-smart-filters-00.txt
 Smart Filters for Push Updates
 
 draft-clemm-netmod-push-smart-filters-00.txt
 Date: 02/07/2018
 Authors: Alexander Clemm, Eric Voit, Xufeng Liu, Igor Bryskin, Tianran Zhou, Guangying Zheng, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG model for Smart Filters for push updates. Smart Filters allow to filter push updates based on values of pushed datastore nodes and/or state, such as previous updates. Smart Filters provide an important building block for service assurance and network automation. This revision of the document is intended as a placeholder, containing the problem statement of draft-clemm-netconf-push-smart- filters-ps-00 that has recently expired. The YANG model itself still needs to be defined.
    
draft-clemm-nmrg-dist-intent-01.txt
 Clarifying the Concepts of Intent and Policy
 
 draft-clemm-nmrg-dist-intent-01.txt
 Date: 18/07/2018
 Authors: Alexander Clemm, Laurent Ciavaglia, Lisandro Granville
 Working Group: Individual Submissions (none)
 Formats: xml txt
Intent and Intent-Based Networking are taking the industry by storm. At the same time, those terms are used loosely and often inconsistently, in many cases overlapping with other concepts such as "policy". This document is therefore intended to clarify the concept of "Intent" and how it relates to other concepts. The goal is to contribute towards a common and shared understanding of terms and concepts which can then be used as foundation to guide further definition of valid research and engineering problems and their solutions.
    
draft-cls-ppr-te-attributes-00.txt
 Resources for Preferred Path Routes in IGPs
 
 draft-cls-ppr-te-attributes-00.txt
 Date: 16/07/2018
 Authors: Uma Chunduri, Renwei Li, Kevin Smith
 Working Group: Individual Submissions (none)
 Formats: txt
Preferred Path Routing (PPR) is concerned with setting up the route for a given prefix as specified in the path description along with a corresponding data plane/forwarding identifier PPR-ID. This document specifies an extension to PPR, a mechanism to perform resource reservations nodes on Preferred Path Routes (PPR) for IGPs (IS-IS, OSPFv2, OSPFv3). This is done by specifying the resources that need to be reserved along the path using PPR path attributes.
    
draft-clt-dmm-tn-aware-mobility-01.txt
 Transport Network aware Mobility for 5G
 
 draft-clt-dmm-tn-aware-mobility-01.txt
 Date: 16/07/2018
 Authors: Uma Chunduri, Renwei Li, Jeff Tantsura, Luis Contreras, Xavier de Foy
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a framework and a mapping function for 5G mobile user plane with transport network slicing, integrated with Mobile Radio Access and a Virtualized Core Network. The integrated approach specified in a way to address all the mobility scenarios defined in [TS23.501] and to be backward compatible with LTE [TS.23.401-3GPP] network deployments. It focuses on an optimized mobile user plane functionality with various transport services needed for some of the 5G traffic needing low and deterministic latency, real-time, mission-critical services. This document describes, how this objective is achieved agnostic to the transport underlay used (IPv4, IPv6, MPLS) in various deployments and with a new transport network underlay routing, called Preferred Path Routing (PPR).
    
draft-contreras-layered-sdn-02.txt
 Cooperating Layered Architecture for SDN
 
 draft-contreras-layered-sdn-02.txt
 Date: 02/07/2018
 Authors: Luis Contreras, Carlos Bernardos, Diego Lopez, Mohamed Boucadair, Paola Iovanna
 Working Group: Individual Submissions (none)
 Formats: txt xml
Software Defined Networking (SDN) proposes the separation of the control plane from the data plane in the network nodes and its logical centralization on a control entity. Most of the network intelligence is moved to this functional entity. Typically, such entity is seen as a compendium of interacting control functions in a vertical, tight integrated fashion. The relocation of the control functions from a number of distributed network nodes to a logical central entity conceptually places together a number of control capabilities with different purposes. As a consequence, the existing solutions do not provide a clear separation between transport control and services that relies upon transport capabilities. This document describes a proposal named Cooperating Layered Architecture for SDN. The idea behind that is to differentiate the control functions associated to transport from those related to services, in such a way that they can be provided and maintained independently, and can follow their own evolution path.
    
draft-cooper-wugh-github-wg-configuration-00.txt
 GitHub Configuration for IETF Working Groups
 
 draft-cooper-wugh-github-wg-configuration-00.txt
 Date: 14/09/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-ct-isis-nspfid-for-sr-paths-01.txt
 Usage of Non Shortest Path Forwarding (NSPF) IDs in IS-IS
 
 draft-ct-isis-nspfid-for-sr-paths-01.txt
 Date: 23/03/2018
 Authors: Uma Chunduri, Jeff Tantsura, Yingzhen Qu
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the advertisement of Non Shortest Path Forwarding IDentifier (NSPF ID) TLV and the computation procedures for the same in IS-IS protocol. NSPF ID allows to simplify the data plane path description of data traffic in SR deployments. This helps mitigate the MTU issues that are caused by additional SR overhead of the packet and allows traffic statistics.
    
draft-ct-ospf-nspfid-for-sr-paths-00.txt
 Usage of Non Shortest Path Forwarding (NSPF) IDs in OSPF
 
 draft-ct-ospf-nspfid-for-sr-paths-00.txt
 Date: 24/03/2018
 Authors: Uma Chunduri, Yingzhen Qu, Jeff Tantsura
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the advertisement of Non Shortest Path Forwarding IDentifier (NSPF ID) TLV and the computation procedures for the same in OSPFv2 and OSPFv3 protocols. NSPF ID allows to simplify the data plane path description of data traffic in SR deployments. This helps to mitigate the MTU issues that are caused by additional SR overhead of the packet and allows traffic statistics.
    
draft-cuspdt-rtgwg-cu-separation-bng-architecture-01.txt
 Architecture for Control Plane and User Plane Separated BNG
 
 draft-cuspdt-rtgwg-cu-separation-bng-architecture-01.txt
 Date: 02/07/2018
 Authors: Shujun Hu, Fengwei Qin, Zhenqiang Li, Tee Chua, Zitao Wang, Jun Song
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the new architecture of BNG devices with control plane (CP) and user plane (UP) separation. BNG-CP is a user control management component while BNG-UP takes responsibility as the network edge and user policy implementation component. Both BNG-CP and BNG-UP are core components for fixed broadband services and deployed separately at different network layer in actual network.
    
draft-cuspdt-rtgwg-cu-separation-bng-protocol-01.txt
 Control-Plane and User-Plane separation BNG control channel Protocol
 
 draft-cuspdt-rtgwg-cu-separation-bng-protocol-01.txt
 Date: 02/07/2018
 Authors: Shujun Hu, Zitao Wang, Fengwei Qin, Zhenqiang Li, Jun Song, Tee Chua
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the CU Separation BNG control channel Protocol (CUSP) for communications between a Control Plane (CP) and a set of User Planes (UPs). CUSP is designed to be flexible and extensible so as to easily allow for the addition of further messages and objects, should further requirements be expressed in the future.
    
draft-cuspdt-rtgwg-cu-separation-infor-model-02.txt
 Information Model of Control-Plane and User-Plane separation BNG
 
 draft-cuspdt-rtgwg-cu-separation-infor-model-02.txt
 Date: 02/07/2018
 Authors: Shujun Hu, 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 the operation expense, the Control-Plane and User-Plane separation conception is raised [TR-384]. This document describes the information model for the interface between Control-Plane and User-Plane separation BNG. This information model may involve both control channel interface and configuration channel interface. The interface for control channel allows the Control-Plane to send several flow tables to the User- Plane, such as user's information table, user's interface table, and user's QoS table, etc. And it also allows the User-Plane to report the resources and statistics information to the Control-Plane. The interface for configuration channel is in charge of the version negotiation of protocols between the Control-Plane and User-Plane, the configuration for devices of Control-Plane and User-Plane, and the reports of User-Plane's capabilities, etc. The information model defined in this document enables defining a standardized data model. Such a data model can be used to define an interface to the CU separation BNG.
    
draft-cuspdt-rtgwg-cu-separation-yang-model-00.txt
 YANG Data Model for Configuration Interface of Control-Plane and User- Plane separation BNG
 
 draft-cuspdt-rtgwg-cu-separation-yang-model-00.txt
 Date: 21/08/2018
 Authors: fangwei hu, RongRong Hua, Sujun Hu, Fengwei Qin
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines the YANG data model for operation management of Control-Plane and User-Plane separation BNG (Broadband Network Gateway).
    
draft-cuspdt-rtgwg-cusp-requirements-02.txt
 Requirements for Control Plane and User Plane Separated BNG Protocol
 
 draft-cuspdt-rtgwg-cusp-requirements-02.txt
 Date: 02/07/2018
 Authors: Sujun Hu, Victor Lopezalvarez, Fengwei Qin, Zhenqiang Li, Tee Chua, Zitao Wang, Jun Song
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document introduces the Control Plane and User Plane separated BNG architecture and defines a set of associated terminology. What's more, this document focuses on defining a set of protocol requirements for the BNG-CP and BNG-UPs communication in the Control Plane and User Plane Separated BNG.
    
draft-dansarie-nts-00.txt
 Network Time Security for the Network Time Protocol
 
 draft-dansarie-nts-00.txt
 Date: 02/07/2018
 Authors: Daniel Franke, Dieter Sibold, Kristof Teichel, Marcus Dansarie, Ragnar Sundblad
 Working Group: Network Time Protocol (ntp)
 Formats: txt pdf xml
This memo specifies Network Time Security (NTS), a mechanism for using Transport Layer Security (TLS) and Authenticated Encryption with Associated Data (AEAD) to provide cryptographic security for the client-server mode of the Network Time Protocol (NTP). NTS is structured as a suite of two loosely coupled sub-protocols: the NTS Key Establishment Protocol (NTS-KE) and the NTS Extension Fields for NTPv4. NTS-KE handles NTS service authentication, initial handshaking, and key extraction over TLS. Encryption and authentication during NTP time synchronization is performed through the NTS Extension Fields in otherwise standard NTP packets. Except for during the initial NTS-KE process, all state required by the protocol is held by the client in opaque cookies.
    
draft-daveor-cgn-logging-04.txt
 Approaches to Address the Availability of Information in Criminal Investigations Involving Large-Scale IP Address Sharing Technologies
 
 draft-daveor-cgn-logging-04.txt
 Date: 12/04/2018
 Authors: David O'Reilly
 Working Group: Individual Submissions (none)
 Formats: xml txt
The use of large-scale IP address sharing technologies (commonly known as "Carrier-Grade NAT" and "A+P") presents a challenge for law enforcement agencies due to the fact that incoming source port information is not routinely logged by Internet-facing servers. The absence of this information means that it is becoming increasingly difficult for law enforcement agencies to identify suspects in criminal activity online. This document considers the reasons why source port information is not routinely logged by Internet-facing servers and makes recommendations to help improve the situation. A deployment maturity model has been developed and a study of the support for logging incoming source port information in common server software is also presented.
    
draft-daveor-ipv6-crime-attribution-00.txt
 Analysis of the Crime Attribution Characteristics of Various IPv6 Address Assignment Techniques
 
 draft-daveor-ipv6-crime-attribution-00.txt
 Date: 25/04/2018
 Authors: David O'Reilly
 Working Group: Individual Submissions (none)
 Formats: xml txt
The migration from IPv4 to IPv6 is intended to fix a large number of problems with IPv4 that have been identified through many years of global use, not least of which is the shortage of available IPv4 addresses. One of the challenges with IPv4 that has not, apparently, been adequately considered is the crime attribution characteristics of IPv6 technologies. The challenge of crime attribution on the Internet is an important one and a careful balance needs to be struck between the needs of law enforcement, the rights of crime victims and the right to privacy of the vast majority of Internet users who have no involvement in any sort of criminality. The purpose of this document is to consider the crime attribution characteristics of various IPv6 address assignment techniques.
    
draft-daveor-slaac-privacy-logging-00.txt
 A Model for Storing IPv6 Stateless Address Autoconfiguration Crime Attribution Records in a Privacy Sensitive Way
 
 draft-daveor-slaac-privacy-logging-00.txt
 Date: 28/05/2018
 Authors: David O'Reilly
 Working Group: Individual Submissions (none)
 Formats: xml txt
The need for individual right to privacy and the need for law enforcement to be able to effectively investigate crime are sometimes portrayed as being irreconcilably in direct conflict with each other. Both needs are legitimate and ignoring the challenges presented by areas of conflict will not make the problem go away. The document presents a conceptual model that allows for both sets of requirements to be met simultaneously. The reason for this publication is to show that, with some creative thinking, it is possible to identify win-win solutions that simultaneously achieve both privacy and law enforcement goals.
    
draft-davidben-tls-universal-psk-00.txt
 Universal PSKs for TLS
 
 draft-davidben-tls-universal-psk-00.txt
 Date: 14/06/2018
 Authors: David Benjamin
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes universal PSKs (Pre-Shared Keys) for TLS. Universal PSKs abstract the TLS 1.3 requirement that each PSK can only be used with a single hash function. This allows PSKs to be provisioned without depending on details of the TLS negotiation, which may change as TLS evolves. Additionally, this document describes a compatibility profile for using TLS 1.3 with PSKs provisioned for the TLS 1.2 PSK mechanism.
    
draft-dawes-sipcore-mediasec-parameter-08.txt
 Security Mechanism Names for Media
 
 draft-dawes-sipcore-mediasec-parameter-08.txt
 Date: 16/05/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-dawkins-panrg-what-not-to-do-01.txt
 Path Aware Networking: A Bestiary of Roads Not Taken
 
 draft-dawkins-panrg-what-not-to-do-01.txt
 Date: 18/06/2018
 Authors: Spencer Dawkins
 Working Group: Path Aware Networking RG (panrg)
 Formats: xml txt
At the first meeting of the proposed Path Aware Networking Research Group, Oliver Bonaventure led a discussion of our mostly-unsuccessful attempts to exploit Path Awareness to achieve a variety of goals, over the past decade. At the end of that discussion, the research group agreed to catalog and analyze these ideas, to extract insights and lessons for path-aware networking researchers. This document contains that catalog and analysis.
    
draft-dawra-idr-bgp-ls-sr-service-segments-00.txt
 BGP-LS Advertisement of Segment Routing Service Segments
 
 draft-dawra-idr-bgp-ls-sr-service-segments-00.txt
 Date: 16/07/2018
 Authors: Gaurav Dawra, Clarence Filsfils, daniel.bernier@bell.ca, Jim Uttaro, Bruno Decraene, Hani Elmalky, Xiaohu Xu, Francois Clad, Ketan Talaulikar
 Working Group: Individual Submissions (none)
 Formats: txt
BGP Link-State (BGP-LS) enables distribution of topology information from the network to a Path Computation Engine (PCE) or any controller/application in general so it can learn the network topology. Service functions are deployed as virtualized elements along with network elements or on servers in data centers. The advertisement of such attached service capabilities along with the network nodes that they are attached to or associated with enable their discovery and for programming of service paths that use these service functions. Segment Routing (SR) bring in the concept of segments which can be topological or service instructions. SR Policies enable setup of paths which are a mix of topological and service segments. This document specifies the extensions to BGP-LS for discovery and advertisement of service segments so as to enable setup of service programming paths using Segment Routing.
    
draft-dawra-idr-bgpls-srv6-ext-04.txt
 BGP Link State extensions for IPv6 Segment Routing(SRv6)
 
 draft-dawra-idr-bgpls-srv6-ext-04.txt
 Date: 03/09/2018
 Authors: Gaurav Dawra, Clarence Filsfils, Ketan Talaulikar, Mach Chen, daniel.bernier@bell.ca, Jim Uttaro, Bruno Decraene, Hani Elmalky
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing IPv6 (SRv6) allows for a flexible definition of end- to-end paths within various topologies by encoding paths as sequences of topological or functional sub-paths, called "segments". These segments are advertised by the various protocols such as BGP, ISIS and OSPFv3. BGP Link-state (BGP-LS) address-family solution for SRv6 is similar to BGP-LS for SR for MPLS dataplane. This draft defines extensions to the BGP-LS to advertise SRv6 Segments along with there functions and other attributes via BGP.
    
draft-dawra-idr-srv6-vpn-04.txt
 BGP Signaling of IPv6-Segment-Routing-based VPN Networks
 
 draft-dawra-idr-srv6-vpn-04.txt
 Date: 26/06/2018
 Authors: Gaurav Dawra, Clarence Filsfils, Darren Dukes, Patrice Brissette, Pablo Camarillo, John Leddy, daniel.voyer@bell.ca, daniel.bernier@bell.ca, Dirk Steinberg, Robert Raszuk, Bruno Decraene, Satoru Matsushima, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines procedures and messages for BGP SRv6-based L3VPN and EVPN. It builds on RFC4364 "BGP/MPLS IP Virtual Private Networks (VPNs)" and RFC7432 "BGP MPLS-Based Ethernet VPN" and provides a migration path from MPLS-based VPNs to SRv6 based VPNs.
    
draft-deconinck-quic-multipath-01.txt
 Multipath Extension for QUIC
 
 draft-deconinck-quic-multipath-01.txt
 Date: 04/09/2018
 Authors: Quentin Coninck, Olivier Bonaventure
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes extensions to the QUIC protocol to enable the usage of multiple paths over a single connection. Those changes remain compliant with the current single-path QUIC design. They allow devices to benefit from multiple network paths while preserving the privacy features of QUIC.
    
draft-defoy-mptcp-considerations-for-5g-01.txt
 Considerations for MPTCP operation in 5G
 
 draft-defoy-mptcp-considerations-for-5g-01.txt
 Date: 22/06/2018
 Authors: Xavier de Foy, Michelle Perras, Uma Chunduri, Kien Nguyen, Mirza Kibria, Kentaro Ishizu, Fumihide Kojima
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes scenarios where the behavior of the 5G mobility management framework is different from earlier cellular generations, and describes how it may benefit from some form of adaptation of MPTCP implementations and protocol aspects in the 5G system. This document also describes how MPTCP may be leveraged in 5G system specifications.
    
draft-dejong-remotestorage-11.txt
 remoteStorage
 
 draft-dejong-remotestorage-11.txt
 Date: 07/06/2018
 Authors: Michiel de Jong, F. Kooman
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes a protocol by which client-side applications, running inside a web browser, can communicate with a data storage server that is hosted on a different domain name. This way, the provider of a web application need not also play the role of data storage provider. The protocol supports storing, retrieving, and removing individual documents, as well as listing the contents of an individual folder, and access control is based on bearer tokens.
    
draft-deshpande-intarea-ipaddress-reclassification-02.txt
 IP address space reclassification
 
 draft-deshpande-intarea-ipaddress-reclassification-02.txt
 Date: 11/09/2018
 Authors: Vineet Deshpande
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes an AI based TCP-IP model. By understanding how the Network is evolving from a Wireless and Software perspective the limitations of current Internet Architecture are identified and the corrections needed for the Big Data bottleneck present in current Internet Architecture are described further. This draft explains about the implicit life cycle between the Cloud, Network and Internet. An important conclusion is drawn that the Network cannot be declassified from the Cloud. Based on the evolution of the Virtualized Datacenter within the Cloud architecture framework and the implicit fact that the Network also needs to grow and scale towards the Cloud another important conclusion that the whole Topological address space which is the current IP address space (IP as well as IPv6) needs to be reclassified or divided into a physical (or logical) address space and a new Virtual address space. The Virtual address space is a Centralized Control plane which only processes routing information. A future Internet architecture for resolving the Big Data bottleneck which introduces a Virtual address space at specific Intersection points such as Inter-AS, CsC and IXP (Internet Exchange Points) is described.
    
draft-deutch-lamps-client-app-encrypt-00.txt
 Client Application Layer Encryption
 
 draft-deutch-lamps-client-app-encrypt-00.txt
 Date: 24/08/2018
 Authors: Benjamin Deutsch
 Working Group: Individual Submissions (none)
 Formats: txt
The protocol for Client Application Layer Encryption offers organizations a method of securely providing users data with very few authentication steps. This protocol makes use of X.509 public key infrastructure and SHOULD NOT be implemented without transport layer security. The protocol described below helps to ensure that response messages may only be read by the intended recipient.
    
draft-dharini-ccamp-dwdm-if-param-yang-05.txt
 A YANG model to manage the optical interface parameters for an external transponder in a WDM network
 
 draft-dharini-ccamp-dwdm-if-param-yang-05.txt
 Date: 25/06/2018
 Authors: Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a Yang model related to the Optical Transceiver parameters characterising coherent 100G and above interfaces. 100G and above Transceivers support coherent modulation, multiple modulation formats, multiple FEC codes including some not yet specified (or by in phase of specification by) ITU-T G.698.2 [ITU.G698.2] or any other ITU-T recommendation. More context about the state of the Coherent transceivers is described in draft-many- coherent-DWDM-if-control. Use cases are described in RFC7698 The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the endpoints of a multi-vendor IaDI optical link.
    
draft-dharinigert-ccamp-dwdm-if-lmp-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-dharinigert-ccamp-dwdm-if-lmp-07.txt
 Date: 25/06/2018
 Authors: Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze, Dieter Beller
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) systems in accordance with the Interface Application Identifier approach defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its extensions.
    
draft-dhjain-spring-bgp-sr-yang-00.txt
 YANG data model for BGP Segment Routing Extensions
 
 draft-dhjain-spring-bgp-sr-yang-00.txt
 Date: 26/06/2018
 Authors: Dhanendra Jain, Kamran Raza, Bruno Decraene, Zhichun Jiang
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage Segment Routing extensions in BGP.
    
draft-dhody-pce-pcep-pmtu-00.txt
 Support for Path MTU (PMTU) in the Path Computation Element Communication Protocol (PCEP).
 
 draft-dhody-pce-pcep-pmtu-00.txt
 Date: 01/07/2018
 Authors: Dhruv Dhody, Cheng Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Path Computation Element (PCE) provides path computation functions in support of traffic engineering in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. The Source Packet Routing in Networking (SPRING) architecture describes how Segment Routing (SR) can be used to steer packets through an IPv6 or MPLS network using the source routing paradigm. A Segment Routed Path can be derived from a variety of mechanisms, including an IGP Shortest Path Tree (SPT), explicit configuration, or a Path Computation Element (PCE). Since the SR does not require signaling, the path maximum transmission unit (MTU) information for SR path is not available. This document specify the extension to PCE communication protocol (PCEP) to carry path (MTU) in the PCEP messages.
    
draft-dhody-pce-stateful-pce-interdomain-07.txt
 Stateful Path Computation Element (PCE) Inter-domain Considerations
 
 draft-dhody-pce-stateful-pce-interdomain-07.txt
 Date: 29/08/2018
 Authors: Dhruv Dhody, Xian Zhang
 Working Group: Individual Submissions (none)
 Formats: xml txt
A stateful Path Computation Element (PCE) maintains information about Label Switched Path (LSP) characteristics and resource usage within a network in order to provide traffic engineering path calculations for its associated Path Computation Clients (PCCs). Furthermore, PCEs are used to compute shortest constrained Traffic Engineering Label Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) networks across multiple domains. This document describes general considerations for the deployment of stateful PCE(s) in inter-domain scenarios including inter-area and inter-AS. The inter-layer considerations will be described in a separate document. This document does not specify any extensions to PCEP.
    
draft-dhody-pce-stateful-pce-optional-01.txt
 Extension for Stateful PCE to allow Optional Processing of PCEP Objects.
 
 draft-dhody-pce-stateful-pce-optional-01.txt
 Date: 20/06/2018
 Authors: Dhruv Dhody, Stephane Litkowski
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document introduces a mechanism to mark some Path Computation Element (PCE) Communication Protocol (PCEP) objects as optional during PCEP messages exchange for the Stateful PCE model to allow relaxing some constraints.
    
draft-dhody-pce-stateful-pce-vendor-05.txt
 Conveying Vendor-Specific Information in the Path Computation Element (PCE) Communication Protocol (PCEP) extensions for stateful PCE.
 
 draft-dhody-pce-stateful-pce-vendor-05.txt
 Date: 29/08/2018
 Authors: Dhruv Dhody
 Working Group: Individual Submissions (none)
 Formats: txt xml
A Stateful Path Computation Element (PCE) maintains information on the current network state, including: computed Label Switched Path (LSPs), reserved resources within the network, and pending path computation requests. This information may then be considered when computing new traffic engineered LSPs, and for associated and dependent LSPs, received from Path Computation Clients (PCCs). RFC 7470 defines a facility to carry vendor-specific information in PCEP. This document extends this capability for the stateful PCE model.
    
draft-dhodylee-pce-pcep-ls-11.txt
 PCEP Extension for Distribution of Link-State and TE Information.
 
 draft-dhodylee-pce-pcep-ls-11.txt
 Date: 21/06/2018
 Authors: Dhruv Dhody, Young Lee, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: txt xml
In order to compute and provide optimal paths, Path Computation Elements (PCEs) require an accurate and timely Traffic Engineering Database (TED). Traditionally this TED has been obtained from a link state (LS) routing protocol supporting traffic engineering extensions. This document extends the Path Computation Element Communication Protocol (PCEP) with Link-State and TE Information.
    
draft-dickinson-doh-dohpe-00.txt
 DoHPE: DoH with Privacy Enhancements
 
 draft-dickinson-doh-dohpe-00.txt
 Date: 18/07/2018
 Authors: Sara Dickinson, Willem Toorop
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes DoHPE (DoH with Privacy Enhancements) - a privacy and anonymity profile for DoH [I-D.ietf-doh-dns-over-https] clients. The profile provides guidelines on the composition of DoH messages, designed to minimize disclosure of identifying information.
    
draft-ding-dinrg-biot-00.txt
 Blockchain-based IoT Infrastructure Functional Requirements
 
 draft-ding-dinrg-biot-00.txt
 Date: 14/09/2018
 Authors: Hui Ding, Zhenzhen Jiao
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This document specifies the functional requirements for a Blockchain-based IoT infrastructure, including the IoT device identity management, service demand and supply matching, support of smart contract, etc.
    
draft-dinh-icnrg-sdnnfvicn-00.txt
 Considerations for Using SDN/NFV in ICN
 
 draft-dinh-icnrg-sdnnfvicn-00.txt
 Date: 01/07/2018
 Authors: Thanh Dinh, Young-Han Kim
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides considerations for using Software-Defined Networking (SDN) / Network Function Virtualization (NFV) in Information- Centric Networking (ICN).
    
draft-divination-cfapi-00.txt
 An API For Calendar-Based Fortune Heuristics Services
 
 draft-divination-cfapi-00.txt
 Date: 22/03/2018
 Authors: Gabriel Destiny, Charise Luck
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a JSON HTTP API for online services that provide calendar-based fortune heuristics.
    
draft-dm-net2cloud-gap-analysis-01.txt
 Gap Analysis of Interconnecting Underlay with Cloud Overlay
 
 draft-dm-net2cloud-gap-analysis-01.txt
 Date: 06/08/2018
 Authors: Linda Dunbar, Andrew Malis, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the technological gaps when using SD-WAN to interconnect workloads & apps hosted in various locations, especially cloud data centers when the network service providers do not have or have limited physical infrastructure to reach the locations [Net2Cloud-problem].
    
draft-dm-net2cloud-problem-statement-02.txt
 Seamless Interconnect Underlay to Cloud Overlay Problem Statement
 
 draft-dm-net2cloud-problem-statement-02.txt
 Date: 02/07/2018
 Authors: Linda Dunbar, Andrew Malis, Christian Jacquenet, Mehmet Toy
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the problems of enterprises face today in connecting their branch offices to dynamic workloads in commercial cloud data centers (DCs). It examines some of the approaches for interconnecting workloads & applications hosted in cloud DCs with enterprises' on-premises DCs & branch offices. This document also describes some of the (network) problems that many enterprises face when they have workloads & applications & data split among hybrid data centers, especially for those enterprises with multiple sites that are already interconnected by VPNs (e.g. MPLS L2VPN/L3VPN) and leased lines. Current operational problems in the field are examined to determine whether there is a need for enhancements to existing protocols or whether a new protocol is necessary to solve them.
    
draft-dold-payto-01.txt
 The 'payto' URI scheme for payments
 
 draft-dold-payto-01.txt
 Date: 07/04/2018
 Authors: Florian Dold, Christian Grothoff
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines the 'payto' Uniform Resource Identifier (URI) scheme for specifying payments.
    
draft-dolson-transport-middlebox-03.txt
 An Inventory of Transport-centric Functions Provided by Middleboxes
 
 draft-dolson-transport-middlebox-03.txt
 Date: 20/06/2018
 Authors: David Dolson, Juho Snellman, Mohamed Boucadair, Christian Jacquenet
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document summarizes benefits that operators perceive to be provided by intermediary devices that execute functions beyond normal IP forwarding. Such intermediary devices are often called "middleboxes". RFC3234 defines a taxonomy of middleboxes and issues in the Internet. Most of those middleboxes utilize or modify application-layer data. This document primarily focuses on devices that observe and act on information carried in the transport layer, and especially information carried in TCP packets. A primary goal of this document is to provide information to working groups developing new transport protocols, to aid understanding of what might be gained or lost by design decisions that may affect (or be affected by) middlebox operation.
    
draft-dong-i2nsf-asf-config-00.txt
 Configuration of Advanced Security Functions with I2NSF Security Controller
 
 draft-dong-i2nsf-asf-config-00.txt
 Date: 30/06/2018
 Authors: Yue Dong, Liang Xia
 Working Group: Individual Submissions (none)
 Formats: xml txt
This draft defines a network security function (NSF-) facing interface of the security controller for the purpose of configuring some advanced security functions. These advanced security functions include antivirus, anti-ddos, and intrusion prevention system (IPS). The interface is presented in a YANG data model fashion and can be used to deploy a large amount of NSF blocks that all support above mentioned functions in the software defined network (SDN) based paradigm.
    
draft-dong-lsr-sr-enhanced-vpn-00.txt
 IGP Extensions for Segment Routing based Enhanced VPN
 
 draft-dong-lsr-sr-enhanced-vpn-00.txt
 Date: 20/06/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 and RFC 4915, can be extended to signal the resources allocated in the underlay network to construct the virtual networks for enhanced VPN services, together with the Segment Routing Identifiers (SIDs) used to identify and access the network resources allocated for the virtual networks in the data plane.
    
draft-dong-sacm-nid-infra-security-baseline-01.txt
 The Data Model of Network Infrastructure Device Infrastructure Layer Security Baseline
 
 draft-dong-sacm-nid-infra-security-baseline-01.txt
 Date: 24/05/2018
 Authors: Yue Dong, Liang Xia
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is one of the companion documents which describes the infrastructure layer security baseline YANG output for network infrastructure devices. The infrastructure layer security baseline covers the security functions to secure the device itself, and the fundamental security capabilities provided by the device to the upper layer applications. In this specific document, the integrity measurement, cryptography algorithms, key management, and certificate management are sorted out to generate the data model.
    
draft-dong-spring-sr-for-enhanced-vpn-01.txt
 Segment Routing for Enhanced VPN Service
 
 draft-dong-spring-sr-for-enhanced-vpn-01.txt
 Date: 02/07/2018
 Authors: Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka
 Working Group: Individual Submissions (none)
 Formats: txt
Enhanced VPN (VPN+) is an enhancement to VPN technology to enable it to support the needs of new applications, particularly applications that are associated with 5G services. These applications require better isolation and have more stringent performance requirements than can be provided with overlay VPNs. The characteristics of an enhanced VPN as perceived by its tenant needs to be comparable to those of a dedicated private network. This requires tight integration between the overlay VPN and the underlay network resources in a scalable manner. An enhanced VPN may form the underpin of 5G network slicing, but will also be of use in its own right. This document describes the use of segment routing based mechanisms to provide the enhanced VPN service with dedicated network resources.
    
draft-dong-teas-enhanced-vpn-01.txt
 A Framework for Enhanced Virtual Private Networks (VPN+)
 
 draft-dong-teas-enhanced-vpn-01.txt
 Date: 15/08/2018
 Authors: Jie Dong, Stewart Bryant, Zhenqiang Li, Takuya Miyasaka
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a framework for using existing, modified and potential new networking technologies as components to provide an enhanced VPN (VPN+) service. The purpose is to enable virtual private networks (VPNs) to support the needs of new applications, particularly applications that are associated with 5G services. A network enhanced with these properties can form the underpinning of network slicing, but will also be of use in its own right.
    
draft-donnerhacke-linktax-01.txt
 Rights for restricted content
 
 draft-donnerhacke-linktax-01.txt
 Date: 28/06/2018
 Authors: Lutz Donnerhacke
 Working Group: Individual Submissions (none)
 Formats: xml txt
Links are omnipresent in the Internet to provide access to other resources. There is no mechanism to express differences in law systems, access limitations, or arbitrary rules defined by the owner of the linked resource. Therefore links do depend on and enforce a communist sharing ideology, which ignores the content owner rights. Links may point to resources far away from the originating page, hiding this fact from the customer. It takes the data transport services for free, internet transit providers on the way from the content source to the customers are not extra payed for this effort. In many cases, the remote company generates huge amount of money from the customers worldwide not shared with the transit providers. In order to get the rights of all involved parties balanced, a new type of connection initiation is proposed: The Right.
    
draft-dorfner-core-simplemetadata-00.txt
 SimpleMetadata: An interoperable format for sharing metadata
 
 draft-dorfner-core-simplemetadata-00.txt
 Date: 16/04/2018
 Authors: Ralf Dorfner
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a container format for storing serializable metadata. It shall provide the possibility to store and share any kind of metadata, including encryption support. The idea is to create an open, universal and interoperable standard for storing and distributing every kind of metadata independent from media type or file format.
    
draft-douglass-serverside-subscriptions-00.txt
 Serverside Subscriptions
 
 draft-douglass-serverside-subscriptions-00.txt
 Date: 04/09/2018
 Authors: Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This specification provides a mechanism whereby subscriptions to external resources can be handled by the server. This specification updates [RFC4791] to add new properies for the MKCOL request.
    
draft-douglass-subscription-upgrade-03.txt
 Calendar subscription upgrades
 
 draft-douglass-subscription-upgrade-03.txt
 Date: 05/05/2018
 Authors: Michael Douglass
 Working Group: Individual Submissions (none)
 Formats: txt xml
This specification introduces an approach to allow subscribers to calendar feeds to upgrade to a more performant protocol. This specification updates [RFC5545] to add the value DELETED to the STATUS property.
    
draft-dreibholz-ipv4-flowlabel-28.txt
 An IPv4 Flowlabel Option
 
 draft-dreibholz-ipv4-flowlabel-28.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This draft defines an IPv4 option containing a flowlabel that is compatible to IPv6. It is required for simplified usage of IntServ and interoperability with IPv6.
    
draft-dreibholz-rserpool-applic-distcomp-25.txt
 Applicability of Reliable Server Pooling for Real-Time Distributed Computing
 
 draft-dreibholz-rserpool-applic-distcomp-25.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the applicability of the Reliable Server Pooling architecture to manage real-time distributed computing pools and access the resources of such pools.
    
draft-dreibholz-rserpool-applic-mobility-24.txt
 Applicability of Reliable Server Pooling for SCTP-Based Endpoint Mobility
 
 draft-dreibholz-rserpool-applic-mobility-24.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz, Jobin Pulinthanath
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a novel mobility concept based on a combination of SCTP with Dynamic Address Reconfiguration extension and Reliable Server Pooling (RSerPool).
    
draft-dreibholz-rserpool-asap-hropt-23.txt
 Handle Resolution Option for ASAP
 
 draft-dreibholz-rserpool-asap-hropt-23.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Handle Resolution option for the ASAP protocol.
    
draft-dreibholz-rserpool-delay-22.txt
 Definition of a Delay Measurement Infrastructure and Delay-Sensitive Least-Used Policy for Reliable Server Pooling
 
 draft-dreibholz-rserpool-delay-22.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz, Xing Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document contains the definition of a delay measurement infrastructure and a delay-sensitive Least-Used policy for Reliable Server Pooling.
    
draft-dreibholz-rserpool-enrp-takeover-20.txt
 Takeover Suggestion Flag for the ENRP Handle Update Message
 
 draft-dreibholz-rserpool-enrp-takeover-20.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz, Xing Zhou
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Takeover Suggestion Flag for the ENRP_HANDLE_UPDATE message of the ENRP protocol.
    
draft-dreibholz-rserpool-nextgen-ideas-10.txt
 Ideas for a Next Generation of the Reliable Server Pooling Framework
 
 draft-dreibholz-rserpool-nextgen-ideas-10.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document collects some idea for a next generation of the Reliable Server Pooling framework.
    
draft-dreibholz-rserpool-score-23.txt
 Reliable Server Pooling (RSerPool) Bakeoff Scoring
 
 draft-dreibholz-rserpool-score-23.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz, Michael Tuexen
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes some of the scoring to be used in the testing of Reliable Server Pooling protocols ASAP and ENRP at upcoming bakeoffs.
    
draft-dreibholz-taps-neat-socketapi-03.txt
 NEAT Sockets API
 
 draft-dreibholz-taps-neat-socketapi-03.txt
 Date: 07/06/2018
 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-08.txt
 Ideas for a Next Generation of the Stream Control Transmission Protocol (SCTP)
 
 draft-dreibholz-tsvwg-sctp-nextgen-ideas-08.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document collects some ideas for a next generation of the Stream Control Transmission Protocol (SCTP) for further discussion. It is a result of lessons learned from more than one decade of SCTP deployment.
    
draft-dreibholz-tsvwg-sctpsocket-multipath-17.txt
 SCTP Socket API Extensions for Concurrent Multipath Transfer
 
 draft-dreibholz-tsvwg-sctpsocket-multipath-17.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz, Martin Becke, Hakim Adhari
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes extensions to the SCTP sockets API for configuring the CMT-SCTP and CMT/RP-SCTP extensions.
    
draft-dreibholz-tsvwg-sctpsocket-sqinfo-17.txt
 Sender Queue Info Option for the SCTP Socket API
 
 draft-dreibholz-tsvwg-sctpsocket-sqinfo-17.txt
 Date: 05/09/2018
 Authors: Thomas Dreibholz, Robin Seggelmann, Martin Becke
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an extension to the SCTP sockets API for querying information about the sender queue.
    
draft-dt-iasa20-proposal-00.txt
 Proposed Structure of the IETF Administrative Organization
 
 draft-dt-iasa20-proposal-00.txt
 Date: 05/04/2018
 Authors: Joseph Hall, Brian Haberman, Jari Arkko, Leslie Daigle, Jason Livingood, Eric Rescorla
 Working Group: Individual Submissions (none)
 Formats: txt xml
The IETF Administrative Support Activity (IASA) was originally established in 2005. In the intervening years, the needs of the IETF have evolved in ways that require changes to its administrative structure. The IETF Chair started an effort in November of 2016 to begin the process of changing the IETF administrative structure, starting with a set of virtual workshops to get input from the IETF community, and then encompassing a series of BOF sessions at IETF meetings to define the problem, develop requirements, explore potential options for changes, and a Design Team - the authors of this document - that would make recommendations. The purpose of this document is to collect all of the various materials that have lead up to the Design Team recommendation that IETF be a Disregarded Limited Liability Company (LLC) of the Internet Society.
    
draft-dugeon-pce-stateful-interdomain-01.txt
 PCEP Extension for Stateful Inter-Domain Tunnels
 
 draft-dugeon-pce-stateful-interdomain-01.txt
 Date: 02/07/2018
 Authors: Olivier Dugeon, Julien Meuric, Young Lee, Dhruv Dhody, Daniele Ceccarelli
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document proposes to combine a Backward Recursive or Hierarchical method in Stateful PCE with PCInitiate message to setup independent paths per domain, and combine these different paths together in order to operate them as end-to-end inter-domain paths without the need of signaling session between AS border routers. A new Stitching Label is defined and new LSP-TYPE code points are considered for that purpose.
    
draft-duke-quic-load-balancers-02.txt
 QUIC-LB: Generating Routable QUIC Connection IDs
 
 draft-duke-quic-load-balancers-02.txt
 Date: 17/09/2018
 Authors: Martin Duke
 Working Group: Individual Submissions (none)
 Formats: txt
QUIC connection IDs allow continuation of connections across address/ port 4-tuple changes, and can store routing information for stateless or low-state load balancers. They also can prevent linkability of connections across deliberate address migration through the use of protected communications between client and server. This creates issues for load-balancing intermediaries. This specification standardizes methods for encoding routing information and proposes an optional protocol called QUIC_LB to exchange the parameters of that encoding.
    
draft-dukes-spring-mtu-overhead-analysis-01.txt
 Comparative Analysis of MTU overhead in the context of SPRING
 
 draft-dukes-spring-mtu-overhead-analysis-01.txt
 Date: 14/09/2018
 Authors: Darren Dukes, Clarence Filsfils, Pablo Camarillo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document provides an apples-to-apples comparative analysis of MTU overhead in the context of SPRING.
    
draft-dukes-spring-sr-for-sdwan-00.txt
 SR For SDWAN: VPN with Underlay SLA
 
 draft-dukes-spring-sr-for-sdwan-00.txt
 Date: 05/06/2018
 Authors: Darren Dukes, Clarence Filsfils, Gaurav Dawra, Xiaohu Xu, daniel.voyer@bell.ca, Pablo Camarillo, Francois Clad, Stefano Salsano
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes how SR enables underlay Service Level Agreements (SLA) to a VPN with scale and security while ensuring service opacity. This solution applies to Over-The-Top VPN (OTT VPN) and Software-Defined WAN (SDWAN).
    
draft-dulaunoy-dnsop-passive-dns-cof-04.txt
 Passive DNS - Common Output Format
 
 draft-dulaunoy-dnsop-passive-dns-cof-04.txt
 Date: 21/06/2018
 Authors: Alexandre Dulaunoy, Aaron Kaplan, Paul Vixie, Henry Stern
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes a common output format of Passive DNS Servers which clients can query. The output format description includes also in addition a common semantic for each Passive DNS system. By having multiple Passive DNS Systems adhere to the same output format for queries, users of multiple Passive DNS servers will be able to combine result sets easily.
    
draft-dulaunoy-misp-core-format-05.txt
 MISP core format
 
 draft-dulaunoy-misp-core-format-05.txt
 Date: 08/08/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP core format used to exchange indicators and threat information between MISP (Malware Information and threat Sharing Platform) instances. The JSON format includes the overall structure along with the semantic associated for each respective key. The format is described to support other implementations which reuse the format and ensuring an interoperability with existing MISP [MISP-P] software and other Threat Intelligence Platforms.
    
draft-dulaunoy-misp-galaxy-format-04.txt
 MISP galaxy format
 
 draft-dulaunoy-misp-galaxy-format-04.txt
 Date: 23/08/2018
 Authors: Alexandre Dulaunoy, Andras Iklody, Deborah Servili
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP galaxy format which describes a simple JSON format to represent galaxies and clusters that can be attached to MISP events or attributes. A public directory of MISP galaxies is available and relies on the MISP galaxy format. MISP galaxies are used to add further informations on a MISP event. MISP galaxy is a public repository [MISP-G] [MISP-G-DOC] of known malware, threats actors and various other collections of data that can be used to mark, classify or label data in threat information sharing.
    
draft-dulaunoy-misp-object-template-format-01.txt
 MISP object template format
 
 draft-dulaunoy-misp-object-template-format-01.txt
 Date: 10/04/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP object template format which describes a simple JSON format to represent the various templates used to construct MISP objects. A public directory of common vocabularies MISP object templates [MISP-O] is available and relies on the MISP object reference format.
    
draft-dulaunoy-misp-taxonomy-format-05.txt
 MISP taxonomy format
 
 draft-dulaunoy-misp-taxonomy-format-05.txt
 Date: 01/06/2018
 Authors: Alexandre Dulaunoy, Andras Iklody
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the MISP taxonomy format which describes a simple JSON format to represent machine tags (also called triple tags) vocabularies. A public directory of common vocabularies MISP taxonomies is available and relies on the MISP taxonomy format. MISP taxonomies are used to classify cyber security events, threats or indicators.
    
draft-dunbar-e2e-latency-arch-view-and-gaps-02.txt
 Architectural View of E2E Latency and Gaps
 
 draft-dunbar-e2e-latency-arch-view-and-gaps-02.txt
 Date: 30/08/2018
 Authors: Linda Dunbar
 Working Group: Individual Submissions (none)
 Formats: txt
Ultra-Low Latency is a highly desired property for many types of services, such as 5G MTC (Machine Type Communication) requiring E2E connection for V2V to be less than 2ms, AR/VR requiring delay less than 5ms, V2X less than 20ms, etc. This draft examines the E2E latency from architectural perspective, from studying how different OSI layers contribute to E2E latency, how different domains, which can be different operators' domains or administrative domains, contribute to E2E latency, to analyzing the gaps of recent technology advancement in reducing latency. By studying the contributing factors to E2E latency from various angles, the draft identifies some gaps of recent technology advancement for E2E services traversing multiple domains and involving multiple layers. The discussion might touch upon multiple IETF areas.
    
draft-dunbar-sr-sdwan-over-hybrid-networks-02.txt
 Segment routing for SD-WAN paths over hybrid networks
 
 draft-dunbar-sr-sdwan-over-hybrid-networks-02.txt
 Date: 02/07/2018
 Authors: Linda Dunbar, Mehmet Toy
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a method for end-to-end (E2E) SD-WAN paths (most likely encrypted) to traverse specific list of network segments, some of which are SR enabled and others may be IP networks that do not support SR, to achieve the desired optimal E2E quality. The method described in this draft uses the principle of segment routing to enforce a SD-WAN path' head-end selected route traversing through a list of specific nodes of multiple network segments without requiring the nodes in each network segment to have the intelligence (or maintaining states) of selecting next hop or next domain. Those networks over which the SD-WAN path traverse have at least one SR enabled network, and some network segments (especially the last mile access portion) being existing IP networks (such as existing IPv4, IPv6 or others).
    
draft-dykim-6man-sid6-00.txt
 Subnet ID Deprecation for IPv6
 
 draft-dykim-6man-sid6-00.txt
 Date: 03/09/2018
 Authors: DY Kim
 Working Group: Individual Submissions (none)
 Formats: txt xml
Deprecation of the subnet ID in IPv6 networking is proposed; the subnet ID is set to zero so that all nodes in a site carry the same prefix. While the procedures for neighbor discovery and duplicate address detection have to be changed, possible simplification gains in IPv6 networking including that of intra-site host- and subnet- mobility might be worth the modification. Site-external behaviors don't change through this modification, enabling incremental deployment of the proposal. Sites of manageable sizes for which scalability is not much a critical issue might consider the mode of operation proposed in this document.
    
draft-eastlake-bess-enhance-evpn-all-active-01.txt
 EVPN All Active Usage Enhancement
 
 draft-eastlake-bess-enhance-evpn-all-active-01.txt
 Date: 05/09/2018
 Authors: Donald Eastlake, Zhenbin Li, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: txt
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) active with all-active links. This draft specifies an improvement to load balancing such links.
    
draft-eastlake-bess-evpn-vxlan-bypass-vtep-01.txt
 EVPN VXLAN Bypass VTEP
 
 draft-eastlake-bess-evpn-vxlan-bypass-vtep-01.txt
 Date: 16/07/2018
 Authors: Donald Eastlake, Zhenbin Li, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
A principal feature of EVPN is the ability to support multihoming from a customer equipment (CE) to multiple provider edge equipment (PE) with all-active links. This draft specifies a mechanism to simplify PEs used with VXLAN tunnels and enhance VXLAN Active-Active reliability.
    
draft-eastlake-fnv-15.txt
 The FNV Non-Cryptographic Hash Algorithm
 
 draft-eastlake-fnv-15.txt
 Date: 12/06/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-07.txt
 Additional XML Security Uniform Resource Identifiers (URIs)
 
 draft-eastlake-rfc6931bis-xmlsec-uris-07.txt
 Date: 04/04/2018
 Authors: Donald Eastlake
 Working Group: Individual Submissions (none)
 Formats: txt
This document updates and corrects the IANA registry for the list of URIs intended for use with XML digital signatures, encryption, canonicalization, and key management. These URIs identify algorithms and types of information. This document corrrects three errata against and obsoletes RFC 6931. The intent is to keep this draft alive while it accumulates updates until it seems reasonable to publish the next version.
    
draft-eastlake-sfc-nsh-ecn-support-01.txt
 Explicit Congestion Notification (ECN) and Congestion Feedback Using the Network Service Header (NSH)
 
 draft-eastlake-sfc-nsh-ecn-support-01.txt
 Date: 02/07/2018
 Authors: Donald Eastlake, Bob Briscoe, Andrew Malis
 Working Group: Individual Submissions (none)
 Formats: txt
Explicit congestion notification (ECN) allows a forwarding element to notify downstream devices of the onset of congestion without having to drop packets. Coupled with a means to expose congestion by feeding back information about it to upstream nodes, this can improve network efficiency through better congestion control, frequently without packet drops. This document specifies ECN and congestion feedback support through use of the Network Service Header (NSH, RFC 8300) and IP Flow Information Export (IPFIX, draft-ietf-tsvwg-tunnel- congestion-feedback).
    
draft-eckert-anima-grasp-dnssd-01.txt
 DNS-SD compatible service discovery in GRASP
 
 draft-eckert-anima-grasp-dnssd-01.txt
 Date: 01/07/2018
 Authors: Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: xml txt
DNS Service Discovery (DNS-SD) defines the common framework for applications to announce and discover services. This includes service names, service instance names, common parameters for selecting a service instance (weight, priority) as well as service specific parameters. GRASP is intended to also be used for service discovery. Reinventing service discovery for GRASP with a similar set of fetures would result in duplication of work. Therefore, this document defines how to use GRASP to announce and discover services in a way that inherits DNS-SD features and also tries to be compatible in spirit as much as possibel while still maintaining the intended simplicity of GRASP. The goal of this document is to permit defining service and their parameters once and then use that in GRASP, mDNS and (unicast) DNS. Future work can also define DNS-SD <-> GRASP gateway functions. In support of service discovery, this document also defines name discovery and schemes for reuseable elements in GRASP objectives which are designed to be extensible so that future work that identifies elements required across multiple objectives do not need to define a scheme how to do this.
    
draft-eckert-anima-noc-autoconfig-00.txt
 Autoconfiguration of NOC services in ACP networks via GRASP
 
 draft-eckert-anima-noc-autoconfig-00.txt
 Date: 02/07/2018
 Authors: Toerless Eckert
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document defines standards for the autoconfiguration of crucial NOC services on ACP nodes via GRASP. It enables secure remote access to zero-touch bootstrapped ANI devices via SSH/Netconf with Radius/ Diameter authentication and authorization and provides lifecycle autoconfiguration for other crucial services such as syslog, NTP (clock synchronization) and DNS for operational purposes.
    
draft-edwards-telnet-xon-xoff-state-control-00.txt
 Xon/Xoff State Control for Telnet Com Port Control Option
 
 draft-edwards-telnet-xon-xoff-state-control-00.txt
 Date: 23/03/2010
 Authors: Grant Edwards
 Working Group: Individual Submissions (none)
 Formats: pdf txt
This document defines new values for use with the telnet com port control option's SET-CONTROL sub-command defined in RFC2217. These new values provide a mechanism for the telnet client to control and query the outbound Xon/Xoff flow control state of the telnet server's physical serial port. This capability is exposed in the serial port API on some operating systems and is needed by telnet clients that implement a port-redirector service which provides applications local to the redirector/telnet-client with transparent access to the remote serial port on the telnet server.
    
draft-ekwk-capport-rfc7710bis-00.txt
 Captive-Portal Identification in DHCP / RA
 
 draft-ekwk-capport-rfc7710bis-00.txt
 Date: 15/07/2018
 Authors: Warren Kumari, Erik Kline
 Working Group: Individual Submissions (none)
 Formats: txt xml
In many environments offering short-term or temporary Internet access (such as coffee shops), it is common to start new connections in a captive portal mode. This highly restricts what the customer can do until the customer has authenticated. This document describes a DHCP option (and a Router Advertisement (RA) extension) to inform clients that they are behind some sort of captive-portal device, and that they will need to authenticate to get Internet access. It is not a full solution to address all of the issues that clients may have with captive portals; it is designed to be used in larger solutions. The method of authenticating to, and interacting with the captive portal is out of scope of this document. [ This document is being collaborated on in Github at: https://github.com/wkumari/draft-ekwk-capport-rfc7710bis. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. Text in square brackets will be removed before publication. ]
    
draft-elders-social-media-apology-00.txt
 Social Media (An Apology)
 
 draft-elders-social-media-apology-00.txt
 Date: 16/07/2018
 Authors: The Internet
 Working Group: Individual Submissions (none)
 Formats: txt
Oops, we did it again.
    
draft-elris-hrpc-righttolife-00.txt
 Right to Life Issues in Internet Content and Protocols
 
 draft-elris-hrpc-righttolife-00.txt
 Date: 05/08/2018
 Authors: Nalini Elkins, William Jouris
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a new IANA registry of Guidance for Blocked Content. Blocked Content is content which has no significant valid use and conflicts with the "Universal Declaration of Human Rights" . The format of the proposed registry is provided, and some initial categories; for example, human trafficking and 3d printed guns.
    
draft-emailwhois-pradeepkumarxplorer-00.txt
 Extensions to WHois service to allow query on email identities
 
 draft-emailwhois-pradeepkumarxplorer-00.txt
 Date: 23/07/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-erdtman-jose-cleartext-jws-01.txt
 Cleartext JSON Web Signature (JWS)
 
 draft-erdtman-jose-cleartext-jws-01.txt
 Date: 06/09/2018
 Authors: Samuel Erdtman, Anders Rundgren, Michael Jones
 Working Group: Individual Submissions (none)
 Formats: txt xml
Cleartext JSON Web Signature (JWS) is a means of signing JSON objects directly without representing the JSON to be signed in a non-JSON representation, such as base64url-encoded JSON. The signature and information about the signature is added to the JSON object when it is signed. The signature calculation for signing the JSON object uses the JSON canonicalization defined by [I-D.rundgren-json-canonicalization-scheme]. Cleartext JWS builds on the JWS, JWA, and JWK specifications, reusing data structures and semantics from these specifications, where applicable.
    
draft-ermagan-lisp-nat-traversal-14.txt
 NAT traversal for LISP
 
 draft-ermagan-lisp-nat-traversal-14.txt
 Date: 16/04/2018
 Authors: Vina Ermagan, Dino Farinacci, Darrel Lewis, Jesper Skriver, Fabio Maino, Chris White
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a mechanism for IPv4 NAT traversal for LISP tunnel routers (xTR) and LISP Mobile Nodes (LISP-MN) behind a NAT device. A LISP device both detects the NAT and initializes its state. Forwarding to the LISP device through a NAT is enabled by the LISP Re-encapsulating Tunnel Router (RTR) network element, which acts as an anchor point in the data plane, forwarding traffic from unmodified LISP devices through the NAT.
    
draft-ermagan-lisp-nsh-05.txt
 LISP Control Plane integration with NSH
 
 draft-ermagan-lisp-nsh-05.txt
 Date: 29/03/2018
 Authors: Vina Ermagan, Paul Quinn, Darrel Lewis, Fabio Maino, Florin Coras
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines extensions to the LISP control plane protocol to enable support for Network Service Header(NSH) based Service Function Chaining (SFC).
    
draft-even-avtcore-priority-markings-02.txt
 Frame Priority Marking RTP Header Extension
 
 draft-even-avtcore-priority-markings-02.txt
 Date: 24/06/2018
 Authors: Roni Even, Ofer Idan
 Working Group: Individual Submissions (none)
 Formats: pdf xml txt
This document updates the Frame Marking RTP header extension in draft-ietf-avtext-framemarking-06 used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middle-boxes or network nodes. The flags for frame marking for non-scalable streams include the D bit to mark a frame that can be discarded, and still provide a decodable media stream. There is also the I bit for frames that can be decoded independent of prior frames, e.g. intra-frame. This memo adds priority values for the non-scalable streams discardable frames
    
draft-fairhurst-tsvwg-transport-encrypt-10.txt
 The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet
 
 draft-fairhurst-tsvwg-transport-encrypt-10.txt
 Date: 28/08/2018
 Authors: Gorry Fairhurst, Colin Perkins
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes implications of applying end-to-end encryption at the transport layer. It identifies in-network uses of transport layer header information. It then reviews the implications of developing end-to-end transport protocols that use authentication to protect the integrity of transport information or encryption to provide confidentiality of the transport protocol header and expected implications of transport protocol design and network operation. Since transport measurement and analysis of the impact of network characteristics have been important to the design of current transport protocols, it also considers the impact on transport and application evolution.
    
draft-faltstrom-unicode11-01.txt
 IDNA2008 and Unicode 11.0.0
 
 draft-faltstrom-unicode11-01.txt
 Date: 02/07/2018
 Authors: Patrik Faltstrom
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes changes between Unicode 6.3.0 and Unicode 11.0.0 in the context of IDNA2008. It further suggests for the IETF a path forward regarding ensuring IDNA2008 follows the evolution of the Unicode Standard.
    
draft-farinacci-lisp-decent-01.txt
 A Decent LISP Mapping System (LISP-Decent)
 
 draft-farinacci-lisp-decent-01.txt
 Date: 02/07/2018
 Authors: Dino Farinacci, Colin Cantrell
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how the LISP mapping system designed to be distributed for scale can also be decentralized for management and trust.
    
draft-farinacci-lisp-ecdsa-auth-03.txt
 LISP Control-Plane ECDSA Authentication and Authorization
 
 draft-farinacci-lisp-ecdsa-auth-03.txt
 Date: 04/09/2018
 Authors: Dino Farinacci, Erik Nordmark
 Working Group: Individual Submissions (none)
 Formats: txt
This draft describes how LISP control-plane messages can be individually authenticated and authorized without a a priori shared- key configuration. Public-key cryptography is used with no new PKI infrastructure required.
    
draft-farinacci-lisp-geo-05.txt
 LISP Geo-Coordinate Use-Cases
 
 draft-farinacci-lisp-geo-05.txt
 Date: 16/04/2018
 Authors: Dino Farinacci
 Working Group: Locator/ID Separation Protocol (lisp)
 Formats: txt
This draft describes how Geo-Coordinates can be used in the LISP Architecture and Protocols.
    
draft-farinacci-lisp-mobile-network-04.txt
 LISP for the Mobile Network
 
 draft-farinacci-lisp-mobile-network-04.txt
 Date: 11/09/2018
 Authors: Dino Farinacci, Padma Pillay-Esnault, Uma Chunduri
 Working Group: Individual Submissions (none)
 Formats: txt
This specification describes how the LISP architecture and protocols can be used in a LTE/5G mobile network to support session survivable EID mobility. A recommendation is provided to SDOs on how to integrate LISP into the mobile network.
    
draft-farinacci-lisp-name-encoding-06.txt
 LISP Distinguished Name Encoding
 
 draft-farinacci-lisp-name-encoding-06.txt
 Date: 11/09/2018
 Authors: Dino Farinacci
 Working Group: Locator/ID Separation Protocol (lisp)
 Formats: txt
This draft defines how to use the AFI=17 Distinguished Names in LISP.
    
draft-farinacci-lisp-telemetry-00.txt
 LISP Data-Plane Telemetry
 
 draft-farinacci-lisp-telemetry-00.txt
 Date: 29/06/2018
 Authors: Dino Farinacci, Said Ouissal, Erik Nordmark
 Working Group: Individual Submissions (none)
 Formats: txt
This draft specs a JSON formatted RLOC-record for telemetry data which decapsulating xTRs include in RLOC-probe Map Reply messages.
    
draft-farmer-6man-exceptions-64-09.txt
 Exceptions to the Standard Subnet Boundary in IPv6 Addressing
 
 draft-farmer-6man-exceptions-64-09.txt
 Date: 09/08/2018
 Authors: David Farmer
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document clarifies exceptions to the standard subnet boundary in IPv6 addressing. The exceptions include unicast IPv6 addresses with the first three bits 000, manually configured addresses, DHCPv6 assigned addresses, IPv6 on-link determination, and the possibility of an exception specified in separate IPv6 link-type specific documents. Further, operational guidance is provided, and Appendix A discusses the valid options for configuring the parameters of an IPv6 subnet.
    
draft-farrel-spring-sr-domain-interconnect-04.txt
 Interconnection of Segment Routing Domains - Problem Statement and Solution Landscape
 
 draft-farrel-spring-sr-domain-interconnect-04.txt
 Date: 13/06/2018
 Authors: Adrian Farrel, John Drake
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) is a forwarding paradigm for use in MPLS and IPv6 networks. It is intended to be deployed in discrete domains that may be data centers, access networks, or other networks that are under the control of a single operator and that can easily be upgraded to support this new technology. Traffic originating in one SR domain often terminates in another SR domain, but must transit a backbone network that provides interconnection between those domains. This document describes a mechanism for providing connectivity between SR domains to enable end-to-end or domain-to-domain traffic engineering. The approach described allows connectivity between SR domains, utilizes traffic engineering mechanisms (RSVP-TE or Segment Routing) across the backbone network, makes heavy use of pre-existing technologies, and requires the specification of very few additional mechanisms. This document provides some background and a problem statement, explains the solution mechanism, gives references to other documents that define protocol mechanisms, and provides examples. It does not define any new protocol mechanisms.
    
draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt
 Control-/Data Plane Aspects for N6 Traffic Steering
 
 draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt
 Date: 20/09/2018
 Authors: Umberto Fattore, Marco Liebsch
 Working Group: Individual Submissions (none)
 Formats: txt
Current standardization effort on the evolution of the mobile communication system reconsiders the mobile data plane protocol. The IETF DMM Working Group has work that proposes and analyzes various protocols as alternative to the GPRS Tunneling Protocol for User Plane (GTP-U) for an overlay deployment in between the mobile device's assigned data plane anchor and its current radio base station, which are denoted as N9 and N3 interfaces. In the view of some future deployment and the original intent per the very early DMM WG charter, a mobile device's data plane anchor may be highly distributed and re-selected for optimization throughout a mobile device's communication with one or more correspondent services. Such re-configuration has impact on the packet routing in between the mobile device's data plane anchor and the one or multiple data networks hosting the services, which is denoted as N6 interface. This draft proposes and discusses a solution to control, setup and maintain traffic treatment policy on the cellular communication system's N6 interface while taking the UE's PDU session settings per the cellular system's control plane, such as QoS and locator information, into account.
    
draft-fear-ippm-mpdm-01.txt
 IPv6 Marking and Performance and Diagnostic Metrics (MPDM)
 
 draft-fear-ippm-mpdm-01.txt
 Date: 24/06/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-feeney-t2trg-inter-network-03.txt
 Inter-network Coexistence in the Internet of Things
 
 draft-feeney-t2trg-inter-network-03.txt
 Date: 28/05/2018
 Authors: Laura Feeney, Viktoria Fodor
 Working Group: Individual Submissions (none)
 Formats: xml txt
The breadth of IoT applications implies that there will be many diverse, administratively independent networks operating in the same physical location. In many cases, these networks will use unlicensed spectrum, due to its low cost and ease of deployment. However, this spectrum is becoming increasingly crowded. IoT networks will therefore be subject to wireless interference, both from similar networks and from networks that use the wireless channel in very different ways. High-density, heterogeneous wireless environments present formidable challenges for network coexistence. The PHY and MAC layers are primarily responsible for managing how radios use the channel. But higher layer protocols are also a key factor in inter-network interaction. To date, there have been few performance studies of coexistence in future IoT operating environments, particularly with respect to protocol behavior and network-scale interactions. This document describes key challenges for coexistence and highlights some recent research results that demonstrate the impact of protocol level interactions on network performance. It identifies both concrete and speculative opportunities for the IRTF T2TRG community. The former include developing and documenting best practices for performance evaluation and contributing IoT-related protocols being developed within IETF. The latter include speculative research into the design of high-layer protocols that allow networks to actively coordinate their access to the shared channel.
    
draft-feng-dmm-ra-prefixtype-03.txt
 Router Advertisement Prefix Option Extension for On-Demand Mobility
 
 draft-feng-dmm-ra-prefixtype-03.txt
 Date: 12/09/2018
 Authors: Wu-chi Feng, Danny Moses
 Working Group: Individual Submissions (none)
 Formats: xml txt
Router Advertisement / Router Solicitation is one of the ways for hosts to establish network IPv6 connectivity configuration. This document describes two approches to allowing a router to specify mobility service type availability to mobile hosts. Mobile hosts can then configure their IP address to the preferred type of mobile connectivity. Two possibilities are considered: (i) creating an extension to the router advertisement prefix information option to allow the router to specify mobility connectivity types, and (ii) specifying a new RA options that allows the router to specify the mobility connectivity types.
    
draft-fieau-cdni-interfaces-https-delegation-05.txt
 CDNI extensions for HTTPS delegation
 
 draft-fieau-cdni-interfaces-https-delegation-05.txt
 Date: 17/09/2018
 Authors: Frederic Fieau, Stephan Emile, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: xml txt
The delivery of content over HTTPS involving multiple CDNs raises credential management issues. This document proposes extensions in CDNI Control and Metadata interfaces to setup HTTPS delegation from an Upstream CDN (uCDN) to a Downstream CDN (dCDN).
    
draft-filsfils-spring-large-scale-interconnect-12.txt
 Interconnecting Millions Of Endpoints With Segment Routing
 
 draft-filsfils-spring-large-scale-interconnect-12.txt
 Date: 29/08/2018
 Authors: Clarence Filsfils, Stefano Previdi, Gaurav Dawra, Wim Henderickx, Dave Cooper
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an application of Segment Routing to scale the network to support hundreds of thousands of network nodes, and tens of millions of physical underlay endpoints. This use-case can be applied to the interconnection of massive-scale DCs and/or large aggregation networks. Forwarding tables of midpoint and leaf nodes only require a few tens of thousands of entries.
    
draft-filsfils-spring-sr-policy-considerations-01.txt
 SR Policy Implementation and Deployment Considerations
 
 draft-filsfils-spring-sr-policy-considerations-01.txt
 Date: 07/06/2018
 Authors: Clarence Filsfils, Ketan Talaulikar, Przemyslaw Krol, Martin Horneffer, Paul Mattes
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) allows a headend node to steer a packet flow along any path. Intermediate per-flow states are eliminated thanks to source routing. SR Policy framework enables the instantiation and the management of necessary state on the headend node for flows along a source routed paths using an ordered list of segments associated with their specific SR Policies. This document describes some of the implementation and deployment aspects that are useful for operationalizing the SR Policy architecture.
    
draft-filsfils-spring-sr-traffic-counters-00.txt
 Segment Routing Traffic Accounting Counters
 
 draft-filsfils-spring-sr-traffic-counters-00.txt
 Date: 07/06/2018
 Authors: Clarence Filsfils, Zafar Ali, Martin Horneffer, daniel.voyer@bell.ca, Muhammad Durrani, Robert Raszuk
 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. Traffic accounting plays a critical role in network operation. A traffic account solution is required for SR networks that provides the necessary functionality without creating any additional per SR path states in the fabric. This document describes counters for traffic accounting in SR networks.
    
draft-filsfils-spring-srv6-interop-01.txt
 SRv6 interoperability report
 
 draft-filsfils-spring-srv6-interop-01.txt
 Date: 11/09/2018
 Authors: Clarence Filsfils, Francois Clad, Pablo Camarillo, Ahmed Abdelsalam, Stefano Salsano, Olivier Bonaventure, Jakub Horn, Jose Liste
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment Routing (SR) can be applied to the IPv6 data plane by leveraging a new type of routing extension header, called Segment Routing Header (SRH). An SRH contains an ordered list, or sequence, of segments representing topological or service-based instructions, or any combination of those. This draft provides an overview of IPv6 Segment Routing (SRv6) implementations and interoperability. It makes an inventory of the various pieces of hardware and software that have been demonstrated to support the processing of an SRH, and details some interoperability scenarios that have been showcased at a public event.
    
draft-filsfils-spring-srv6-network-programming-05.txt
 SRv6 Network Programming
 
 draft-filsfils-spring-srv6-network-programming-05.txt
 Date: 02/07/2018
 Authors: Clarence Filsfils, Pablo Camarillo, John Leddy, daniel.voyer@bell.ca, Satoru Matsushima, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the SRv6 network programming concept and its most basic functions.
    
draft-filyurin-lisp-elp-probing-01.txt
 LISP Explicit Locator Path (ELP) Probing
 
 draft-filyurin-lisp-elp-probing-01.txt
 Date: 14/05/2018
 Authors: Yan Filyurin, Robert Raszuk, Truman Boyes, Dino Farinacci
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes a LISP-TE mechanism to probe an Explicit Locator Path (ELP) for reachability and telemetry data. The mechanism is called ELP-Probing.
    
draft-filyurin-rift-access-networks-00.txt
 RIFT -- Motivation,Additional Requirements and Use Cases in User Access Networks
 
 draft-filyurin-rift-access-networks-00.txt
 Date: 13/06/2018
 Authors: Yan Filyurin
 Working Group: Individual Submissions (none)
 Formats: txt
RIFT is a new specialized dynamic routing protocol originally designed for Clos and Fat Tree Data Center networks. It is designed to work on multilevel network topologies in which nodes in certain level will only connect to nodes in one upper or lower level with optional and non-contiguous intra-level connectivity. While the protocol was originally designed to meet the needs of Massively Scalable Data Centers, its ability to automatically prune the information distribution from higher levels to lower levels, as well as provide optimal routing for intra and inter-level traffic makes it a good match for user access networks, or any network that combines end user access and various compute enabling various network service for these end users. Current directions in distributed computing seek to blur even that distinction. Large distributed networks can be created, where virtual compute units can be in all tiers, combining and crossing many requirements for DC or User Access design. This draft seeks to analyze these requirements.
    
draft-finkelman-cdni-rr-sva-extensions-01.txt
 CDNI SVA Request Routing Extensions
 
 draft-finkelman-cdni-rr-sva-extensions-01.txt
 Date: 16/05/2018
 Authors: Ori Finkelman, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery requests from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).
    
draft-finkelman-cdni-triggers-sva-extensions-00.txt
 CDNI Triggers Interface SVA Extensions
 
 draft-finkelman-cdni-triggers-sva-extensions-00.txt
 Date: 14/06/2018
 Authors: Ori Finkelman, Sanjay Mishra
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery request from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN).
    
draft-finn-detnet-bounded-latency-01.txt
 DetNet Bounded Latency
 
 draft-finn-detnet-bounded-latency-01.txt
 Date: 02/07/2018
 Authors: Norman Finn, Jean-Yves Le Boudec, Ehsan Mohammadpour, Balazs Varga, Janos Farkas
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents a parameterized timing model for Deterministic Networking so that existing and future standards can achieve bounded latency and zero congestion loss.
    
draft-finzi-priority-switching-scheduler-02.txt
 Priority Switching Scheduler
 
 draft-finzi-priority-switching-scheduler-02.txt
 Date: 30/05/2018
 Authors: Fred Baker, Anais Finzi, Fabrice Frances, Emmanuel Lochin, Ahlem Mifdaoui
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
We detail the implementation of a network scheduler that aims at isolating time constrained and elastic traffic flows from best-effort traffic. This scheduler inherits from the priority scheduler (PS) but dynamically changes the priority of one or several queues. Usual implementations of rate scheduler schemes (such as WRR, DRR, ...) do not allow to efficiently guarantee the capacity dedicated to both AF and BE 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. To cope with this issue, this memo presents a credit based scheduler mechanism called Priority Switching Scheduler (PSS) that allows a more predictable output rate per traffic class.
    
draft-fioccola-ippm-multipoint-alt-mark-04.txt
 Multipoint Alternate Marking method for passive and hybrid performance monitoring
 
 draft-fioccola-ippm-multipoint-alt-mark-04.txt
 Date: 29/06/2018
 Authors: Giuseppe Fioccola, Mauro Cociglio, Amedeo Sapio, Riccardo Sisto
 Working Group: Individual Submissions (none)
 Formats: txt
The Alternate Marking method, as presented in RFC 8321 [RFC8321], can be applied only to point-to-point flows because it assumes that all the packets of the flow measured on one node are measured again by a single second node. This document aims to generalize and expand this methodology to measure any kind of unicast flows, whose packets can follow several different paths in the network, in wider terms a multipoint-to-multipoint network. For this reason the technique here described is called Multipoint Alternate Marking. Some definitions here introduced extend the scope of RFC 5644 [RFC5644] in the context of alternate marking schema.
    
draft-fioccola-v6ops-ipv6-alt-mark-01.txt
 IPv6 Performance Measurement with Alternate Marking Method
 
 draft-fioccola-v6ops-ipv6-alt-mark-01.txt
 Date: 05/06/2018
 Authors: Giuseppe Fioccola, Gunter Van de Velde, Mauro Cociglio, Praveen Muley
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how the alternate marking method in [RFC8321] can be used as the passive performance measurement method in an IPv6 domain, and will discuss the strengths and the weaknesses of the implementation options available to network operations. It proposes how to extend [RFC7837] to apply alternate marking technique.
    
draft-flanagan-7322bis-03.txt
 RFC Style Guide
 
 draft-flanagan-7322bis-03.txt
 Date: 03/04/2018
 Authors: Heather Flanagan, RFC Editor
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the fundamental and unique style conventions and editorial policies currently in use for the RFC Series. It captures the RFC Editor's basic requirements and offers guidance regarding the style and structure of an RFC. Additional guidance is captured on a website that reflects the experimental nature of that guidance and prepares it for future inclusion in the RFC Style Guide. This document obsoletes RFC 7322, "RFC Style Guide".
    
draft-fmm-nvo3-pm-alt-mark-02.txt
 Performance Measurement (PM) with Alternate Marking in Network Virtualization Overlays (NVO3)
 
 draft-fmm-nvo3-pm-alt-mark-02.txt
 Date: 25/06/2018
 Authors: Giuseppe Fioccola, Gregory Mirsky, Tal Mizrahi
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes how the alternate marking method can be used for performance measurement method in a Network Virtualization Overlays (NVO3) Domain. The description aims to be general for NVO3 encapsulations, but is focused to Geneve, recommended by the NVO3 design team [I-D.ietf-nvo3-encap].
    
draft-foglar-ipv6-ull-routing-03.txt
 IPv6 Source Routing for ultralow Latency
 
 draft-foglar-ipv6-ull-routing-03.txt
 Date: 30/08/2018
 Authors: Andreas Foglar, Mike Parker, Theodoros Rokkas
 Working Group: Individual Submissions (none)
 Formats: txt
This Internet-Draft describes a hierarchical addressing scheme for IPv6, intentionally very much simplified to allow for very fast source routing experimentation using simple forwarding nodes. Research groups evaluate achievable latency reduction for special applications such as radio access networks, industrial networks or other networks requiring very low latency.
    
draft-foudil-securitytxt-04.txt
 A Method for Web Security Policies
 
 draft-foudil-securitytxt-04.txt
 Date: 16/07/2018
 Authors: Edwin Foudil, Yakov Shafranovich
 Working Group: Individual Submissions (none)
 Formats: txt
When security risks are discovered by independent security researchers, they often lack the channels to disclose them properly. As a result, security issues may be left unreported. This document defines a standard ("security.txt") to help organizations describe the process for security researchers to follow in order to disclose security vulnerabilities securely.
    
draft-fregly-regext-rdap-search-regex-04.txt
 Registration Data Access Protocol (RDAP) Search Using POSIX Regular Expressions
 
 draft-fregly-regext-rdap-search-regex-04.txt
 Date: 01/06/2018
 Authors: afregly@verisign.com, Swapneel Sheth, Scott Hollenbeck
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Registration Data Access Protocol (RDAP) provides limited search functionality based on pattern matching. This document describes an RDAP query extension that provides additional search functionality using POSIX extended regular expressions.
    
draft-freytag-troublesome-characters-02.txt
 Those Troublesome Characters: A Registry of Unicode Code Points Needing Special Consideration When Used in Network Identifiers
 
 draft-freytag-troublesome-characters-02.txt
 Date: 30/06/2018
 Authors: Asmus Freytag, John Klensin, Andrew Sullivan
 Working Group: Individual Submissions (none)
 Formats: xml txt
Unicode's design goal is to be the universal character set for all applications. The goal entails the inclusion of very large numbers of characters. It is also focused on written language in general; special provisions have always been needed for identifiers. The sheer size of the repertoire increases the possibility of accidental or intentional use of characters that can cause confusion among users, particularly where linguistic context is ambiguous, unavailable, or impossible to determine. A registry of code points that can be sometimes especially problematic may be useful to guide system administrators in setting parameters for allowable code points or combinations in an identifier system, and to aid applications in creating security aids for users.
    
draft-friel-brski-over-802dot11-01.txt
 BRSKI over IEEE 802.11
 
 draft-friel-brski-over-802dot11-01.txt
 Date: 02/07/2018
 Authors: Owen Friel, Eliot Lear, Max Pritikin, Michael Richardson
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document outlines the challenges associated with implementing Bootstrapping Remote Secure Key Infrastructures over IEEE 802.11 and IEEE 802.1x networks. Multiple options are presented for discovering and authenticating to the correct IEEE 802.11 SSID. This initial draft is a discussion document and no final recommendations are made on the recommended approaches to take.
    
draft-friel-tls-atls-01.txt
 Application-Layer TLS
 
 draft-friel-tls-atls-01.txt
 Date: 31/07/2018
 Authors: Owen Friel, Richard Barnes, Max Pritikin, Hannes Tschofenig, Mark Baugher
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies how TLS sessions can be established at the application layer over untrusted transport between clients and services for the purposes of establishing secure end-to-end encrypted communications channels. Transport layer encodings for application layer TLS records are specified for HTTP and CoAP transport. Explicit identification of application layer TLS packets enables middleboxes to provide transport services and enforce suitable transport policies for these payloads, without requiring access to the unencrypted payload content. Multiple scenarios are presented identifying the need for end-to-end application layer encryption between clients and services, and the benefits of reusing the well- defined TLS protocol, and a standard TLS stack, to accomplish this are described. Application software architectures for building, and network architectures for deploying application layer TLS are outlined.
    
draft-galimbe-ccamp-iv-yang-06.txt
 A YANG model to manage the optical parameters for in a WDM network
 
 draft-galimbe-ccamp-iv-yang-06.txt
 Date: 25/06/2018
 Authors: Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert Grammel
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines a Yang model that translate the information model to support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functionality. The information model is defined in draft-ietf- ccamp-wson-iv-info and draft-martinelli-ccamp-wson-iv-encode. This document defines proper encoding and extend to the models defined in draft-lee-ccamp-wson-yang tu support Impairment-Aware (IA) Routing and Wavelength Assignment (RWA) functions The Yang model defined in this memo can be used for Optical Parameters monitoring and/or configuration of the multivendor Endpoints and ROADMs
    
draft-gandhi-spring-sr-mpls-pm-03.txt
 Performance Measurement in Segment Routing Networks with MPLS Data Plane
 
 draft-gandhi-spring-sr-mpls-pm-03.txt
 Date: 14/09/2018
 Authors: Rakesh Gandhi, Clarence Filsfils, daniel.voyer@bell.ca, Stefano Salsano, Pier Ventre, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt
RFC 6374 specifies protocol mechanisms to enable the efficient and accurate measurement of packet loss, one-way and two-way delay, as well as related metrics such as delay variation in MPLS networks using probe messages. This document reviews how these mechanisms can be used for Delay and Loss Performance Measurements (PM) in Segment Routing (SR) networks with MPLS data plane (SR-MPLS), for both SR links and end-to-end SR Policies. The performance measurements for SR links are used to compute extended Traffic Engineering (TE) metrics for delay and loss and are advertised in the network using routing protocol extensions.
    
draft-gandhi-spring-udp-pm-02.txt
 UDP Path for In-band Performance Measurement for Segment Routing Networks
 
 draft-gandhi-spring-udp-pm-02.txt
 Date: 14/09/2018
 Authors: Rakesh Gandhi, Clarence Filsfils, daniel.voyer@bell.ca, Stefano Salsano, Pier Ventre, Mach Chen
 Working Group: Individual Submissions (none)
 Formats: txt
Segment Routing (SR) is applicable to both Multiprotocol Label Switching (SR-MPLS) and IPv6 (SRv6) data planes. This document specifies procedures for using UDP path for sending and processing in-band probe query and response messages for Performance Measurement. The procedure uses the RFC 6374 defined mechanisms for Delay and Loss performance measurement. The procedure specified is applicable to SR-MPLS and SRv6 data planes for both links and end-to-end measurement for SR Policies. This document also defines mechanisms for handling Equal Cost Multipaths (ECMPs) for SR Policies. In addition, this document defines Return Path Segment List TLV for two-way performance measurement and Block Number TLV for loss measurement.
    
draft-gao-alto-fcs-06.txt
 ALTO Extension: Flow-based Cost Query
 
 draft-gao-alto-fcs-06.txt
 Date: 02/07/2018
 Authors: J. Zhang, Kai Gao, Junzhuo Wang, Qiao Xiang, Yang Yang
 Working Group: Individual Submissions (none)
 Formats: txt
ALTO cost maps and endpoint cost services map a source-destination pair into a cost value. However, current filter specifications, which define the set of source-destination pairs in an ALTO query, have two limitations: 1) Only very limited address types are supported (IPv4 and IPv6), which is not sufficient to uniquely identify a flow in networks with fine-grained routing, such as the emerging Software Defined Networks; 2) The base ALTO protocol only defines filters enumerating all sources and all destinations, leading to redundant information in the response; 3) Cannot distinguish transmission types of flows in the query, which makes the server hard to respond the accurate resource consumption. To address these three issues, this document extends the base ALTO protocol with a more fine-grained filter type which allows ALTO clients to select only the concerned source-destination pairs and announce the flow-specific information like data transmission type, and a more expressive address space which allows ALTO clients to make queries beyond the limited IP addresses.
    
draft-gao-bess-evpn-blackhole-00.txt
 EVPN blackhole community extention for Blackholing
 
 draft-gao-bess-evpn-blackhole-00.txt
 Date: 02/07/2018
 Authors: Yuan Gao, Haibo Wang
 Working Group: Individual Submissions (none)
 Formats: txt
Ethernet Virtual Private Networks (EVPN) is becoming the de-facto standard-based control plane solution for Data Center and layer-2 Service Provider applications.The risk of hacking and DDos attacks within the EVPN network is general common concern.Blackhole mac is a method used to block hacking or DDos attacks, The network device discard the packets where the source or destionation match the blackhole mac.Normally blackhole mac is mannually configured on the networkdevic,Configure blackhole mac is complex and error-prone task for network operators.This document introduces a blackhole community extension for evpn mac route to distribute the blackhole mac in the EVPN networks.The evpn mac route with blackhole community allows the bgp speaker to notify the recipients the specific mac is a blackhole mac.
    
draft-gao-flexible-session-protocol-00.txt
 Flexible Session Protocol
 
 draft-gao-flexible-session-protocol-00.txt
 Date: 15/07/2018
 Authors: Jason Gao
 Working Group: Individual Submissions (none)
 Formats: txt
FSP is a connection-oriented transport layer protocol that provides support for mobility, multi-homing and multi-path by introducing the concept of 'upper layer thread ID'. It introduces the concept of transmit transaction to facilitate a quad-party sub-protocol of 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-garciamorchon-t2trg-automated-iot-security-00.txt
 Automated IoT Security
 
 draft-garciamorchon-t2trg-automated-iot-security-00.txt
 Date: 02/07/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 and and many standardization steps for providing security have been taken, for example, the specification of Constrained Application Protocol (CoAP) over Datagram Transport Layer Security (DTLS). However, 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 has three main parts: First, it summarizes exemplary security threats and suitable mitigation strategies to protect against multiple types of threats. Second, it describes a comprehensive agile security framework to integrate existing security processes such as risk asssement or vulnerability assessment in the lifecycle of a smart object in an IoT application. Thus, instead of having a security configuration that is fixed at manufacturing time, our approach allows us to apply a - security profile - on the device tailored for a specific environment at any point of time. Third, we discuss the concept of security profiles and give examples of them. 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). PACS 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 profile to defeat the identified risks. The assigned security profile 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. We describe a few examplary security profiles that could be applicable in different application areas and automatically configured by means of PASC and PAVA.
    
draft-geng-bier-sr-multicast-deployment-00.txt
 MVPN using Segment Routing and BIER for High Reachability Multicast Deployment
 
 draft-geng-bier-sr-multicast-deployment-00.txt
 Date: 02/07/2018
 Authors: Liang Geng, Lei Wang, Jingrong Xie, Mike McBride, Gang Yan
 Working Group: Individual Submissions (none)
 Formats: xml txt
Bit Index Explicit Replication (BIER) introduces a stateless multicast approach for a specific IGP area. Segment Routing introduces an approach for end-to-end stateless deployment for both inter-area and inter-as scenarios. This document proposes a MVPN using Segment Routing and BIER for a high reachability multicast deployment.
    
draft-geng-detnet-conf-yang-04.txt
 DetNet Configuration YANG Model
 
 draft-geng-detnet-conf-yang-04.txt
 Date: 10/09/2018
 Authors: Xuesong Geng, Mach Chen, Zhenqiang Li, Reshad Rahman
 Working Group: Deterministic Networking (detnet)
 Formats: txt xml
This document defines a YANG data model for Deterministic Networking (DetNet), which includes the DetNet topology YANG module, DetNet flow configuration YANG module and DetNet Transport QoS YANG Module. The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).
    
draft-geng-detnet-requirements-bounded-latency-00.txt
 Technical Requirements of Bounded Latency in Large-scale DetNet Deployment
 
 draft-geng-detnet-requirements-bounded-latency-00.txt
 Date: 02/07/2018
 Authors: Liang Geng, Lei Wang, Li Qiang
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document summarizes the technical requirements of bounded latency of DetNet system in large-scale deployment.
    
draft-geng-pim-bier-sr-multicast-deployment-00.txt
 MVPN using Segment Routing and BIER for High Reachability Multicast Deployment
 
 draft-geng-pim-bier-sr-multicast-deployment-00.txt
 Date: 02/07/2018
 Authors: Liang Geng, Lei Wang, Jingrong Xie, Mike McBride, Gang Yan
 Working Group: Individual Submissions (none)
 Formats: txt xml
Bit Index Explicit Replication (BIER) introduces a stateless multicast approach for a specific IGP area. Segment Routing introduces an approach for end-to-end stateless deployment for both inter-area and inter-as scenarios. This document proposes a MVPN using Segment Routing and BIER for a high reachability multicast deployment.
    
draft-ggalimbe-ccamp-flex-if-lmp-05.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-05.txt
 Date: 25/06/2018
 Authors: Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti, Ruediger Kunze
 Working Group: Individual Submissions (none)
 Formats: txt
This experimental memo defines extensions to LMP(rfc4209) for managing Optical parameters associated with Wavelength Division Multiplexing (WDM) adding a set of parameters related to multicarrier DWDM interfaces to be used in Spectrum Switched Optical Networks (sson).
    
draft-ggalimbe-ccamp-flexigrid-carrier-label-04.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-04.txt
 Date: 28/06/2018
 Authors: Gabriele Galimberti, Domenico Fauci, Andrea Zanardi, Lorenzo Galvagni
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines the signaling extensions for managing Spectrum Switched Optical Network (SSON) parameters shared between the Client and the Network and inside the Network in accordance to the model described in RFC 7698. The extensions are in accordance and extending the parameters defined in ITU-T Recommendation G.694.1.[ITU.G694.1] and its extensions and G.872.[ITU.G872].
    
draft-ginsberg-isis-rfc5306bis-01.txt
 Restart Signaling for IS-IS
 
 draft-ginsberg-isis-rfc5306bis-01.txt
 Date: 28/06/2018
 Authors: Les Ginsberg, Paul Wells
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization. This document additionally describes a mechansim for a router to signal its neighbors that it is preparing to initiate a restart while maintaining forwarding plane state. This allows the neighbors to maintain their adjacencies until the router has restarted, but also allows the neighbors to bring the adjacencies down in the event of other topology changes. This document additionally describes a mechanism for a restarting router to determine when it has achieved Link State Protocol Data Unit (LSP) database synchronization with its neighbors and a mechanism to optimize LSP database synchronization, while minimizing transient routing disruption when a router starts. This document obsoletes RFC 5306.
    
draft-gmsm-bess-evpn-bfd-01.txt
 Fault Management for EVPN networks
 
 draft-gmsm-bess-evpn-bfd-01.txt
 Date: 27/05/2018
 Authors: Vengada Govindan, Mallik Mudigonda, Ali Sajassi, Gregory Mirsky, Donald Eastlake
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a proactive, in-band network OAM mechanism 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 EVPN network. The mechanisms proposed in the draft use the widely adopted Bidirectional Forwarding Detection (BFD) protocol.
    
draft-gondwana-jmap-imapdata-00.txt
 JMAP Extension for imap data
 
 draft-gondwana-jmap-imapdata-00.txt
 Date: 21/03/2018
 Authors: Bron Gondwana
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document adds additional properties to the JMAP Email and Mailbox objects so that servers which also support IMAP can expose metadata about the IMAP Mailstore via JMAP.
    
draft-gondwana-sieve-mailboxid-01.txt
 Sieve Email Filtering: delivery by mailboxid
 
 draft-gondwana-sieve-mailboxid-01.txt
 Date: 12/08/2018
 Authors: Bron Gondwana
 Working Group: Individual Submissions (none)
 Formats: xml txt
The OBJECTID capability of the IMAP protocol (I-D.ietf-extra-imap- objectid) allows clients to identify mailboxes by a unique identifier which survives rename. In contrast, the Sieve mail filtering language (RFC 5228) currently has no such capability. This memo defines a Sieve extension that fills this gap: it adds a method for specifying the unique identifier of a mailbox as a target for fileinto rules, and a method for testing the existence of a mailbox by its unique identifier.
    
draft-gont-6man-non-stable-iids-04.txt
 Recommendation on Temporary IPv6 Interface Identifiers
 
 draft-gont-6man-non-stable-iids-04.txt
 Date: 24/03/2018
 Authors: Fernando Gont, Christian Huitema, Suresh Krishnan, Guillermo Gont, Madelen Corbo
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a set of requirements for generating temporary addresses, and clarifies the stability requirements for IPv6 addresses, allowing for the use of only temporary addresses.
    
draft-gont-taps-address-analysis-00.txt
 Problem Statement Regarding IPv6 Address Usage
 
 draft-gont-taps-address-analysis-00.txt
 Date: 21/03/2018
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the security, privacy, and interoperability implications of IPv6 addresses based on a number of properties (such as address scope, stability, and usage type).
    
draft-gont-taps-sockets-api-limitations-00.txt
 Problem Statement Regarding Limitations of the Sockets API for IPv6 Address Usage
 
 draft-gont-taps-sockets-api-limitations-00.txt
 Date: 21/03/2018
 Authors: Fernando Gont, Guillermo Gont, Madelen Corbo, Christian Huitema
 Working Group: Individual Submissions (none)
 Formats: txt
This identifies gaps that currently prevent systems and applications from leveraging the increased flexibility and availability of IPv6 addresses.
    
draft-google-self-published-geofeeds-02.txt
 Self-published IP Geolocation Data
 
 draft-google-self-published-geofeeds-02.txt
 Date: 28/07/2013
 Authors: Erik Kline, Krzysztof Duleba, Zoltan Szamonek
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document records a format whereby a network operator can publish a mapping of IP address ranges to simplified geolocation information, colloquially termed a geolocation "feed". Interested parties can poll and parse these feeds to update or merge with other geolocation data sources and procedures. Some technical organizations operating networks that move from one conference location to the next have already experimentally published small geolocation feeds. At least one consumer (Google) has incorporated these ad hoc feeds into a geolocation data pipeline.
    
draft-gould-carney-regext-registry-03.txt
 Registry Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-carney-regext-registry-03.txt
 Date: 17/08/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-idn-table-06.txt
 Extensible Provisioning Protocol (EPP) Internationalized Domain Name (IDN) Table Mapping
 
 draft-gould-idn-table-06.txt
 Date: 16/04/2018
 Authors: James Gould, Francisco Obispo
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an Extensible Provisioning Protocol (EPP) mapping for getting Internationalized Domain Name (IDN) Table information for the registration of IDNs, using the EPP domain name mapping, and optionally with the IDN mapping extension. An IDN Table defines the valid set of characters (code points) that can be used in a domain name. Code points may overlap across IDN Tables and the IDN Tables supported by the servers are up to server policy. The IDN Table information can be used to validate an IDN prior to registration, can be cached by the client for pre-validation, can be used to select the best IDN Table for the IDN, and can be used to know if and what IDN Table Identifier to pass in a domain create.
    
draft-gould-regext-dataset-02.txt
 Data Set File Format
 
 draft-gould-regext-dataset-02.txt
 Date: 05/09/2018
 Authors: James Gould
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a Data Set File (DSF) format that can be used to define and pass bulk data between a client and a server. This format is extensible to pass any set of simple data types in a set of records contained in the body of the file. The file format also supports storing the result of processing the data set that MAY be generated by the server and returned to the client. The file format consists of an XML definition header and a Comma-Separated Values (CSV) data section delimited by "-----BEGIN DATA SET-----" and "----- END DATA SET-----" lines. The XML definition header defines the format of the CSV data section, contains additional meta-data, and optionally includes a digital signature to identify the source and ensure that the data has not been tampered with between the parties (source, client, and server). The interface (manual or automated) that is used to submit the file and receive the result file is not defined within this document.
    
draft-gould-regext-launch-policy-01.txt
 Launch Phase Policy Extensions Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-launch-policy-01.txt
 Date: 17/08/2018
 Authors: James Gould
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an Extensible Provisioning Protocol (EPP) extension of the Registry Mapping to define the server policy of the Launch Phase EPP extension. The server policy of the Launch Phase EPP extension includes the MAYs, SHOULDs, and options implemented by the server.
    
draft-gould-regext-login-security-02.txt
 Login Security Extension for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-login-security-02.txt
 Date: 17/08/2018
 Authors: James Gould, Matthew Pozun
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds additional security features to the EPP login command and response.
    
draft-gould-regext-login-security-policy-00.txt
 Login Security Policy Extensions Mapping for the Extensible Provisioning Protocol (EPP)
 
 draft-gould-regext-login-security-policy-00.txt
 Date: 12/09/2018
 Authors: James Gould
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an Extensible Provisioning Protocol (EPP) extension of the Registry Mapping to define the server policy of the Login Security EPP extension. The server policy of the Login Security EPP extension includes the MAYs, SHOULDs, and options implemented by the server.
    
draft-gpujol-oauth-atrl-01.txt
 OAuth 2.0 Token Revocation List
 
 draft-gpujol-oauth-atrl-01.txt
 Date: 10/09/2018
 Authors: Guillaume Pujol
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a format and a standardised uri for a Token Revocation List. An OAuth 2.0 authorization server can use those to expose a current list of revoked access tokens identifiers that it previously issued, intended for use by OAuth 2.0 resource servers.
    
draft-gu-grow-bmp-vpn-label-00.txt
 VPN Label Monitoring Using BMP
 
 draft-gu-grow-bmp-vpn-label-00.txt
 Date: 02/07/2018
 Authors: Yunan Gu, iqjie@mail.ustc.edu.cn, Penghui Mi, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
The BGP Monitoring Protocol (BMP) is designed to monitor BGP running status, such as BGP peer relationship establishment and termination and route updates. This document provides a method of collecting the VPN label using BMP, as well as an implementation example.
    
draft-gu-network-monitoring-protocol-00.txt
 Network Monitoring Protocol (NMP)
 
 draft-gu-network-monitoring-protocol-00.txt
 Date: 16/07/2018
 Authors: Yunan Gu, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
To evolve towards automated network OAM (Operations, administration and management), the monitoring of control plane protocols is a fundamental necessity. In this document, a network monitoring protocol (NMP) is proposed to provision the running status information of control plane protocols, e.g., IGP (Interior Gateway Protocol) and other protocols. By collecting the protocol monitoring data and reporting it to the NMP monitoring server in real-time, NMP can facilitate network troubleshooting. In this document, NMP for IGP troubleshooting are illustrated to showcase the necessity of NMP. IS-IS is used as the demonstration protocol, and the case of OSPF (Open Shortest Path First) and other control protocols will be elaborated in the future versions. The operations of NMP are described, and the NMP message types and message formats are defined in the document.
    
draft-gu-network-mornitoring-protol-00.txt
 Network Monitoring Protocol (NMP)
 
 draft-gu-network-mornitoring-protol-00.txt
 Date: 02/07/2018
 Authors: Yunan Gu, Shunwan Zhuang, Zhenbin Li
 Working Group: Individual Submissions (none)
 Formats: txt
To enable automated network OAM (Operations, administration and management), the availability of network protocol running status information is a fundamental step. In this document, a network monitoring protocol (NMP) is proposed to provision the information related to running status of IGP (Interior Gateway Protocol) and other control protocols. It can facilitate the network troubleshooting of control protocols in a network domain. Typical network issues are illustrated as the usecases of NMP for ISIS to showcase the necessity of NMP. Then the operations and the message formats of NMP for ISIS are defined. In this document ISIS is used as the illustration protocol, and the case of OSPF and other control protocols will be included in the future version.
    
draft-guichard-sfc-nsh-sr-02.txt
 NSH and Segment Routing Integration for Service Function Chaining (SFC)
 
 draft-guichard-sfc-nsh-sr-02.txt
 Date: 18/06/2018
 Authors: Jim Guichard, Haoyu Song, Jeff Tantsura, Joel Halpern, Wim Henderickx, Mohamed Boucadair
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes two application scenarios where Network Service Header (NSH) and Segment Routing (SR) techniques can be deployed together to support Service Function Chaining (SFC) in an efficient manner while maintaining separation of the service and transport planes as originally intended by the SFC architecture. In the first scenario, an NSH-based SFC is created using SR as the transport between SFFs. SR in this case is just one of many encapsulations that could be used to maintain the transport- independent nature of NSH-based service chains. In the second scenario, SR is used to represent each service hop of the NSH-based SFC as a segment within the segment-list. SR and NSH in this case are integrated. In both scenarios SR is responsible for steering packets between SFFs along a given SFP while NSH is responsible for maintaining the integrity of the service plane, the SFC instance context, and any associated metadata. These application scenarios demonstrate that NSH and SR can work jointly and complement each other leaving the network operator with the flexibility to use whichever transport technology makes sense in specific areas of their network infrastructure, and still maintain an end-to-end service plane using NSH.
    
draft-gundavelli-dmm-mfa-01.txt
 Mobility-aware Floating Anchor (MFA)
 
 draft-gundavelli-dmm-mfa-01.txt
 Date: 19/09/2018
 Authors: Sri Gundavelli, Marco Liebsch, Satoru Matsushima
 Working Group: Individual Submissions (none)
 Formats: txt
IP mobility protocols are designed to allow a mobile node to remain reachable while moving around in the network. The currently deployed mobility management protocols are anchor-based approaches, where a mobile node's IP sessions are anchored on a central node. The mobile node's IP traffic enters and exits from this anchor node and it remains as the control point for all subscriber services. This architecture based on fixed IP anchors comes with some complexity and there is some interest from the mobile operators to eliminate the use of fixed anchors, and other residual elements such as the overlay tunneling that come with it. This document describes a new approach for realizing a mobile user- plane that does not require fixed IP anchors. The architectural- basis for this approach is the separation of control and user plane, and the use of programmability constructs of the user-plane for traffic steering. This approach is referred to as, Mobility-aware Floating Anchor (MFA).
    
draft-gundogan-icnrg-ccnlowpan-02.txt
 ICN Adaptation to LowPAN Networks (ICN LoWPAN)
 
 draft-gundogan-icnrg-ccnlowpan-02.txt
 Date: 16/07/2018
 Authors: Cenk Gundogan, Thomas Schmidt, Matthias Waehlisch, Christopher Scherb, Claudio Marxer, Christian Tschudin
 Working Group: Individual Submissions (none)
 Formats: xml txt
In this document, a convergence layer for CCNx and NDN over IEEE 802.15.4 LoWPAN networks is defined. A new frame format is specified to adapt CCNx and NDN packets to the small MTU size of IEEE 802.15.4. For that, syntactic and semantic changes to the TLV-based header formats are described. To support compatibility with other LoWPAN technologies that may coexist on a wireless medium, the dispatching scheme provided by 6LoWPAN is extended to include new dispatch types for CCNx and NDN. Additionally, the link fragmentation component of the 6LoWPAN dispatching framework is applied to ICN chunks. Basic improvements in efficiency are advised by stateless and stateful compression schemes.
    
draft-gutmann-scep-10.txt
 Simple Certificate Enrolment Protocol
 
 draft-gutmann-scep-10.txt
 Date: 01/03/2018
 Authors: Peter Gutmann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies the Simple Certificate Enrolment Protocol (SCEP), a PKI protocol that leverages existing technology by using CMS (formerly known as PKCS #7) and PKCS #10 over HTTP. SCEP is the evolution of the enrolment protocol sponsored by Cisco Systems, which enjoys wide support in both client and server implementations, as well as being relied upon by numerous other industry standards that work with certificates.
    
draft-gutmann-tls-lts-10.txt
 TLS 1.2 Update for Long-term Support
 
 draft-gutmann-tls-lts-10.txt
 Date: 22/03/2018
 Authors: Peter Gutmann
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies an update of TLS 1.2 for long-term support on systems that can have multi-year or even decade-long update cycles, one that incoporates as far as possible what's already deployed for TLS 1.2 but with the security holes and bugs fixed. This document also recognises the fact that there is a huge amount of TLS use outside the web content-delivery environment with its resource-rich hardware and software that can be updated whenever required and provides a long-term stable, known-good version that can be deployed to systems that can't roll out ongoing changes on a continuous basis.
    
draft-gwock-rmcat-ccfs-00.txt
 Congestion Control based on Forward path Status
 
 draft-gwock-rmcat-ccfs-00.txt
 Date: 03/09/2018
 Authors: jungnam.gwock
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes CCFS(Congestion Control based on Forward path Status), rate adaptation scheme for interactive real-time media applications, such as video conferencing. CCFS manages forward path's status based on the estimated three major parameters - serving bitrate, queue delay and queue delay by cross traffics. Considering only forward path status minimizes the effects of backward path's network event such as congestion. It also is free from compatibility issues because it defines generalized feedback message and minimizes receiver's role.
    
draft-haberman-iasa20dt-recs-02.txt
 IASA 2.0 Design Team Recommendations
 
 draft-haberman-iasa20dt-recs-02.txt
 Date: 18/04/2018
 Authors: Brian Haberman, Jari Arkko, Leslie Daigle, Jason Livingood, Joseph Hall, Eric Rescorla
 Working Group: Individual Submissions (none)
 Formats: txt
The arrangements relating to administrative support for the IETF were created more than ten years ago. Since then, there has been considerable change in the tasks and in our own expectations. The IETF community has discussed these changes and the problems they cause. The community has some sense of the properties they expect from future arrangements, including those related to structure, organization, personnel, and transparency. This document is a product of a design team, focused on providing additional information to the community about solution options, as well as supporting analysis of the implications of those options. To be clear, the community is responsible for adopting any recommendations or making any final decisions.
    
draft-haindl-lisp-gb-atn-01.txt
 Ground-Based LISP for the Aeronautical Telecommunications Network
 
 draft-haindl-lisp-gb-atn-01.txt
 Date: 05/06/2018
 Authors: Bernhard Haindl, Manfred Lindner, Reshad Rahman, Marc Portoles-Comeras, Victor Moreno, Fabio Maino
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the use of the LISP architecture and protocols to address the requirements of the worldwide Aeronautical Telecommunications Network with Internet Protocol Services, as articulated by the International Civil Aviation Organization. The ground-based LISP overlay provides mobility and multi-homing services to the IPv6 networks hosted on commercial aircrafts, to support Air Traffic Management communications with Air Traffic Controllers and Air Operation Controllers. The proposed architecture doesn't require support for LISP protocol in the airborne routers, and can be easily deployed over existing ground infrastructures.
    
draft-hakala-urn-nbn-rfc3188bis-02.txt
 Using National Bibliography Numbers as Uniform Resource Names
 
 draft-hakala-urn-nbn-rfc3188bis-02.txt
 Date: 14/06/2018
 Authors: Juna Hakala
 Working Group: Applications and Real-Time Area (art)
 Formats: txt
National Bibliography Numbers (NBNs) are used by the national libraries and other organizations in order to identify resources in their collections. NBNs are usually applied to resources that are not catered for by established (standard) identifier systems such as ISBN. A URN (Uniform Resource Names) namespace for NBNs was established in 2001 in RFC 3188. Since then, a number of European national libraries have implemented URN:NBN-based systems. This document replaces RFC 3188 and defines how NBNs can be supported within the updated URN framework. A revised namespace registration (version 4) compliant to RFC 8141 is included.
    
draft-hall-censorship-tech-05.txt
 A Survey of Worldwide Censorship Techniques
 
 draft-hall-censorship-tech-05.txt
 Date: 25/05/2018
 Authors: Joseph Hall, Michael Aaron, Ben Jones, Nick Feamster
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes the technical mechanisms used by censorship regimes around the world to block or impair Internet traffic. It aims to make designers, implementers, and users of Internet protocols aware of the properties being exploited and mechanisms used to censor end-user access to information. This document makes no suggestions on individual protocol considerations, and is purely informational, intended to be a reference.
    
draft-hallambaker-dare-container-02.txt
 Data At Rest Encryption Part 2: DARE Container
 
 draft-hallambaker-dare-container-02.txt
 Date: 27/08/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes DARE Container, a message and file syntax that allows an append-only sequence of data frames to be represented with cryptographic integrity, signature and encryption enhancements. The format supports data integrity checks using digest chains and Merkle trees. The simplest supports efficient write operations and efficient read operations in either the forward or reverse direction. Support for efficient random-access reads may be provided through the use of binary trees or index records appended to the end of the file. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-dare-container.html [1] .
    
draft-hallambaker-dare-message-02.txt
 Data At Rest Encryption Part 1: DARE Message Syntax
 
 draft-hallambaker-dare-message-02.txt
 Date: 27/08/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes the Data At Rest Encryption (DARE) message syntax. This syntax is used to digitally sign, digest, authenticate, or encrypt arbitrary message content. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-dare-message.html [1] .
    
draft-hallambaker-jbcd-container-02.txt
 JBCD Container
 
 draft-hallambaker-jbcd-container-02.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jbcd-container.html [1] .
    
draft-hallambaker-json-key-exchange-03.txt
 JSON Key Exchange
 
 draft-hallambaker-json-key-exchange-03.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The JSON Key Exchange This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-json-key- exchange.html [1] .
    
draft-hallambaker-json-web-service-10.txt
 JSON Web Service Binding Version 1.0
 
 draft-hallambaker-json-web-service-10.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The JSON Web Binding (JWB) describes a standardized approach to implementing Web Services. Services are advertised using the DNS SRV and HTTP Well Known Service conventions. Messages may be authenticated or authenticated and encrypted at the message layer in addition to any transport and/or network layer security. Service messages are encoded in JSON using Internet time format for Date-Time fields and Base64urlencoding for binary objects. This document specifies Version 1.0 of JWB which uses HTTP/1.1 for transport. Use of the multiple stream capabilities of HTTP/2 or QUIC is outside the scope of this document. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-json-web-service.html [1] .
    
draft-hallambaker-jsonbcd-13.txt
 Binary Encodings for JavaScript Object Notation: JSON-B,JSON-C,JSON-D
 
 draft-hallambaker-jsonbcd-13.txt
 Date: 15/07/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
Three binary encodings for JavaScript Object Notation (JSON) are presented. JSON-B (Binary) is a strict superset of the JSON encoding that permits efficient binary encoding of intrinsic JavaScript data types. JSON-C (Compact) is a strict superset of JSON-B that supports compact representation of repeated data strings with short numeric codes. JSON-D (Data) supports additional binary data types for integer and floating-point representations for use in scientific applications where conversion between binary and decimal representations would cause a loss of precision. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-jsonbcd.html [1] .
    
draft-hallambaker-mesh-advanced-00.txt
 Mathematical Mesh Part III: Advanced Cryptographic Services
 
 draft-hallambaker-mesh-advanced-00.txt
 Date: 31/08/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh ?The Mesh? is an infrastructure that facilitates the exchange of configuration and credential data between multiple user devices and provides end-to-end security. This document describes the advanced encryption services supported by the Mesh. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-advanced.html [1] .
    
draft-hallambaker-mesh-app-02.txt
 Mathematical Mesh: Application Profiles
 
 draft-hallambaker-mesh-app-02.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The use of the Mathematical Mesh to manage cryptographic keys for use with Mail and SSH is described. The format of the application profiles is described with examples. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-app.html [1] .
    
draft-hallambaker-mesh-architecture-06.txt
 Mathematical Mesh Part I: Architecture Guide
 
 draft-hallambaker-mesh-architecture-06.txt
 Date: 31/08/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The architecture of the Mesh and examples of typical applications are described. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh- architecture.html [1] .
    
draft-hallambaker-mesh-developer-07.txt
 Mathematical Mesh: Reference Implementation
 
 draft-hallambaker-mesh-developer-07.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes the Mesh reference code and how to install, run and make use of it in applications. It does not form a part of the Mesh specifications and is not normative. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-developer.html [1] .
    
draft-hallambaker-mesh-platform-03.txt
 Mathematical Mesh: Platform Configuration
 
 draft-hallambaker-mesh-platform-03.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. This document describes how Mesh profiles are stored for application access on Windows, Linux and OSX platforms. This document is also available online at http://prismproof.org/Documents/draft-hallambaker-mesh-platform.html [1] .
    
draft-hallambaker-mesh-reference-10.txt
 Mathematical Mesh Part II: Reference
 
 draft-hallambaker-mesh-reference-10.txt
 Date: 31/08/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
The Mathematical Mesh ?The Mesh? is an end-to-end secure infrastructure that facilitates the exchange of configuration and credential data between multiple user devices. The core protocols of the Mesh are described with examples of common use cases and reference data. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-mesh-reference.html [1] .
    
draft-hallambaker-sin-03.txt
 Strong Internet Names (SIN)
 
 draft-hallambaker-sin-03.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
A Strong Internet Name is a DNS name that contains a cryptographic binding to a security policy governing interpretation of the name. This document describes the use of Strong Internet Names formed using a Uniform Data Fingerprint of a PKIX trust root and outlines the additional capabilities that might be supported in a purpose written policy language. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-sin.html [1] .
    
draft-hallambaker-udf-10.txt
 Uniform Data Fingerprint (UDF)
 
 draft-hallambaker-udf-10.txt
 Date: 11/04/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes means of generating Uniform Data Fingerprint (UDF) values and their presentation as text sequences and as URIs. Uses of UDF fingerprints include but are not limited to creating Strong Internet Names (SINs). Cryptographic digests provide a means of uniquely identifying static data without the need for a registration authority. A fingerprint is a form of presenting a cryptographic digest that makes it suitable for use in applications where human readability is required. The UDF fingerprint format improves over existing formats through the introduction of a compact algorithm identifier affording an intentionally limited choice of digest algorithm and the inclusion of an IANA registered MIME Content-Type identifier within the scope of the digest input to allow the use of a single fingerprint format in multiple application domains. Alternative means of rendering fingerprint values are considered including machine-readable codes, word and image lists. This document is also available online at http://mathmesh.com/Documents/draft-hallambaker-udf.html [1] .
    
draft-hallambaker-web-service-discovery-00.txt
 DNS Web Service Discovery
 
 draft-hallambaker-web-service-discovery-00.txt
 Date: 14/06/2018
 Authors: Phillip Hallam-Baker
 Working Group: Individual Submissions (none)
 Formats: xml txt
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-00.txt
 Resource Reservation Protocol for IP Transport QoS
 
 draft-han-tsvwg-ip-transport-qos-00.txt
 Date: 02/07/2018
 Authors: Lin Han, Yingzhen Qu, Lijun Dong, Thomas Nadeau, Kevin Smith
 Working Group: Individual Submissions (none)
 Formats: txt
IP has been known as best-effort data transmission. 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-02.txt
 Centralized EVPN DF Election
 
 draft-hao-bess-evpn-centralized-df-02.txt
 Date: 18/09/2018
 Authors: Donald Eastlake, Hao Weiguo, Lili Wang, Li Yizhou, Shunwan Zhuang
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes a centralized DF Designated Forwarder election mechanism to be used between an SDN (Software Defined Network) controller and each PE (Provider Edge) device in an EVPN network. Such a mechanism overcomes the issues of current standalone DF election defined in RFC 7432. A new BGP capability and an additional DF Election Result Route Type are specified to support this centralized DF mechanism.
    
draft-hardie-path-signals-03.txt
 Path Signals
 
 draft-hardie-path-signals-03.txt
 Date: 02/04/2018
 Authors: Ted Hardie
 Working Group: Individual Submissions (none)
 Formats: txt
This document discusses the nature of signals seen by on-path elements, contrasting implicit and explicit signals. For example, TCP's state mechanics uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on- path network elements lack those signals. This document recommends that explict signals be used by transports which encrypt their state mechanics. It also recommends that a signal be exposed to the path only when the signal's originator intends that it be used by the network elements on the path.
    
draft-hardjono-oauth-decentralized-02.txt
 Decentralized Service Architecture for OAuth2.0
 
 draft-hardjono-oauth-decentralized-02.txt
 Date: 25/03/2018
 Authors: Thomas Hardjono
 Working Group: Individual Submissions (none)
 Formats: txt
This document proposes an alternative service architecture for user- centric control of the sharing of resources following the UMA model, such as personal data, using the decentralized peer-to-peer computing paradigm. The term 'control' is used here to denote the full capacity of the user to freely select (i) the entities with whom to share resources (e.g. data), and (ii) the entities which provide services implementing user-controlled resource sharing. The peer-to- peer service architecture uses a set of computing nodes called OAuth2.0 Nodes (ON) that are part of a peer-to-peer network as the basis for the decentralized service architecture.
    
draft-hardt-oauth-distributed-01.txt
 Distributed OAuth
 
 draft-hardt-oauth-distributed-01.txt
 Date: 12/06/2018
 Authors: Dick Hardt, Brian Campbell, Nat Sakimura
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Distributed OAuth profile enables an OAuth client to discover what authorization server or servers may be used to obtain access tokens for a given resource, and what parameter values to provide in the access token request.
    
draft-hares-i2nsf-capability-data-model-07.txt
 I2NSF Capability YANG Data Model
 
 draft-hares-i2nsf-capability-data-model-07.txt
 Date: 23/03/2018
 Authors: Susan Hares, Jaehoon Jeong, Jinyong Kim, Robert Moskowitz, linqiushi@huawei.com
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines a YANG data model for capabilities that enables an I2NSF user to control various network security functions in network security devices.
    
draft-haresh-sushrut-mib-classification-01.txt
 SNMPD to use cache and shared database based on MIB Classification
 
 draft-haresh-sushrut-mib-classification-01.txt
 Date: 29/03/2012
 Authors: Haresh Khandelwal
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines classification of SNMP MIBs to either use SNMP cache database and shared database (SDB) mechanism to reduce high CPU usage while SNMP GET REQUEST, GETNEXT REQUEST, GETBULK REQUEST are continuously performed from network management system (NMS)/SNMP manager/SNMP MIB browser to managed device.
    
draft-harkins-pkex-06.txt
 Public Key Exchange
 
 draft-harkins-pkex-06.txt
 Date: 06/08/2018
 Authors: Dan Harkins
 Working Group: Crypto Forum (cfrg)
 Formats: txt
This memo describes a password-authenticated protocol to allow two devices to exchange "raw" (uncertified) public keys and establish trust that the keys belong to their respective identities.
    
draft-harkins-tls-dragonfly-04.txt
 Secure Password Ciphersuites for Transport Layer Security (TLS)
 
 draft-harkins-tls-dragonfly-04.txt
 Date: 23/08/2018
 Authors: Dan Harkins
 Working Group: Individual Submissions (none)
 Formats: txt
This memo defines several new ciphersuites for the Transport Layer Security (TLS) protocol to support certificate-less, secure authentication using only a simple, low-entropy, password. The exchange is called TLS-PWD. The ciphersuites are all based on an authentication and key exchange protocol, named "dragonfly", that is resistant to off-line dictionary attack.
    
draft-harris-early-pipe-01.txt
 SMTP Service Extension for Early Pipelining
 
 draft-harris-early-pipe-01.txt
 Date: 13/09/2018
 Authors: Jeremy Harris
 Working Group: Individual Submissions (none)
 Formats: txt xml
PIPE_CONNECT is an SMTP extension supporting the pipelining of banner, EHLO and one following command or traditionally-pipelined sequence in an SMTP conversation. It permits a reduction in delivery latency by eliminating a nunmber of network round-trips.
    
draft-hartke-core-stateless-01.txt
 Extended Tokens and Stateless Clients in the Constrained Application Protocol (CoAP)
 
 draft-hartke-core-stateless-01.txt
 Date: 18/09/2018
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
This document provides considerations for alleviating CoAP clients and intermediaries of maintaining per-request state. Additionally, it introduces a new, optional CoAP protocol extension for extended token lengths. This document updates RFCs 7252 and 8323.
    
draft-hartke-t2trg-coral-05.txt
 The Constrained RESTful Application Language (CoRAL)
 
 draft-hartke-t2trg-coral-05.txt
 Date: 25/04/2018
 Authors: Klaus Hartke
 Working Group: Individual Submissions (none)
 Formats: txt
The Constrained RESTful Application Language (CoRAL) defines a data model and interaction model as well as two specialized serialization formats for the description of typed connections between resources on the Web ("links"), possible operations on such resources ("forms"), and simple resource metadata.
    
draft-haynes-nfsv4-delstid-00.txt
 Extending the Opening of Files in NFSv4.2
 
 draft-haynes-nfsv4-delstid-00.txt
 Date: 01/04/2018
 Authors: Thomas Haynes
 Working Group: Individual Submissions (none)
 Formats: txt
The Network File System v4 (NFSv4) allows a client to both open a file and be granted a delegation of that file. This grants the client the right to cache metadata on the file locally. This document presents serveral refinements to both the opeing and delegating of the file to the client.
    
draft-he-ccamp-gmpls-signaling-smp-00.txt
 GMPLS Signaling Extensions for Shared Mesh Protection
 
 draft-he-ccamp-gmpls-signaling-smp-00.txt
 Date: 02/07/2018
 Authors: He Jia
 Working Group: Individual Submissions (none)
 Formats: txt
ITU-T Recommendation G.808.3 [G808.3] defines the generic aspects of a shared mesh protection (SMP) mechanism, where the difference between SMP and shared mesh restoration (SMR) is also identified. ITU-T Recommendation G.873.3 [G873.3] defines the protection switching operation and associated protocol for shared mesh protection (SMP) at the optical data unit (ODU) layer. This document updates RFC 4872 to provide the extensions to the Generalized Multi-Protocol Label Switching (GMPLS) signaling to support the control of the shared mesh protection.
    
draft-hegde-spring-node-protection-for-sr-te-paths-03.txt
 Node Protection for SR-TE Paths
 
 draft-hegde-spring-node-protection-for-sr-te-paths-03.txt
 Date: 02/07/2018
 Authors: Shraddha Hegde, Chris Bowers, Stephane Litkowski, Xiaohu Xu
 Working Group: Individual Submissions (none)
 Formats: xml txt
Segment routing supports the creation of explicit paths using adjacency-sids, node-sids, and binding-sids. It is important to provide fast reroute (FRR) mechanisms to respond to failures of links and nodes in the Segment-Routed Traffic-Engineered(SR-TE) path. A point of local repair (PLR) can provide FRR protection against the failure of a link in an SR-TE path by examining only the first (top) label in the SR label stack. In order to protect against the failure of a node, a PLR may need to examine the second label in the stack as well in order to determine SR-TE path beyond the failed node. This document specifies how a PLR can use the first and second label in the label stack describing an SR-TE path to provide protection against node failures.
    
draft-heitz-idr-extra-extended-community-01.txt
 BGP Extra Extended Community
 
 draft-heitz-idr-extra-extended-community-01.txt
 Date: 17/07/2018
 Authors: Jakob Heitz, Ali Sajassi, Ignas Bagdonas
 Working Group: Individual Submissions (none)
 Formats: txt xml
Auto-derived identifiers are used by applications to enable zero configuration features. Such identifiers are often a combination of primitive identifiers and are thus longer. In addition, existing identifiers have grown longer. IP addresses have grown from 4 octets to 16. AS numbers have grown from 2 octets to 4. In order to accommodate such longer identifiers in BGP extended communities, this document defines a new BGP path attribute, the Extra Extended Communities attribute. It is similar to the Extended Community, but is 24 octets long. Communities are mostly used within ASes under a single administration or between neighboring ASes. Limiting the spread of communities beyond their intended reach and polluting the internet at large is complex and error prone. To simplify this, enhanced transitivity options are provided.
    
draft-herbert-fast-03.txt
 Firewall and Service Tickets
 
 draft-herbert-fast-03.txt
 Date: 19/09/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the Firewalls and Service Tickets protocol. A ticket is data that accompanies a packet and indicates a granted right to traverse a network or a request for network service to be applied. Applications request tickets from a local agent in the network and attach issued tickets to packets. Firewall tickets are issued to grant packets the right to traverse a network; service tickets indicate the desired service to be applied to a packets. A single ticket may provide both firewall and service ticket information. Tickets are sent in IPv6 Hop-by-Hop options.
    
draft-herbert-idloc-fast-00.txt
 Lightweight Identifier-Locator Mapping Using FAST
 
 draft-herbert-idloc-fast-00.txt
 Date: 26/06/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This proposal provides a method to implement identifier to locator mapping in the datapath without the need to access an in-network mapping database or cache. Mappings are encoded in Firewall and Service Tickets (FAST) tickets as locator information. When a packet is sent by a mobile node, a ticket is attached that providers the locator to use in the return path. Peer nodes receive packets with these tickets, cache the tickets in a flow context, and then attach them to packets they send as reflected tickets. When a packet with a reflected ticket enters an identifier-locator domain, the ticket is parsed to extract the locator. That locator is then used to send the packet to the appropriate destination over a network overlay.
    
draft-herbert-ipv6-update-opts-00.txt
 Updates to Requirements for IPv6 Options
 
 draft-herbert-ipv6-update-opts-00.txt
 Date: 14/09/2018
 Authors: Tom Herbert
 Working Group: Individual Submissions (none)
 Formats: txt
This document updates requirements for IPv6 Destination and Hop-by- Hop Options. The requirements that option type and option length cannot change en route, as well as the requirements that options cannot be added or removed, are made explicit. The meaning and requirements of a Destination Option marked as changeable are clarified. Finally, the requirement that all destinations listed in a Routing header must process options in a Destination Options header preceding the Routing header is relaxed.
    
draft-hevroni-oauth-seamless-flow-01.txt
 Seamless OAuth 2.0 Client Assertion Grant
 
 draft-hevroni-oauth-seamless-flow-01.txt
 Date: 02/08/2018
 Authors: Omer Hevroni
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines the use of a One Time Password, encoded as JSON Web Token (JWS) Bearer Token, as a means for requesting an OAuth 2.0 access token as well as for client authentication.
    
draft-historic-simple-ip-03.txt
 Simple Internet Protocol (SIP) Specification
 
 draft-historic-simple-ip-03.txt
 Date: 06/09/2018
 Authors: Steve Deering, Robert Hinden
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document is published for the historical record. The Simple Internet Protocol was the basis for one of the candidates for the IETF's Next Generation (IPng) work that became IPv6. The publication date of the original Internet-Draft was November 10, 1992. It is presented here substantially unchanged and is neither a complete document nor intended to be implementable. The paragraph that follows is the Abstract from the original draft. This document specifies a new version of IP called SIP, the Simple Internet Protocol. It also describes the changes needed to ICMP, IGMP, and transport protocols such as TCP and UDP, in order to work with SIP. A companion document [SIP-ADDR] describes the addressing and routing aspects of SIP, including issues of auto-configuration, host and subnet mobility, and multicast.
    
draft-hj-bier-mldp-signaling-00.txt
 M-LDP Signaling Through BIER Core
 
 draft-hj-bier-mldp-signaling-00.txt
 Date: 02/07/2018
 Authors: Hooman Bidgoli, Andrew Dolganow, Jayant Kotalwar
 Working Group: Individual Submissions (none)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the procedure needed for mLDP tunnels to be signaled and stitched through a BIER core. Allowing LDP routers to run traditional Multipoint LDP services through a BIER core.
    
draft-hmm-dmm-5g-uplane-analysis-01.txt
 User Plane Protocol and Architectural Analysis on 3GPP 5G System
 
 draft-hmm-dmm-5g-uplane-analysis-01.txt
 Date: 10/08/2018
 Authors: Shunsuke Homma, Takuya Miyasaka, Satoru Matsushima, daniel.voyer@bell.ca
 Working Group: Individual Submissions (none)
 Formats: txt
This document analyzes the mobile user plane protocol and the architecture specified in 3GPP 5G documents. The analysis work is to clarify those specifications, extract protocol and architectural requirements and derive evaluation aspects for user plane protocols on IETF side. This work is corresponding to the User Plane Protocol Study work on 3GPP side.
    
draft-hoehlhubmer-https-addon-07.txt
 Informational Add-on for HTTP over the Secure Sockets Layer (SSL) Protocol and/or the Transport Layer Security (TLS) Protocol
 
 draft-hoehlhubmer-https-addon-07.txt
 Date: 25/11/2013
 Authors: Walter Hoehlhubmer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes an Add-on for websites providing encrypted connectivity (HTTP over TLS). The Add-on has two parts, one for the Domain Name System (DNS) - storing the X.509 certificate hashes - and one for the webserver itself - an additional webpage providing specific informations.
    
draft-hoehrmann-cp-collation-01.txt
 The i;codepoint collation
 
 draft-hoehrmann-cp-collation-01.txt
 Date: 14/09/2010
 Authors: Bjoern Hoehrmann
 Working Group: Individual Submissions (none)
 Formats: txt
This memo describes the "i;codepoint" collation. Character strings are compared based on the Unicode scalar values of the characters. The collation supports equality, substring, and ordering operations.
    
draft-hoffman-c2pq-04.txt
 The Transition from Classical to Post-Quantum Cryptography
 
 draft-hoffman-c2pq-04.txt
 Date: 13/08/2018
 Authors: Paul Hoffman
 Working Group: Crypto Forum (cfrg)
 Formats: txt
Quantum computing is the study of computers that use quantum features in calculations. For over 20 years, it has been known that if very large, specialized quantum computers could be built, they could have a devastating effect on asymmetric classical cryptographic algorithms such as RSA and elliptic curve signatures and key exchange, as well as (but in smaller scale) on symmetric cryptographic algorithms such as block ciphers, MACs, and hash functions. There has already been a great deal of study on how to create algorithms that will resist large, specialized quantum computers, but so far, the properties of those algorithms make them onerous to adopt before they are needed. Small quantum computers are being built today, but it is still far from clear when large, specialized quantum computers will be built that can recover private or secret keys in classical algorithms at the key sizes commonly used today. It is important to be able to predict when large, specialized quantum computers usable for cryptanalysis will be possible so that organization can change to post-quantum cryptographic algorithms well before they are needed. This document describes quantum computing, how it might be used to attack classical cryptographic algorithms, and possibly how to predict when large, specialized quantum computers will become feasible.
    
draft-hoffman-resolver-associated-doh-01.txt
 Associating a DoH Server with a Resolver
 
 draft-hoffman-resolver-associated-doh-01.txt
 Date: 25/08/2018
 Authors: Paul Hoffman
 Working Group: Individual Submissions (none)
 Formats: txt
Some clients will want to know if there are one or more DoH servers associated with the DNS recursive resolver that the client is already using. This document describes a protocol for a resolver to tell a client what its associated DoH servers are.
    
draft-hohendorf-secure-sctp-26.txt
 Secure SCTP
 
 draft-hohendorf-secure-sctp-26.txt
 Date: 05/09/2018
 Authors: Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz
 Working Group: Individual Submissions (none)
 Formats: txt
This document explains the reason for the integration of security functionality into SCTP, and gives a short description of S-SCTP and its services. S-SCTP is fully compatible with SCTP defined in RFC4960, it is designed to integrate cryptographic functions into SCTP.
    
draft-hollenbeck-regext-rdap-openid-10.txt
 Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect
 
 draft-hollenbeck-regext-rdap-openid-10.txt
 Date: 29/08/2018
 Authors: Scott Hollenbeck
 Working Group: Individual Submissions (none)
 Formats: xml txt
The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect.
    
draft-homma-dmm-5gs-id-loc-coexistence-01.txt
 Co-existence of 3GPP 5GS and Identifier Locator Separation Architecture
 
 draft-homma-dmm-5gs-id-loc-coexistence-01.txt
 Date: 15/05/2018
 Authors: Shunsuke Homma, Kenta Kawakami, Arashmid Akhavain
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document describes an approach to introduce Identifier Locator Separation architecture into 3GPP 5GS with low-impact on its specification, and shows the features and considerations of this approach.
    
draft-homma-nfvrg-slice-gateway-00.txt
 Gateway Function for Network Slicing
 
 draft-homma-nfvrg-slice-gateway-00.txt
 Date: 02/07/2018
 Authors: Shunsuke Homma, Xavier de Foy, A. Galis
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the roles and requirements for a slice gateway that is a data plane function or function group for connecting/disconnecting and compose/decompose network slice subnets and providing network slices from end to end. The interworkings between management and control elements at the management and control planes with the gateway function for controlling and orchestrating end-to-end network slices are also presented in this document.
    
draft-hong-i2nsf-nsf-monitoring-data-model-04.txt
 YANG Data Model for Monitoring I2NSF Network Security Functions
 
 draft-hong-i2nsf-nsf-monitoring-data-model-04.txt
 Date: 02/07/2018
 Authors: Dongjin Hong, Jaehoon Jeong, Jinyong Kim, Susan Hares, Liang Xia, Henk Birkholz
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
This document proposes a YANG data model for monitoring Network Security Functions (NSFs) in the Interface to Network Security Functions (I2NSF) system. If the monitoring of NSFs is performed in a comrehensive way, it is possible to detect the indication of malicious activity, anomalous behavior or the potential sign of denial of service attacks in a timely manner. This monitoring functionality is based on the monitoring information that is generated by NSFs. Thus, this document describes not only a data tree to specify an information model for monitoring NSFs, but also the corresponding YANG data model for monitoring NSFs.
    
draft-hong-icnrg-ccnx-nrs-02.txt
 CCNx Extension for Name Resolution Service
 
 draft-hong-icnrg-ccnx-nrs-02.txt
 Date: 02/07/2018
 Authors: jhong@etri.re.kr, Taewan You, Yong-Geun Hong
 Working Group: Individual Submissions (none)
 Formats: txt xml
This document presents the CCNx extension for Name Resolution Service (NRS). It describes TLV-based CCNx messages for NRS and modification of CCNx forwarder where the messages for NRS are working.
    
draft-hong-icnrg-icnnrs-01.txt
 Architectural Considerations of ICN using Name Resolution Service
 
 draft-hong-icnrg-icnnrs-01.txt
 Date: 02/07/2018
 Authors: jhong@etri.re.kr, Taewan You, Yong-Geun Hong
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document discusses architectural considerations and implications of Information-Centric Networking (ICN) related to the usage of the Name Resolution Service (NRS). It describes how ICN architecture changes and what implications are in the routing system when NRS is utilized in ICN.
    
draft-hong-iot-edge-computing-00.txt
 Problem Statement of IoT integrated with Edge Computing
 
 draft-hong-iot-edge-computing-00.txt
 Date: 02/07/2018
 Authors: jhong@etri.re.kr, Yong-Geun Hong, Joo-Sang Youn
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes new challenges for IoT services issued by the changes of the IoT environment. In order to address those new challenges, the integration of Edge computing and IoT has been emerged as a promising solution. This document provides the concept of IoT integrated with Edge computing as well as its use cases to discuss the benefits and challenges of Edge computing mainly focused on IoT data. The direction of Edge computing for IoT should be discussed in IETF/IRTF.
    
draft-hou-6lo-plc-04.txt
 Transmission of IPv6 Packets over PLC Networks
 
 draft-hou-6lo-plc-04.txt
 Date: 02/07/2018
 Authors: Jianqiang Hou, Bing Liu, Yong-Geun Hong, Xiaojun Tang, Charles Perkins
 Working Group: Individual Submissions (none)
 Formats: txt
Power Line Communication (PLC), namely using the electric-power lines for indoor and outdoor communications, has been widely applied to support Advanced Metering Infrastructure (AMI), especially smart meters for electricity. The inherent advantage of existing electricity infrastructure facilitates the expansion of PLC deployments, and moreover, a wide variety of accessible devices raises the potential demand of IPv6 for future applications. This document describes how IPv6 packets are transported over constrained PLC networks, such as ITU-T G.9903, IEEE 1901.1, IEEE 1901.2 and IEEE 1901.2a.
    
draft-housley-suit-cose-hash-sig-04.txt
 Use of the Hash-based Signature Algorithm with CBOR Object Signing and Encryption (COSE)
 
 draft-housley-suit-cose-hash-sig-04.txt
 Date: 02/07/2018
 Authors: Russell Housley
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies the conventions for using the Leighton-Micali Signature (LMS) algorithm for digital signatures with the CBOR Object Signing and Encryption (COSE) syntax.
    
draft-housley-tls-tls13-cert-with-extern-psk-01.txt
 TLS 1.3 Extension for Certificate-based Authentication with an External Pre-Shared Key
 
 draft-housley-tls-tls13-cert-with-extern-psk-01.txt
 Date: 16/08/2018
 Authors: Russell Housley
 Working Group: Transport Layer Security (tls)
 Formats: txt
This document specifies a TLS 1.3 extension that allows a server to authenticate with a certificate while providing an external pre- shared key (PSK) as an input to the key schedule.
    
draft-hoyland-tls-layered-exported-authenticator-00.txt
 Layered Exported Authenticators in TLS
 
 draft-hoyland-tls-layered-exported-authenticator-00.txt
 Date: 25/06/2018
 Authors: Jonathan Hoyland
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an extension that allows for Exported Authenticators (EAs) to authenticate each other. The extension includes a reference to a previous EA. An EA containing this extension constitues an attestation of the authenticity of the referenced EA.
    
draft-hsmit-bmp-extensible-routemon-msgs-00.txt
 BMP Extensible Route-Monitoring Messages
 
 draft-hsmit-bmp-extensible-routemon-msgs-00.txt
 Date: 18/07/2018
 Authors: Henk Smit
 Working Group: Individual Submissions (none)
 Formats: xml txt
The BGP Monitoring Protocol (BMP) is defined in RFC7854. Most of the types of messages in BMP are extensible via the mechanism of TLVs. However, the most important type of message, the route-monitoring message, has a fixed format. This document proposes a relatively small change to the format of BMP route-monitoring messages. The new format of route-monitoring messages is no longer fixed-format, but tlv-encoded. This document also proposes to split the route-monitoring message-type into 3 new message-types. For Adj-RIB-In, Adj-RIB-Out and Loc-RIB. This document proposes two types of TLVs to be used in this new format. A TLV to report the BGP update message itself. And a flags- field TLV, to report state of the reported routes.
    
draft-httpi-12.txt
 Need for an httpi intelligent service
 
 draft-httpi-12.txt
 Date: 15/07/2018
 Authors: pradeep xplorer
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the need for an httpi protocol similar to https/http used for intelligent surfing of information.
    
draft-hu-bess-srv6-vpn-bypass-sid-00.txt
 Enhance IPv6-Segment-Routing-based EVPN VPWS All Active Usage
 
 draft-hu-bess-srv6-vpn-bypass-sid-00.txt
 Date: 02/07/2018
 Authors: Chongyang Hu
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the extensions to enhance SRv6 EVPN VPWS all- active Reliability.
    
draft-hu-bier-bfd-01.txt
 BIER BFD
 
 draft-hu-bier-bfd-01.txt
 Date: 30/07/2018
 Authors: fangwei hu, Gregory Mirsky, Quan Xiong, Chang Liu
 Working Group: Individual Submissions (none)
 Formats: txt
Point to multipoint (P2MP) BFD is designed to verify multipoint connectivity. This document specifies the support of P2MP BFD in BIER network.
    
draft-hu-isis-srv6-yang-00.txt
 YANG Data Model for IS-IS SRv6
 
 draft-hu-isis-srv6-yang-00.txt
 Date: 31/07/2018
 Authors: Zhibo Hu, Dan Ye, Yingzhen Qu, Jiajia Dong
 Working Group: Individual Submissions (none)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage IS-IS SRv6 [I-D.bashandy-isis-srv6-extensions].
    
draft-hu-lsr-isis-path-mtu-00.txt
 IS-IS Extensions for Path MTU
 
 draft-hu-lsr-isis-path-mtu-00.txt
 Date: 30/06/2018
 Authors: Zhibo Hu, Yongqing Zhu, Zhenbin Li, Longfei Dai
 Working Group: Individual Submissions (none)
 Formats: txt xml pdf
Segment routing (SR) leverages the source routing mechanism. It allows for a flexible definition of end-to-end paths with IGP topologies by encoding paths as sequences of topological sub-paths which is called segments. These segments are advertised by the link- state routing protocols (IS-IS and OSPF). Unlike the MPLS, SR does not have the specific path construction signaling so that it cannot support the Path MTU. This draft provides the necessary IS-IS extensions about the Path MTU that need to be used on SR.
    
draft-hu-lsr-network-automatic-optimization-00.txt
 Network Automatic Optimization Based on Dynamic Adjustment of IGP Metrics
 
 draft-hu-lsr-network-automatic-optimization-00.txt
 Date: 02/07/2018
 Authors: Zhibo Hu, Gang Yan, Junda Yao
 Working Group: Individual Submissions (none)
 Formats: txt
The centralized traffic engineering technology adopts centralized calculation, PCE/SDN performs centralized calculation based on the collected link-status and TE information collected by BGP-LS/IGP, so that the traffic in the network is optimized to the optimization goal. The distributed traffic engineering technology uses IGP to calculate the shortest path. Each node in the network calculates the next hop to a destination address based on the same algorithm and network topology. Each algorithm can calculate a shortest path tree in the entire network, which can reduce the amount of calculation, so that the hard convergence time of TE can be close to the convergence time of IGP. The distributed computing and management methods can not co-ordinate management of network bandwidth resources. As a result, network bandwidth resources can not be planned in an integrated manner, bandwidth resources are wasted, and even tunnels cannot be established. This document attempts to discuss a automatic network optimization function of the distributed traffic engineering technology by the method of dynamically adjusting the link Metric.
    
draft-hu-nvo3-vxlan-gpe-extension-for-vbng-00.txt
 VXLAN GPE Extension for Packets Exchange Between Control and User Plane of vBNG
 
 draft-hu-nvo3-vxlan-gpe-extension-for-vbng-00.txt
 Date: 13/06/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-spring-segment-routing-rsvp-te-interop-00.txt
 Segment Routing interworking with RSVP-TE
 
 draft-hu-spring-segment-routing-rsvp-te-interop-00.txt
 Date: 30/06/2018
 Authors: Zhibo Hu, Gang Yan, Xia Chen, Junda Yao
 Working Group: Individual Submissions (none)
 Formats: txt
A Segment Routing (SR) node steers a packet through an ordered list of instructions, called segments. A segment can represent any instruction, topological or service-based. Segment Routing (SR) is a protocol designed to forward packets on the network based on the concept of source routing. The Segment Routing architecture can be directly applied to the MPLS data plane with no change in the forwarding plane. It simplifies the MPLS control protocol, simplifies the configuration of the network, and can achieve SDN better. Resource Reservation Protocol - Traffic Engineering (RSVP-TE) has the ability of path planning and resource reservation. In the process of traditional network evolution to Segment Routing, there will inevitably be coexistence of RSVP-TE and Segment Routing. The Document describes how to interact with nodes that support Segment Routing capabilities and nodes that support RSVP-TE capabilities.
    
draft-huang-detnet-single-path-pref-01.txt
 Single-path PREF
 
 draft-huang-detnet-single-path-pref-01.txt
 Date: 13/06/2018
 Authors: Daniel Huang
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document specifies PREF on the single path for low-rate traffic, and illustrates in details the implementation solutions as well as the impacts on the data plane specified in [I-D.ietf-detnet-dp-alt].
    
draft-huang-rsca-sdm-eon-00.txt
 RSCA method with Dividing Frequency Slots Area in Space Division Multiplexing Elastic Optical Networks
 
 draft-huang-rsca-sdm-eon-00.txt
 Date: 21/05/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-prireq-00.txt
 DNS-SD Privacy and Security Requirements
 
 draft-huitema-dnssd-prireq-00.txt
 Date: 30/06/2018
 Authors: Christian Huitema
 Working Group: Extensions for Scalable DNS Service Discovery (dnssd)
 Formats: xml txt
DNS-SD (DNS Service Discovery) normally discloses information about devices offering and 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, serious privacy problems arise. We analyze the requirements of a privacy respecting discovery service.
    
draft-huitema-dnssd-privacyscaling-01.txt
 DNS-SD Privacy Scaling Tradeoffs
 
 draft-huitema-dnssd-privacyscaling-01.txt
 Date: 30/06/2018
 Authors: Christian Huitema
 Working Group: Extensions for Scalable DNS Service Discovery (dnssd)
 Formats: xml txt
DNS-SD (DNS Service Discovery) normally discloses information about both the devices offering services and the devices requesting services. This information includes host names, network parameters, and possibly a further description of the corresponding service instance. Especially when mobile devices engage in DNS Service Discovery over Multicast DNS at a public hotspot, a serious privacy problem arises. The draft currently progressing in the DNS-SD Working Group assumes peer-to-peer pairing between the service to be discovered and each of its clients. This has good security properties, but creates scaling issues, because each server needs to publish as many announcements as it has paired clients. This leads to large number of operations when servers are paired with many clients. Different designs are possible. For example, if there was only one server "discovery key" known by each authorized client, each server would only have to announce a single record, and clients would only have to process one response for each server that is present on the network. Yet, these designs will present different privacy profiles, and pose different management challenges. This draft analyses the tradeoffs between privacy and scaling in a set of different designs, using either shared secrets or public keys.
    
draft-huitema-quic-dnsoquic-05.txt
 Specification of DNS over Dedicated QUIC Connections
 
 draft-huitema-quic-dnsoquic-05.txt
 Date: 29/06/2018
 Authors: Christian Huitema, Melinda Shore, Allison Mankin, Sara Dickinson, Jana Iyengar
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the use of QUIC to provide transport privacy for DNS. The encryption provided by QUIC has similar properties to that provided by TLS, while QUIC transport eliminates the head-of- line blocking issues inherent with TCP and provides more efficient error corrections than UDP. DNS over QUIC (DNS/QUIC) has privacy properties similar to DNS over TLS specified in RFC7858, and performance similar to classic DNS over UDP.
    
draft-hunt-secevent-sstp-00.txt
 Symmetric SET Transfer Protocol
 
 draft-hunt-secevent-sstp-00.txt
 Date: 22/03/2018
 Authors: Phil Hunt, Anthony Nadalin
 Working Group: Individual Submissions (none)
 Formats: xml txt
This specification defines how security event tokens (SETs) may be exchanged between a client and service provider using HTTP POST over TLS using a symmetric format. The specification supports three modes of operation: "push", "pull", and "push-pull" bi-directional SET exchange. The specification also defines a simple acknowledge mechanism allowing parties to confirm delivery.
    
draft-huque-dnsop-multi-provider-dnssec-03.txt
 Multi Provider DNSSEC models
 
 draft-huque-dnsop-multi-provider-dnssec-03.txt
 Date: 01/07/2018
 Authors: Shumon Huque, Pallavi Aras, John Dickinson, Jan Vcelak
 Working Group: Domain Name System Operations (dnsop)
 Formats: txt
Many enterprises today employ the service of multiple DNS providers to distribute their authoritative DNS service. Deploying DNSSEC in such an environment can have some challenges depending on the configuration and feature set in use. This document will present several deployment models that may be suitable.
    
draft-huque-dnssec-alg-nego-03.txt
 Algorithm Negotiation in DNSSEC
 
 draft-huque-dnssec-alg-nego-03.txt
 Date: 22/07/2018
 Authors: Shumon Huque, Haya Shulman, Shane Kerr
 Working Group: Individual Submissions (none)
 Formats: txt
This document specifies a DNS extension that allows a DNS client to specify a list of DNSSEC algorithms, in preference order, that the client desires to use. A DNS server upon receipt of this extension can choose to selectively respond with DNSSEC signatures using the most preferred algorithm they support. This mechanism may make it easier for DNS zone operators to support signing zone data simultaneously with multiple DNSSEC algorithms, without significantly increasing the size of DNS responses. It will also allow an easier way to transition to new algorithms while still retaining support for older DNS validators that do not yet support the new algorithms.
    
draft-hyun-i2nsf-nsf-triggered-steering-06.txt
 Service Function Chaining-Enabled I2NSF Architecture
 
 draft-hyun-i2nsf-nsf-triggered-steering-06.txt
 Date: 02/07/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, Park Jung-Soo, Susan Hares
 Working Group: Individual Submissions (none)
 Formats: xml pdf txt
This document describes an architecture of the I2NSF framework using security function chaining for security policy enforcement. Security function chaining enables composite inspection of network traffic by steering the traffic through multiple types of network security functions according to the information model for NSFs capabilities in the I2NSF framework. This document explains the additional components integrated into the I2NSF framework and their functionalities to achieve security function chaining. It also describes representative use cases to address major benefits from the proposed architecture.
    
draft-hyun-i2nsf-registration-interface-dm-06.txt
 I2NSF Registration Interface Data Model
 
 draft-hyun-i2nsf-registration-interface-dm-06.txt
 Date: 26/07/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, Park Jung-Soo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document defines an information model and a YANG data model for Interface to Network Security Functions (I2NSF) Registration Interface between Security Controller and Developer's Management System (DMS). The objective of these information and data models is to support NSF search, instantiation and registration according to required security capabilities via I2NSF Registration Interface.
    
draft-hyun-i2nsf-registration-interface-im-06.txt
 Registration Interface Information Model
 
 draft-hyun-i2nsf-registration-interface-im-06.txt
 Date: 17/07/2018
 Authors: Sangwon Hyun, Jaehoon Jeong, TaeKyun Roh, Sarang Wi, Park Jung-Soo
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document describes an information model for Interface to Network Security Functions (I2NSF) Registration Interface between Security Controller and Developer's Management System (DMS). The information model is required to support NSF instance via the registration interface. This document explains the procedures over I2NSF registration interface for these functionalities. It also describes the detailed information which should be exchanged via I2NSF registration interface.
    
draft-iab-iotsi-workshop-02.txt
 Report from the Internet of Things (IoT) Semantic Interoperability (IOTSI) Workshop 2016
 
 draft-iab-iotsi-workshop-02.txt
 Date: 02/07/2018
 Authors: Jaime Jimenez, Hannes Tschofenig, Dave Thaler
 Working Group: Internet Architecture Board (iab)
 Formats: xml txt
This document provides a summary of the 'Workshop on Internet of Things (IoT) Semantic Interoperability (IOTSI)', which took place in Santa Clara, California, on March 17-18, 2016. The main goal of the workshop was to foster a discussion on the different approaches used by companies and Standards Developing Organizations (SDOs) to accomplish interoperability at the application layer. This report summarizes the discussions, and lists recommendations to the standards community. The views and positions in this report are those of the workshop participants and do not necessarily reflect those of the authors and the Internet Architecture Board (IAB), which organized the workshop.
    
draft-iab-marnew-report-02.txt
 IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW) Report
 
 draft-iab-marnew-report-02.txt
 Date: 25/05/2018
 Authors: Natasha Rooney, Spencer Dawkins
 Working Group: Internet Architecture Board (iab)
 Formats: txt xml
The Internet Architecture Board (IAB) and GSM Association (GSMA) held a joint workshop on "Managing Radio Networks in an Encrypted World" (MaRNEW), on September 24-25, 2015. This workshop aimed to discuss solutions for bandwidth optimisation on mobile networks for encrypted content, as current solutions rely on unencrypted content which is not indicative of the security needs of today's Internet users. The workshop gathered IETF attendees, IAB members and participants from various organisations involved in the telecommunications industry including original equipment manufacturers, content providers, and mobile network operators. The group discussed the current Internet encryption trends and deployment issues identified within the IETF, and the privacy needs of users which should be adhered. Solutions designed around sharing data from the network to the endpoints and vice versa were then discussed as well as analysing whether issues experienced when using current transport layer protocols are also playing a role here. Content providers and CDNs gave their own views of their experiences delivering their content with mobile network operators. Finally, technical responses to regulation was discussed to help the regulated industries relay the issues of impossible-to-implement or bad-for- privacy technologies back to regulators. A group of suggested solutions were devised which will be discussed in various IETF groups moving forward.
    
draft-iab-path-signals-00.txt
 Path Signals
 
 draft-iab-path-signals-00.txt
 Date: 16/05/2018
 Authors: Ted Hardie
 Working Group: Internet Architecture Board (iab)
 Formats: txt
This document discusses the nature of signals seen by on-path elements, contrasting implicit and explicit signals. For example, TCP's state mechanics uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on- path network elements lack those signals. This document recommends that explict signals be used by transports which encrypt their state mechanics. It also recommends that a signal be exposed to the path only when the signal's originator intends that it be used by the network elements on the path.
    
draft-iab-protocol-maintenance-00.txt
 The Harmful Consequences of the Robustness Principle
 
 draft-iab-protocol-maintenance-00.txt
 Date: 03/05/2018
 Authors: Martin Thomson
 Working Group: Internet Architecture Board (iab)
 Formats: txt xml
Jon Postel's famous statement of "Be liberal in what you accept, and conservative in what you send" is a principle that has long guided the design and implementation of Internet protocols. The posture this statement advocates promotes interoperability, but can produce negative effects in the protocol ecosystem in the long term. Those effects can be avoided by maintaining protocols.
    
draft-icann-registrar-interfaces-01.txt
 ICANN Registrar Interfaces
 
 draft-icann-registrar-interfaces-01.txt
 Date: 18/09/2018
 Authors: Gustavo Lozano, Eduardo Alvarez
 Working Group: Individual Submissions (none)
 Formats: txt
This document describes the interfaces provided by ICANN to Registrars and Data Escrow Agents in order to fulfill the data escrow requirements of the Registrar Accreditation Agreement and the Registrar Data Escrow Specifications.
    
draft-idr-bgp-route-refresh-options-05.txt
 Extension to BGP's Route Refresh Message
 
 draft-idr-bgp-route-refresh-options-05.txt
 Date: 29/08/2018
 Authors: Keyur Patel, Aamod Vyavaharkar, Niloofar Fazlollahi, Tony Przygienda
 Working Group: Individual Submissions (none)
 Formats: txt xml
[RFC2918] defines a route refresh capability to be exchanged between BGP speakers. BGP speakers that support this capability are advertising that they can resend the entire BGP Adj-RIB-Out on receipt of a refresh request. By supporting this capability, BGP speakers are more flexible in applying any inbound routing policy changes as they no longer have to store received routes in their unchanged form or reset the session when an inbound routing policy change occurs. The route refresh capability is advertised per AFI, SAFI combination. There are newer AFI, SAFI types that have been introduced to BGP that support a variety of route types (e.g. IPv4/MVPN, L2VPN/EVPN). Currently, there is no way to request a subset of routes in a Route Refresh message for a given AFI, SAFI. This draft defines route refresh capability extensions that help BGP speakers to request a subset of routes for a given address family. This is expected to reduce the amount of update traffic being generated by route refresh requests as well as lessen the burden on the router servicing such requests.
    
draft-idr-rfc8203bis-00.txt
 Extended BGP Administrative Shutdown Communication
 
 draft-idr-rfc8203bis-00.txt
 Date: 30/04/2018
 Authors: Job Snijders, Jakob Heitz, John Scudder, Alexander Azimov
 Working Group: Individual Submissions (none)
 Formats: xml txt
This document enhances the BGP Cease NOTIFICATION message "Administrative Shutdown" and "Administrative Reset" subcodes for operators to transmit a short freeform message to describe why a BGP session was shutdown or reset. This document updates RFC 4486 and obsoletes RFC 8203 by defining an Extended BGP Administrative Shutdown Communication to improve communication using multibyte character sets.
    
draft-ietf-6lo-ap-nd-07.txt
 Address Protected Neighbor Discovery for Low-power and Lossy Networks
 
 draft-ietf-6lo-ap-nd-07.txt
 Date: 03/09/2018
 Authors: Pascal Thubert, Behcet Sarikaya, Mohit Sethi
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This document defines an extension to 6LoWPAN Neighbor Discovery (ND) [RFC6775] [I-D.ietf-6lo-rfc6775-update] called Address Protected ND (AP-ND); AP-ND protects the owner of an address against address theft and impersonation inside a low-power and lossy network (LLN). Nodes supporting this extension compute a cryptographic Owner Unique Interface ID and associate it with one or more of their Registered Addresses. The Cryptographic ID identifies the owner of the Registered Address and can be used for proof-of-ownership. It is used in 6LoWPAN ND in place of the EUI-64-based unique ID that is associated with the registration. Once an address is registered with a Cryptographic ID, only the owner of that ID can modify the registration information of the Registered Address, and Source Address Validation can be enforced.
    
draft-ietf-6lo-backbone-router-07.txt
 IPv6 Backbone Router
 
 draft-ietf-6lo-backbone-router-07.txt
 Date: 03/09/2018
 Authors: Pascal Thubert, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
Backbone Routers placed at the wireless edge of a backbone link interconnect multiple wireless links at Layer-3 to form a large MultiLink Subnet, so that the broadcast domain of the backbone does not extend to the wireless links. Wireless nodes register or are proxy-registered to a Backbone Router to establish IPv6 Neighbor Discovery proxy services, and the Backbone Router takes care of the ND operation on behalf of registered nodes and ensures and routes towards the registered addresses over the wireless interface.
    
draft-ietf-6lo-blemesh-03.txt
 IPv6 Mesh over BLUETOOTH(R) Low Energy using IPSP
 
 draft-ietf-6lo-blemesh-03.txt
 Date: 02/07/2018
 Authors: Carles Gomez, Seyed Darroudi, Teemu Savolainen, Michael Spoerk
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
RFC 7668 describes the adaptation of 6LoWPAN techniques to enable IPv6 over Bluetooth low energy networks that follow the star topology. However, recent Bluetooth specifications allow the formation of extended topologies as well. This document specifies the mechanisms needed to enable IPv6 over mesh networks composed of Bluetooth low energy links established by using the Bluetooth Internet Protocol Support Profile.
    
draft-ietf-6lo-deadline-time-02.txt
 Packet Delivery Deadline time in 6LoWPAN Routing Header
 
 draft-ietf-6lo-deadline-time-02.txt
 Date: 31/08/2018
 Authors: Lijo Thomas, Satish Anamalamudi, S.V.R Anand, Malati Hegde, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt
This document specifies a new type for the 6LoWPAN routing header containing the delivery deadline time for data packets. The deadline time enables forwarding and scheduling decisions for time critical IoT M2M applications that need deterministic delay guarantees over constrained networks and operate within time-synchronized networks.
    
draft-ietf-6lo-fragment-recovery-00.txt
 6LoWPAN Selective Fragment Recovery
 
 draft-ietf-6lo-fragment-recovery-00.txt
 Date: 20/09/2018
 Authors: Pascal Thubert
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: xml txt
This draft updates RFC 4944 with a simple protocol to recover individual fragments across a route-over mesh network, with a minimal flow control to protect the network against bloat.
    
draft-ietf-6lo-nfc-10.txt
 Transmission of IPv6 Packets over Near Field Communication
 
 draft-ietf-6lo-nfc-10.txt
 Date: 17/07/2018
 Authors: Younghwan Choi, Yong-Geun Hong, Joo-Sang Youn, Dongkyun Kim, JinHyeock Choi
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
Near field communication (NFC) is a set of standards for smartphones and portable devices to establish radio communication with each other by touching them together or bringing them into proximity, usually no more than 10 cm. NFC standards cover communications protocols and data exchange formats, and are based on existing radio-frequency identification (RFID) standards including ISO/IEC 14443 and FeliCa. The standards include ISO/IEC 18092 and those defined by the NFC Forum. The NFC technology has been widely implemented and available in mobile phones, laptop computers, and many other devices. This document describes how IPv6 is transmitted over NFC using 6LowPAN techniques.
    
draft-ietf-6lo-rfc6775-update-21.txt
 Registration Extensions for 6LoWPAN Neighbor Discovery
 
 draft-ietf-6lo-rfc6775-update-21.txt
 Date: 19/06/2018
 Authors: Pascal Thubert, Erik Nordmark, Samita Chakrabarti, Charles Perkins
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt xml
This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies including the Routing Registrars performing routing for host routes and/or proxy Neighbor Discovery in a low power network.
    
draft-ietf-6lo-use-cases-05.txt
 IPv6 over Constrained Node Networks (6lo) Applicability & Use cases
 
 draft-ietf-6lo-use-cases-05.txt
 Date: 01/07/2018
 Authors: Yong-Geun Hong, Carles Gomez, Abdur Sangi, Take Aanstoot, Samita Chakrabarti
 Working Group: IPv6 over Networks of Resource-constrained Nodes (6lo)
 Formats: txt
This document describes the applicability of IPv6 over constrained node networks (6lo) and provides practical deployment examples. In addition to IEEE 802.15.4, various link layer technologies such as ITU-T G.9959 (Z-Wave), BLE, DECT-ULE, MS/TP, NFC, PLC (IEEE 1901.2), and IEEE 802.15.4e (6tisch) are used as examples. The document targets an audience who like to understand and evaluate running end- to-end IPv6 over the constrained node networks connecting devices to each other or to other devices on the Internet (e.g. cloud infrastructure).
    
draft-ietf-6man-icmp-limits-00.txt
 ICMPv6 errors for discarding packets due to processing limits
 
 draft-ietf-6man-icmp-limits-00.txt
 Date: 29/05/2018
 Authors: Tom Herbert
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
Network nodes may discard packets if they are unable to process protocol headers of packets due to processing constraints or limits. When such packets are dropped, the sender receives no indication so it cannot take action to address the cause of discarded packets. This document defines ICMPv6 errors that can be sent by a node that discards packets because it is unable to process the protocol headers. A node that receives such an ICMPv6 error may be able to modify what it sends in future packets to avoid subsequent packet discards.
    
draft-ietf-6man-ipv6only-flag-02.txt
 IPv6 Router Advertisement IPv6-Only Flag
 
 draft-ietf-6man-ipv6only-flag-02.txt
 Date: 14/08/2018
 Authors: Robert Hinden, Brian Carpenter
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
This document specifies a Router Advertisement Flag to indicate to hosts that the administrator has configured the router to advertise that the link is IPv6-Only. This document updates RFC5175.
    
draft-ietf-6man-rfc4941bis-00.txt
 Privacy Extensions for Stateless Address Autoconfiguration in IPv6
 
 draft-ietf-6man-rfc4941bis-00.txt
 Date: 02/07/2018
 Authors: Fernando Gont, Suresh Krishnan, Thomas Narten, Richard Draves
 Working Group: IPv6 Maintenance (6man)
 Formats: txt
Nodes use IPv6 stateless address autoconfiguration to generate addresses using a combination of locally available information and information advertised by routers. Addresses are formed by combining network prefixes with an interface identifier. This document describes an extension that causes nodes to generate global scope addresses from interface identifiers that change over time. Changing the interface identifier (and the global scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when different addresses used in different transactions actually correspond to the same node.
    
draft-ietf-6man-rfc6434-bis-09.txt
 IPv6 Node Requirements
 
 draft-ietf-6man-rfc6434-bis-09.txt
 Date: 16/07/2018
 Authors: Tim Chown, John Loughney, Timothy Winters
 Working Group: IPv6 Maintenance (6man)
 Formats: xml txt
This document defines requirements for IPv6 nodes. It is expected that IPv6 will be deployed in a wide range of devices and situations. Specifying the requirements for IPv6 nodes allows IPv6 to function well and interoperate in a large number of situations and deployments. This document obsoletes RFC 6434, and in turn RFC 4294.
    
draft-ietf-6man-segment-routing-header-14.txt
 IPv6 Segment Routing Header (SRH)
 
 draft-ietf-6man-segment-routing-header-14.txt
 Date: 29/06/2018
 Authors: Clarence Filsfils, Stefano Previdi, John Leddy, Satoru Matsushima, daniel.voyer@bell.ca
 Working Group: IPv6 Maintenance (6man)
 Formats: txt xml
Segment Routing can be applied to the IPv6 data plane using a new type of Routing Extension Header. This document describes the Segment Routing Extension Header and how it is used by Segment Routing capable nodes.
    
draft-ietf-6tisch-6top-protocol-12.txt
 6TiSCH Operation Sublayer Protocol (6P)
 
 draft-ietf-6tisch-6top-protocol-12.txt
 Date: 20/06/2018
 Authors: Qin Wang, Xavier Vilajosana, Thomas Watteyne
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This document defines the IPv6 over the TSCH mode of IEEE 802.15.4e (6TiSCH) Operation Sublayer (6top) Protocol (6P), which enables distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes to add/delete TSCH cells to one another. 6P is part of the 6TiSCH Operation Sublayer (6top), the next higher layer to the IEEE Std 802.15.4 TSCH medium access control layer. The 6top layer terminates the 6top Protocol defined in this document, and runs one or more 6top Scheduling Function(s). A 6top Scheduling Function (SF) decides when to add/delete cells, and triggers 6P Transactions. This document lists the requirements for an SF, but leaves the definition of SFs out of scope.
    
draft-ietf-6tisch-architecture-14.txt
 An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4
 
 draft-ietf-6tisch-architecture-14.txt
 Date: 25/04/2018
 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-02.txt
 6tisch Zero-Touch Secure Join protocol
 
 draft-ietf-6tisch-dtsecurity-zerotouch-join-02.txt
 Date: 30/04/2018
 Authors: Michael Richardson, Benjamin Damm
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This document describes a Zero-touch Secure Join (ZSJ) mechanism to enroll a new device (the "pledge") into a IEEE802.15.4 TSCH network using the 6tisch signaling mechanisms. The resulting device will obtain a domain specific credential that can be used with either 802.15.9 per-host pair keying protocols, or to obtain the network- wide key from a coordinator. The mechanism describe here is an augmentation to the one-touch mechanism described in [I-D.ietf-6tisch-minimal-security], and a constrained version of [I-D.ietf-anima-bootstrapping-keyinfra].
    
draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt
 IEEE802.15.4 Informational Element encapsulation of 6tisch Join and Enrollment Information
 
 draft-ietf-6tisch-enrollment-enhanced-beacon-00.txt
 Date: 20/07/2018
 Authors: Diego Dujovne, Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
In TSCH mode of IEEE802.15.4, as described by [RFC8180], opportunities for broadcasts are limited to specific times and specific channels. Nodes in a TSCH network typically frequently send Enhanced Beacon (EB) frames to announce the presence of the network. This document provides a mechanism by which small details critical for new nodes (pledges) and long sleeping nodes may be carried within the Enhanced Beacon.
    
draft-ietf-6tisch-minimal-security-06.txt
 Minimal Security Framework for 6TiSCH
 
 draft-ietf-6tisch-minimal-security-06.txt
 Date: 25/05/2018
 Authors: Malisa Vucinic, Jonathan Simon, Kris Pister, Michael Richardson
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: txt
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, a new Stateless-Proxy CoAP option, and configures the rest of the 6TiSCH communication stack for this join process to occur in a secure manner. Additional security mechanisms may be added on top of this minimal framework.
    
draft-ietf-6tisch-msf-00.txt
 6TiSCH Minimal Scheduling Function (MSF)
 
 draft-ietf-6tisch-msf-00.txt
 Date: 21/08/2018
 Authors: Tengfei Chang, Malisa Vucinic, Xavier Vilajosana, Simon Duquennoy, Diego Dujovne
 Working Group: IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
 Formats: xml txt
This specification defines the 6TiSCH Minimal Scheduling Function (MSF). This Scheduling Function describes both the behavior of a node when joining the network, and how the communication schedule is managed in a distributed fashion. MSF builds upon the 6TiSCH Operation Sublayer Protocol (6P) and the Minimal Security Framework for 6TiSCH.
    
draft-ietf-ace-coap-est-05.txt
 EST over secure CoAP (EST-coaps)
 
 draft-ietf-ace-coap-est-05.txt
 Date: 18/07/2018
 Authors: Peter van der Stok, Panos Kampanakis, Sandeep Kumar, Michael Richardson, Martin Furuhed, Shahid Raza
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt pdf xml
Enrollment over Secure Transport (EST) is used as a certificate provisioning protocol over HTTPS. Low-resource devices often use the lightweight Constrained Application Protocol (CoAP) for message exchanges. This document defines how to transport EST payloads over secure CoAP (EST-coaps), which allows low-resource constrained devices to use existing EST functionality for provisioning certificates.
    
draft-ietf-ace-cwt-proof-of-possession-03.txt
 Proof-of-Possession Key Semantics for CBOR Web Tokens (CWTs)
 
 draft-ietf-ace-cwt-proof-of-possession-03.txt
 Date: 29/06/2018
 Authors: Michael Jones, Ludwig Seitz, Goeran Selander, Samuel Erdtman, Hannes Tschofenig
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: xml txt
This specification describes how to declare in a CBOR Web Token (CWT) that the presenter of the CWT possesses a particular proof-of- possession key. Being able to prove possession of a key is also sometimes described as being the holder-of-key. This specification provides equivalent functionality to "Proof-of-Possession Key Semantics for JSON Web Tokens (JWTs)" (RFC 7800), but using CBOR and CWTs rather than JSON and JWTs.
    
draft-ietf-ace-dtls-authorize-04.txt
 Datagram Transport Layer Security (DTLS) Profile for Authentication and Authorization for Constrained Environments (ACE)
 
 draft-ietf-ace-dtls-authorize-04.txt
 Date: 06/09/2018
 Authors: Stefanie Gerdes, Olaf Bergmann, Carsten Bormann, Goeran Selander, Ludwig Seitz
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt xml
This specification defines a profile for delegating client authentication and authorization in a constrained environment by establishing a Datagram Transport Layer Security (DTLS) channel between resource-constrained nodes. The protocol relies on DTLS for communication security between entities in a constrained network using either raw public keys or pre-shared keys. A resource- constrained node can use this protocol to delegate management of authorization information to a trusted host with less severe limitations regarding processing power and memory.
    
draft-ietf-ace-oauth-authz-14.txt
 Authentication and Authorization for Constrained Environments (ACE) using the OAuth 2.0 Framework (ACE-OAuth)
 
 draft-ietf-ace-oauth-authz-14.txt
 Date: 19/09/2018
 Authors: Ludwig Seitz, Goeran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes Tschofenig
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
This specification defines a framework for authentication and authorization in Internet of Things (IoT) environments called ACE- OAuth. The framework is based on a set of building blocks including OAuth 2.0 and CoAP, thus making a well-known and widely used authorization solution suitable for IoT devices. Existing specifications are used where possible, but where the constraints of IoT devices require it, extensions are added and profiles are defined.
    
draft-ietf-ace-oauth-params-00.txt
 Additional OAuth Parameters for Authorization in Constrained Environments (ACE)
 
 draft-ietf-ace-oauth-params-00.txt
 Date: 18/09/2018
 Authors: Ludwig Seitz
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt
This specification defines new parameters for the OAuth 2.0 token and introspection endpoints when used with framework for authentication and authorization for constrained environments (ACE). These are used to express the desired audience of a requested access token, the desired proof-of-possession key, the proof-of-possession key that the AS has selected, and the key the RS should use to authenticate to the client.
    
draft-ietf-ace-oscore-profile-02.txt
 OSCORE profile of the Authentication and Authorization for Constrained Environments Framework
 
 draft-ietf-ace-oscore-profile-02.txt
 Date: 29/06/2018
 Authors: Ludwig Seitz, Francesca Palombini, Martin Gunnarsson, Goeran Selander
 Working Group: Authentication and Authorization for Constrained Environments (ace)
 Formats: txt xml
This memo specifies a profile for the Authentication and Authorization for Constrained Environments (ACE) framework. It utilizes Object Security for Constrained RESTful Environments (OSCORE) to provide communication security, server authentication, and proof-of-possession for a key owned by the client and bound to an OAuth 2.0 access token.
    
draft-ietf-acme-acme-14.txt
 Automatic Certificate Management Environment (ACME)
 
 draft-ietf-acme-acme-14.txt
 Date: 10/08/2018
 Authors: Richard Barnes, Jacob Hoffman-Andrews, Daniel McCarney, James Kasten
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
Public Key Infrastructure X.509 (PKIX) certificates are used for a number of purposes, the most significant of which is the authentication of domain names. Thus, certification authorities (CAs) in the Web PKI are trusted to verify that an applicant for a certificate legitimately represents the domain name(s) in the certificate. Today, this verification is done through a collection of ad hoc mechanisms. This document describes a protocol that a CA and an applicant can use to automate the process of verification and certificate issuance. The protocol also provides facilities for other certificate management functions, such as certificate revocation. RFC EDITOR: PLEASE REMOVE THE FOLLOWING PARAGRAPH: The source for this draft is maintained in GitHub. Suggested changes should be submitted as pull requests at https://github.com/ietf-wg-acme/acme [1]. Instructions are on that page as well. Editorial changes can be managed in GitHub, but any substantive change should be discussed on the ACME mailing list (acme@ietf.org).
    
draft-ietf-acme-authority-token-00.txt
 ACME Challenges Using an Authority Token
 
 draft-ietf-acme-authority-token-00.txt
 Date: 03/07/2018
 Authors: Jon Peterson, Mary Barnes, David Hancock, Chris Wendt
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt
A number of proposed challenges for the Automated Certificate Management Environment (ACME) effectively rely on an external authority issuing a token according to a particular policy. This document specifies a generic Authority Token challenge for ACME which supports subtype claims for different identifiers or namespaces that can be defined separately for specific applications of this Authority Token challenge.
    
draft-ietf-acme-authority-token-tnauthlist-00.txt
 TNAuthList profile of ACME Authority Token
 
 draft-ietf-acme-authority-token-tnauthlist-00.txt
 Date: 02/07/2018
 Authors: Chris Wendt, David Hancock, Mary Barnes, Jon Peterson
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
This document defines a profile of the Automated Certificate Management Environment (ACME) Authority Token for the automated and authorized creation of certificates for VoIP Telephone Providers to support Secure Telephony Identity (STI) using the TNAuthList defined by STI certificates.
    
draft-ietf-acme-caa-05.txt
 CAA Record Extensions for Account URI and ACME Method Binding
 
 draft-ietf-acme-caa-05.txt
 Date: 21/06/2018
 Authors: Hugo Landau
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
The CAA DNS record allows a domain to communicate issuance policy to CAs, but only allows a domain to define policy with CA-level granularity. However, the CAA specification also provides facilities for extension to admit more granular, CA-specific policy. This specification defines two such parameters, one allowing specific accounts of a CA to be identified by URI and one allowing specific methods of domain control validation as defined by the ACME protocol to be required.
    
draft-ietf-acme-email-smime-03.txt
 Extensions to Automatic Certificate Management Environment for end user S/MIME certificates
 
 draft-ietf-acme-email-smime-03.txt
 Date: 01/09/2018
 Authors: Alexey Melnikov
 Working Group: Automated Certificate Management Environment (acme)
 Formats: xml txt
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by email users that want to use S/MIME.
    
draft-ietf-acme-email-tls-05.txt
 Extensions to Automatic Certificate Management Environment for email TLS
 
 draft-ietf-acme-email-tls-05.txt
 Date: 25/07/2018
 Authors: Alexey Melnikov
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for use by TLS email services.
    
draft-ietf-acme-ip-04.txt
 ACME IP Identifier Validation Extension
 
 draft-ietf-acme-ip-04.txt
 Date: 27/07/2018
 Authors: Roland Shoemaker
 Working Group: Automated Certificate Management Environment (acme)
 Formats: txt xml
This document specifies identifiers and challenges required to enable the Automated Certificate Management Environment (ACME) to issue certificates for IP addresses.
    
draft-ietf-acme-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-03.txt
 Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO
 
 draft-ietf-alto-cdni-request-routing-alto-03.txt
 Date: 17/06/2018
 Authors: Jan Seedorf, Yang Yang, Kevin Ma, Jon Peterson, Xiao Lin
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Content Delivery Networks Interconnection (CDNI) WG is defining a set of protocols to inter-connect CDNs, to achieve multiple goals such as extending the reach of a given CDN to areas that are not covered by that particular CDN. One component that is needed to achieve the goal of CDNI is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI) [RFC7336]. [RFC8008] has defined precisely the semantics of FCI and provided guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. In this document, we define an FCI protocol using the Application-Layer Traffic Optimization (ALTO) protocol.
    
draft-ietf-alto-cost-calendar-07.txt
 ALTO Cost Calendar
 
 draft-ietf-alto-cost-calendar-07.txt
 Date: 02/07/2018
 Authors: Sabine Randriamasy, Yang Yang, Qin Wu, Deng Lingli, Nico Schwan
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The goal of Application-Layer Traffic Optimization (ALTO) is to bridge the gap between network and applications by provisioning network related information in order to allow applications to make network informed decisions. The present draft extends the ALTO cost information so as to broaden the decision possibilities of applications to not only decide 'where' to connect to, but also 'when'. This is useful to applications that need to schedule their data transfers and connections and have a degree of freedom to do so. ALTO guidance to schedule application traffic can also efficiently help for load balancing and resources efficiency. Besides, the ALTO Cost Calendar allows to schedule the ALTO requests themselves and thus to save a number of ALTO transactions. This draft proposes new capabilities and attributes on filtered cost maps and endpoint cost maps enabling an ALTO Server to provide "Cost Calendars". These capabilities are applicable to ALTO metrics with time-varying values. With ALTO Cost Calendars, an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes are specified in the IRD and ALTO Server responses.
    
draft-ietf-alto-incr-update-sse-13.txt
 ALTO Incremental Updates Using Server-Sent Events (SSE)
 
 draft-ietf-alto-incr-update-sse-13.txt
 Date: 23/07/2018
 Authors: Wendy Roome, Y. Yang, Shiwei Chen
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol provides network related information, called network information resources, to client applications so that clients can make informed decisions in utilizing network resources. For example, an ALTO server can provide network and cost maps so that an ALTO client can use the maps to determine the costs between endpoints when choosing communicating endpoints. However, the ALTO protocol does not define a mechanism to allow an ALTO client to obtain updates to the information resources, other than by periodically re-fetching them. Because some information resources (e.g., the aforementioned maps) may be large (potentially tens of megabytes), and because only parts of the information resources may change frequently (e.g., only some entries in a cost map), complete re-fetching can be extremely inefficient. This document presents a mechanism to allow an ALTO server to push updates to ALTO clients, to achieve two benefits: (1) Updates can be immediate, in that the ALTO server can send updates as soon as they are available; and (2) updates can be incremental, in that if only a small section of an information resource changes, the ALTO server can send just the changes.
    
draft-ietf-alto-path-vector-04.txt
 ALTO Extension: Path Vector Cost Type
 
 draft-ietf-alto-path-vector-04.txt
 Date: 02/07/2018
 Authors: Greg Bernstein, Shiwei Chen, Kai Gao, Young Lee, Wendy Roome, Michael Scharf, Yang Yang, J. Zhang
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
The Application-Layer Traffic Optimization (ALTO) protocol [RFC7285] has defined cost maps and endpoint cost maps to provide basic network information. However, they provide only scalar (numerical or ordinal) cost mode values, which are insufficient to satisfy the demands of solving more complex network optimization problems. This document introduces an extension to the base ALTO protocol, namely the path-vector extension, which allows ALTO clients to query information such as capacity regions for a given set of flows. A non-normative example called multi-flow scheduling is presented to illustrate the limitations of existing ALTO endpoint cost maps. After that, details of the extension are defined.
    
draft-ietf-alto-performance-metrics-04.txt
 ALTO Performance Cost Metrics
 
 draft-ietf-alto-performance-metrics-04.txt
 Date: 16/06/2018
 Authors: Qin Wu, Yang Yang, Young Lee, Dhruv Dhody, Sabine Randriamasy
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt xml
Cost Metric is a basic concept in Application-Layer Traffic Optimization (ALTO). It is used in both the Cost Map Service and the Endpoint Cost Service. Different applications may benefit from different Cost Metrics. For example, a Resource Consumer may prefer Resource Providers that offer a low delay delivery to the Resource Consumer. However the base ALTO protocol [ALTO] has documented only one single cost metric, i.e., the generic "routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]). This document, proposes a set of Cost Metrics, derived and aggregated from routing protocols with different granularity and scope, such as BGP-LS,OSPF-TE and ISIS-TE, or from end-to-end traffic management tools. It currently documents Network Performance Cost Metrics reporting on network delay, jitter, packet loss, hop count, and bandwidth. These metrics may be exposed by an ALTO Server to allow applications to determine "where" to connect based on network performance criteria. Additional Cost Metrics involving ISP specific considerations or other network technologies may be documented in further versions of this draft.
    
draft-ietf-alto-unified-props-new-04.txt
 Unified Properties for the ALTO Protocol
 
 draft-ietf-alto-unified-props-new-04.txt
 Date: 29/06/2018
 Authors: Wendy Roome, Shiwei Chen, Sabine Randriamasy, Yang Yang, J. Zhang
 Working Group: Application-Layer Traffic Optimization (alto)
 Formats: txt
This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to domains of other entities, and by presenting those properties as maps, similar to the network and cost maps in ALTO.
    
draft-ietf-anima-autonomic-control-plane-18.txt
 An Autonomic Control Plane (ACP)
 
 draft-ietf-anima-autonomic-control-plane-18.txt
 Date: 07/08/2018
 Authors: Toerless Eckert, Michael Behringer, Steinthor Bjarnason
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
Autonomic functions need a control plane to communicate, which depends on some addressing and routing. This Autonomic Management and Control Plane should ideally be self-managing, and as independent as possible of configuration. This document defines such a plane and calls it the "Autonomic Control Plane", with the primary use as a control plane for autonomic functions. It also serves as a "virtual out-of-band channel" for Operations Administration and Management (OAM) communications over a network that is secure and reliable even when the network is not configured, or misconfigured.
    
draft-ietf-anima-bootstrapping-keyinfra-16.txt
 Bootstrapping Remote Secure Key Infrastructures (BRSKI)
 
 draft-ietf-anima-bootstrapping-keyinfra-16.txt
 Date: 22/06/2018
 Authors: Max Pritikin, Michael Richardson, Michael Behringer, Steinthor Bjarnason, Kent Watsen
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document specifies automated bootstrapping of a remote secure key infrastructure (BRSKI) using manufacturer installed X.509 certificate, in combination with a manufacturer's authorizing service, both online and offline. Bootstrapping a new device can occur using a routable address and a cloud service, or using only link-local connectivity, or on limited/disconnected networks. Support for lower security models, including devices with minimal identity, is described for legacy reasons but not encouraged. Bootstrapping is complete when the cryptographic identity of the new key infrastructure is successfully deployed to the device but the established secure connection can be used to deploy a locally issued certificate to the device as well.
    
draft-ietf-anima-constrained-voucher-02.txt
 Constrained Voucher Artifacts for Bootstrapping Protocols
 
 draft-ietf-anima-constrained-voucher-02.txt
 Date: 11/09/2018
 Authors: Michael Richardson, Peter van der Stok, Panos Kampanakis
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document defines a strategy to securely assign a pledge to an owner, using an artifact signed, directly or indirectly, by the pledge's manufacturer. This artifact is known as a "voucher". This document builds upon the work in [RFC8366], encoding the resulting artifact in CBOR. Use with two signature technologies are described. Additionally, this document explains how constrained vouchers may be transported in the [I-D.ietf-ace-coap-est] protocol.
    
draft-ietf-anima-grasp-15.txt
 A Generic Autonomic Signaling Protocol (GRASP)
 
 draft-ietf-anima-grasp-15.txt
 Date: 13/07/2017
 Authors: Carsten Bormann, Brian Carpenter, Bing Liu
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document specifies the GeneRic Autonomic Signaling Protocol (GRASP), which enables autonomic nodes and autonomic service agents to dynamically discover peers, to synchronize state with each other, and to negotiate parameter settings with each other. GRASP depends on an external security environment that is described elsewhere. The technical objectives and parameters for specific application scenarios are to be described in separate documents. Appendices briefly discuss requirements for the protocol and existing protocols with comparable features.
    
draft-ietf-anima-grasp-api-02.txt
 Generic Autonomic Signaling Protocol Application Program Interface (GRASP API)
 
 draft-ietf-anima-grasp-api-02.txt
 Date: 29/06/2018
 Authors: Brian Carpenter, Bing Liu, Wendong Wang, Xiangyang Gong
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: xml txt
This document is a conceptual outline of an application programming interface (API) for the Generic Autonomic Signaling Protocol (GRASP). Such an API is needed for Autonomic Service Agents (ASA) calling the GRASP protocol module to exchange autonomic network messages with other ASAs.
    
draft-ietf-anima-prefix-management-07.txt
 Autonomic IPv6 Edge Prefix Management in Large-scale Networks
 
 draft-ietf-anima-prefix-management-07.txt
 Date: 18/12/2017
 Authors: Sheng Jiang, Zongpeng Du, Brian Carpenter, Qiong Sun
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document defines two autonomic technical objectives for IPv6 prefix management at the edge of large-scale ISP networks, with an extension to support IPv4 prefixes. An important purpose of the document is to use it for validation of the design of various components of the autonomic networking infrastructure.
    
draft-ietf-anima-reference-model-07.txt
 A Reference Model for Autonomic Networking
 
 draft-ietf-anima-reference-model-07.txt
 Date: 24/08/2018
 Authors: Michael Behringer, Brian Carpenter, Toerless Eckert, Laurent Ciavaglia, Jeferson Nobre
 Working Group: Autonomic Networking Integrated Model and Approach (anima)
 Formats: txt xml
This document describes a reference model for Autonomic Networking for managed networks. It defines the behaviour of an autonomic node, how the various elements in an autonomic context work together, and how autonomic services can use the infrastructure.
    
draft-ietf-avtcore-cc-feedback-message-02.txt
 RTP Control Protocol (RTCP) Feedback for Congestion Control
 
 draft-ietf-avtcore-cc-feedback-message-02.txt
 Date: 15/07/2018
 Authors: Zaheduzzaman Sarker, Colin Perkins, Varun Singh, Michael Ramalho
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt
This document describes an RTCP feedback message intended to enable congestion control for interactive real-time traffic using RTP. The feedback message is designed for use with a sender-based congestion control algorithm, in which the receiver of an RTP flow sends RTCP feedback packets to the sender containing the information the sender needs to perform congestion control.
    
draft-ietf-avtcore-multi-media-rtp-session-13.txt
 Sending Multiple Types of Media in a Single RTP Session
 
 draft-ietf-avtcore-multi-media-rtp-session-13.txt
 Date: 18/12/2015
 Authors: Magnus Westerlund, Colin Perkins, Jonathan Lennox
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: xml txt
This document specifies how an RTP session can contain RTP Streams with media from multiple media types such as audio, video, and text. This has been restricted by the RTP Specification, and thus this document updates RFC 3550 and RFC 3551 to enable this behaviour for applications that satisfy the applicability for using multiple media types in a single RTP session.
    
draft-ietf-avtcore-multiplex-guidelines-06.txt
 Guidelines for using the Multiplexing Features of RTP to Support Multiple Media Streams
 
 draft-ietf-avtcore-multiplex-guidelines-06.txt
 Date: 02/07/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-07.txt
 Frame Marking RTP Header Extension
 
 draft-ietf-avtext-framemarking-07.txt
 Date: 30/04/2018
 Authors: Mo Zanaty, Espen Berger, Suhas Nandakumar
 Working Group: Audio/Video Transport Core Maintenance (avtcore)
 Formats: txt xml
This document describes a Frame Marking RTP header extension used to convey information about video frames that is critical for error recovery and packet forwarding in RTP middleboxes or network nodes. It is most useful when media is encrypted, and essential when the middlebox or node has no access to the media decryption keys. It is also useful for codec-agnostic processing of encrypted or unencrypted media, while it also supports extensions for codec-specific information.
    
draft-ietf-avtext-lrr-07.txt
 The Layer Refresh Request (LRR) RTCP Feedback Message
 
 draft-ietf-avtext-lrr-07.txt
 Date: 02/07/2017
 Authors: Jonathan Lennox, Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman
 Working Group: Audio/Video Transport Extensions (avtext)
 Formats: xml txt
This memo describes the RTCP Payload-Specific Feedback Message "Layer Refresh Request" (LRR), which can be used to request a state refresh of one or more substreams of a layered media stream. It also defines its use with several RTP payloads for scalable media formats.
    
draft-ietf-avtext-rid-09.txt
 RTP Stream Identifier Source Description (SDES)
 
 draft-ietf-avtext-rid-09.txt
 Date: 06/10/2016
 Authors: Adam Roach, Suhas Nandakumar, Peter Thatcher
 Working Group: Audio/Video Transport Extensions (avtext)
 Formats: txt
This document defines and registers two new RTCP Stream Identifier Source Description (SDES) items. One, named RtpStreamId, is used for unique identification of RTP streams. The other, RepairedRtpStreamId, can be used to identify which stream a redundancy RTP stream is to be used to repair.
    
draft-ietf-babel-applicability-03.txt
 Applicability of the Babel routing protocol
 
 draft-ietf-babel-applicability-03.txt
 Date: 07/04/2018
 Authors: Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
Where we argue that, although OSPF and IS-IS are fine protocols, there exists a space where the Babel routing protocol (RFC 6126bis) is useful.
    
draft-ietf-babel-dtls-00.txt
 Babel Routing Protocol over Datagram Transport Layer Security
 
 draft-ietf-babel-dtls-00.txt
 Date: 15/08/2018
 Authors: Antonin Decimo, David Schinazi, Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
This documents describes how to use Datagram Transport Layer Security (DTLS) to secure the Babel Routing Protocol.
    
draft-ietf-babel-hmac-00.txt
 Babel Cryptographic Authentification
 
 draft-ietf-babel-hmac-00.txt
 Date: 16/08/2018
 Authors: Clara Do, Weronika Kolodziejak, Juliusz Chroboczek
 Working Group: Babel routing protocol (babel)
 Formats: txt xml
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-03.txt
 Babel Information Model
 
 draft-ietf-babel-information-model-03.txt
 Date: 05/06/2018
 Authors: Barbara Stark
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
This Babel Information Model can be used to create data models under various data modeling regimes (e.g., YANG). It allows a Babel implementation (via a management protocol such as netconf) to report on its current state and may allow some limited configuration of protocol constants.
    
draft-ietf-babel-rfc6126bis-05.txt
 The Babel Routing Protocol
 
 draft-ietf-babel-rfc6126bis-05.txt
 Date: 29/05/2018
 Authors: Juliusz Chroboczek, David Schinazi
 Working Group: Babel routing protocol (babel)
 Formats: xml txt
Babel is a loop-avoiding distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol, and obsoletes RFCs 6126 and 7557
    
draft-ietf-behave-syslog-nat-logging-06.txt
 Syslog Format for NAT Logging
 
 draft-ietf-behave-syslog-nat-logging-06.txt
 Date: 24/01/2014
 Authors: Zhonghua Chen, Cathy Zhou, Tina Tsou, Tom Taylor
 Working Group: Individual Submissions (none)
 Formats: txt xml
NAT devices are required to log events like creation and deletion of translations and information about the resources the NAT is managing. The logs are required to identify an attacker or a host that was used to launch malicious attacks, and for various other purposes of accounting and management. Since there is no standard way of logging this information, different NAT devices behave differently. The lack of a consistent way makes it difficult to write the collector applications that would receive this data and process it to present useful information. This document describes the information that is required to be logged by the NAT devices. It goes on to standardize formats for reporting these events and parameters using SYSLOG (RFC 5424). A companion document specifies formats for reporting the same events and parameters using IPFIX (RFC 7011). Applicability statements are provided in this document and its companion to guide operators and implementors in their choice of which technology to use for logging.
    
draft-ietf-bess-bgp-vpls-control-flags-06.txt
 Updated processing of control flags for BGP VPLS
 
 draft-ietf-bess-bgp-vpls-control-flags-06.txt
 Date: 17/08/2018
 Authors: Ravi Singh, Kireeti Kompella, Senad Palislamovic
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document updates the meaning of the "control flags" fields inside the "layer2 info extended community" used for BGP-VPLS NLRI as defined in RFC4761. If approved, this document updates RFC4761.
    
draft-ietf-bess-datacenter-gateway-01.txt
 Gateway Auto-Discovery and Route Advertisement for Segment Routing Enabled Domain Interconnection
 
 draft-ietf-bess-datacenter-gateway-01.txt
 Date: 02/05/2018
 Authors: John Drake, Adrian Farrel, Eric Rosen, Keyur Patel, Luay Jalil
 Working Group: BGP Enabled ServiceS (bess)
 Formats: xml txt
Data centers have become critical components of the infrastructure used by network operators to provide services to their customers. Data centers are attached to the Internet or a backbone network by gateway routers. One data center typically has more than one gateway for commercial, load balancing, and resiliency reasons. Segment routing is a popular protocol mechanism for operating within a data center, but also for steering traffic that flows between two data center sites. In order that one data center site may load balance the traffic it sends to another data center site it needs to know the complete set of gateway routers at the remote data center, the points of connection from those gateways to the backbone network, and the connectivity across the backbone network. Segment routing may also be operated in other domains, such as access networks. Those domains also need to be connected across backbone networks through gateways. This document defines a mechanism using the BGP Tunnel Encapsulation attribute to allow each gateway router to advertise the routes to the prefixes in the segment routing domains to which it provides access, and also to advertise on behalf of each other gateway to the same segment routing domain.
    
draft-ietf-bess-dci-evpn-overlay-10.txt
 Interconnect Solution for EVPN Overlay networks
 
 draft-ietf-bess-dci-evpn-overlay-10.txt
 Date: 02/03/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Wim Henderickx, Ali Sajassi, John Drake
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes how Network Virtualization Overlays (NVO) can be connected to a Wide Area Network (WAN) in order to extend the layer-2 connectivity required for some tenants. The solution analyzes the interaction between NVO networks running Ethernet Virtual Private Networks (EVPN) and other L2VPN technologies used in the WAN, such as Virtual Private LAN Services (VPLS), VPLS extensions for Provider Backbone Bridging (PBB-VPLS), EVPN or PBB-EVPN. It also describes how the existing technical specifications apply to the Interconnection and extends the EVPN procedures needed in some cases. In particular, this document describes how EVPN routes are processed on Gateways (GWs) that interconnect EVPN-Overlay and EVPN-MPLS networks, as well as the Interconnect Ethernet Segment (I-ES) to provide multi-homing, and the use of the Unknown MAC route to avoid MAC scale issues on Data Center Network Virtualization Edge (NVE) devices.
    
draft-ietf-bess-evpn-bum-procedure-updates-04.txt
 Updates on EVPN BUM Procedures
 
 draft-ietf-bess-evpn-bum-procedure-updates-04.txt
 Date: 27/06/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-03.txt
 Framework for EVPN Designated Forwarder Election Extensibility
 
 draft-ietf-bess-evpn-df-election-framework-03.txt
 Date: 24/05/2018
 Authors: Jorge Rabadan, satyamoh@cisco.com, Ali Sajassi, John Drake, Kiran Nagaraj, Senthil Sathappan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The Designated Forwarder (DF) in EVPN networks is the PE responsible for sending broadcast, unknown unicast and multicast (BUM) traffic to a multi-homed CE, on a given VLAN on a particular Ethernet Segment (ES). The DF is selected out of a list of candidate PEs that advertise the same Ethernet Segment Identifier (ESI) to the EVPN network. By default, EVPN uses a DF Election algorithm referred to as "Service Carving" and it is based on a modulus function (V mod N) that takes the number of PEs in the ES (N) and the VLAN value (V) as input. This default DF Election algorithm has some inefficiencies that this document addresses by defining a new DF Election algorithm and a capability to influence the DF Election result for a VLAN, depending on the state of the associated Attachment Circuit (AC). In addition, this document creates a registry with IANA, for future DF Election Algorithms and Capabilities. It also presents a formal definition and clarification of the DF Election Finite State Machine.
    
draft-ietf-bess-evpn-fast-df-recovery-00.txt
 Fast Recovery for EVPN DF Election
 
 draft-ietf-bess-evpn-fast-df-recovery-00.txt
 Date: 12/06/2018
 Authors: Ali Sajassi, Gaurav Badoni, Dhananjaya Rao, Patrice Brissette, John Drake, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Ethernet Virtual Private Network (EVPN) solution [RFC 7432] describes DF election procedures for multi-homing Ethernet Segments. These procedures are enhanced further in [DF-FRAMEWORK] by applying Highest Random Weight Algorithm for DF election in order to avoid DF status unnecessarily upon a failure. This draft makes further improvement to DF election procedures in [DF-FRAMEWORK] by providing two options for fast DF election upon recovery of the failed link or node associated with the multi-homing Ethernet Segment. This fast DF election is achieved independent of number of EVIs associated with that Ethernet Segment and it is performed via a simple signaling between the recovered PE and each PE in the multi-homing group.
    
draft-ietf-bess-evpn-igmp-mld-proxy-02.txt
 IGMP and MLD Proxy for EVPN
 
 draft-ietf-bess-evpn-igmp-mld-proxy-02.txt
 Date: 25/06/2018
 Authors: Ali Sajassi, Samir Thoria, Keyur Patel, Derek Yeung, John Drake, Wen Lin
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Ethernet Virtual Private Network (EVPN) solution [RFC 7432] is becoming pervasive in data center (DC) applications for Network Virtualization Overlay (NVO) and DC interconnect (DCI) services, and in service provider (SP) applications for next generation virtual private LAN services. This draft describes how to support efficiently endpoints running IGMP for the above services over an EVPN network by incorporating IGMP proxy procedures on EVPN PEs.
    
draft-ietf-bess-evpn-inter-subnet-forwarding-05.txt
 Integrated Routing and Bridging in EVPN
 
 draft-ietf-bess-evpn-inter-subnet-forwarding-05.txt
 Date: 18/07/2018
 Authors: Ali Sajassi, Samer Salam, Samir Thoria, John Drake, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
EVPN provides an extensible and flexible multi-homing VPN solution over an MPLS/IP network for intra-subnet connectivity among Tenant Systems and End Devices that can be physical or virtual. However, there are scenarios for which there is a need for a dynamic and efficient inter-subnet connectivity among these Tenant Systems and End Devices while maintaining the multi-homing capabilities of EVPN. This document describes an Integrated Routing and Bridging (IRB) solution based on EVPN to address such requirements.
    
draft-ietf-bess-evpn-irb-mcast-01.txt
 EVPN Optimized Inter-Subnet Multicast (OISM) Forwarding
 
 draft-ietf-bess-evpn-irb-mcast-01.txt
 Date: 16/07/2018
 Authors: Wen Lin, Zhaohui Zhang, John Drake, Eric Rosen, Jorge Rabadan, Ali Sajassi
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Ethernet VPN (EVPN) provides a service that allows a single Local Area Network (LAN), comprising a single IP subnet, to be divided into multiple "segments". Each segment may be located at a different site, and the segments are interconnected by an IP or MPLS backbone. Intra-subnet traffic (either unicast or multicast) always appears to the endusers to be bridged, even when it is actually carried over the IP or MPLS backbone. When a single "tenant" owns multiple such LANs, EVPN also allows IP unicast traffic to be routed between those LANs. This document specifies new procedures that allow inter-subnet IP multicast traffic to be routed among the LANs of a given tenant, while still making intra-subnet IP multicast traffic appear to be bridged. These procedures can provide optimal routing of the inter- subnet multicast traffic, and do not require any such traffic to leave a given router and then reenter that same router. These procedures also accommodate IP multicast traffic that needs to travel to or from systems that are outside the EVPN domain.
    
draft-ietf-bess-evpn-na-flags-01.txt
 Propagation of IPv6 Neighbor Advertisement Flags in EVPN
 
 draft-ietf-bess-evpn-na-flags-01.txt
 Date: 09/04/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages and reduce/suppress the flooding produced by the Address Resolution procedure. However, if the Neighbor information is learnt via EVPN, the PE would not know if a particular IPv6->MAC pair belongs to a host, a router or a host with an anycast address as this information is not carried in the MAC/IP route advertisements. This document proposes an OPTIONAL advertisement of the Flags defined in [RFC4861] along with the EVPN MAC/IP Advertisement routes, so that an EVPN PE implementing a proxy-ND function can reply to Neighbor Solicitations with the correct Flag information in Neighbor Advertisements.
    
draft-ietf-bess-evpn-per-mcast-flow-df-election-00.txt
 Per multicast flow Designated Forwarder Election for EVPN
 
 draft-ietf-bess-evpn-per-mcast-flow-df-election-00.txt
 Date: 04/09/2018
 Authors: Ali Sajassi, mankamana mishra, Samir Thoria, Jorge Rabadan, John Drake
 Working Group: BGP Enabled ServiceS (bess)
 Formats: pdf txt
[RFC7432] describes mechanism to elect designated forwarder (DF) at the granularity of (ESI, EVI) which is per VLAN (or per group of VLANs in case of VLAN bundle or VLAN-aware bundle service). However, the current level of granularity of per-VLAN is not adequate for some applications.[I-D.ietf-bess-evpn-df-election-framework] improves base line DF election by introducing HRW DF election. [I-D.ietf-bess-evpn-igmp-mld-proxy] introduces applicability of EVPN to Multicast flows, routes to sync them and a default DF election. This document is an extension to HRW base draft [I-D.ietf-bess-evpn-df-election-framework] and further enhances HRW algorithm for the Multicast flows to do DF election at the granularity of (ESI, VLAN, Mcast flow).
    
draft-ietf-bess-evpn-pref-df-01.txt
 Preference-based EVPN DF Election
 
 draft-ietf-bess-evpn-pref-df-01.txt
 Date: 09/04/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Tony Przygienda, Wen Lin, John Drake, Ali Sajassi, satyamoh@cisco.com
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
RFC7432 defines the Designated Forwarder (DF) in (PBB-)EVPN networks as the PE responsible for sending broadcast, multicast and unknown unicast traffic (BUM) to a multi-homed device/network in the case of an all-active multi-homing ES, or BUM and unicast in the case of single-active multi-homing. The DF is selected out of a candidate list of PEs that advertise the Ethernet Segment Identifier (ESI) to the EVPN network, according to the 'service-carving' algorithm. While 'service-carving' provides an efficient and automated way of selecting the DF across different EVIs or ISIDs in the ES, there are some use-cases where a more 'deterministic' and user-controlled method is required. At the same time, Service Providers require an easy way to force an on-demand DF switchover in order to carry out some maintenance tasks on the existing DF or control whether a new active PE can preempt the existing DF PE. This document proposes an extension to the current RFC7432 DF election procedures so that the above requirements can be met.
    
draft-ietf-bess-evpn-prefix-advertisement-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-04.txt
 Operational Aspects of Proxy-ARP/ND in EVPN Networks
 
 draft-ietf-bess-evpn-proxy-arp-nd-04.txt
 Date: 09/04/2018
 Authors: Jorge Rabadan, Senthil Sathappan, Kiran Nagaraj, Wim Henderickx, Greg Hankins, Thomas King, Daniel Melzer, Erik Nordmark
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The MAC/IP Advertisement route specified in [RFC7432] can optionally carry IPv4 and IPv6 addresses associated with a MAC address. Remote PEs can use this information to reply locally (act as proxy) to IPv4 ARP requests and IPv6 Neighbor Solicitation messages (or 'unicast- forward' them to the owner of the MAC) and reduce/suppress the flooding produced by the Address Resolution procedure. This EVPN capability is extremely useful in Internet Exchange Points (IXPs) and Data Centers (DCs) with large broadcast domains, where the amount of ARP/ND flooded traffic causes issues on routers and CEs, as explained in [RFC6820]. This document describes how the [RFC7432] EVPN proxy- ARP/ND function may be implemented to help IXPs and other operators deal with the issues derived from Address Resolution in large broadcast domains.
    
draft-ietf-bess-evpn-unequal-lb-00.txt
 Weighted Multi-Path Procedures for EVPN All-Active Multi-Homing
 
 draft-ietf-bess-evpn-unequal-lb-00.txt
 Date: 19/09/2018
 Authors: Neeraj Malhotra, Ali Sajassi, Jorge Rabadan, John Drake, Avinash Lingala, Samir Thoria
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
In an EVPN-IRB based network overlay, EVPN LAG enables all-active multi-homing for a host or CE device connected to two or more PEs via a LAG bundle, such that bridged and routed traffic from remote PEs can be equally load balanced (ECMPed) across the multi-homing PEs. This document defines extensions to EVPN procedures to optimally handle unequal access bandwidth distribution across a set of multi- homing PEs in order to: o provide greater flexibility, with respect to adding or removing individual PE-CE links within the access LAG o handle PE-CE LAG member link failures that can result in unequal PE-CE access bandwidth across a set of multi-homing PEs
    
draft-ietf-bess-evpn-virtual-eth-segment-00.txt
 EVPN Virtual Ethernet Segment
 
 draft-ietf-bess-evpn-virtual-eth-segment-00.txt
 Date: 19/06/2018
 Authors: Ali Sajassi, Patrice Brissette, Rick Schell, John Drake, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
EVPN and PBB-EVPN introduce a family of solutions for multipoint Ethernet services over MPLS/IP network with many advanced capabilities among which their multi-homing capabilities. These solutions define two types of multi-homing for an Ethernet Segment (ES): 1) Single-Active and 2) All-Active, where an Ethernet Segment is defined as a set of links between the multi-homed device/network and the set of PE devices that they are connected to. Some Service Providers want to extend the concept of the physical links in an ES to Ethernet Virtual Circuits (EVCs) where many of such EVCs can be aggregated on a single physical External Network-to- Network Interface (ENNI). An ES that consists of a set of EVCs instead of physical links is referred to as a virtual ES (vES). This draft describes the requirements and the extensions needed to support vES in EVPN and PBB-EVPN.
    
draft-ietf-bess-evpn-vpls-seamless-integ-04.txt
 (PBB-)EVPN Seamless Integration with (PBB-)VPLS
 
 draft-ietf-bess-evpn-vpls-seamless-integ-04.txt
 Date: 25/04/2018
 Authors: Ali Sajassi, Samer Salam, Nick Regno, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This draft specifies procedures for backward compatibility of the (PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for seamless integration of the two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this draft enables service providers to introduce (PBB-)EVPN PEs in their brown- field deployments of (PBB-)VPLS networks.
    
draft-ietf-bess-evpn-vpws-fxc-00.txt
 EVPN VPWS Flexible Cross-Connect Service
 
 draft-ietf-bess-evpn-vpws-fxc-00.txt
 Date: 26/04/2018
 Authors: Ali Sajassi, Patrice Brissette, Jim Uttaro, John Drake, Wen Lin, Sami Boutros, Jorge Rabadan
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document describes a new EVPN VPWS service type specifically for multiplexing multiple attachment circuits across different Ethernet Segments and physical interfaces into a single EVPN VPWS service tunnel and still providing Single-Active and All-Active multi-homing. This new service is referred to as flexible cross-connect service. It also describes the rational for this new service type as well as a solution to deliver such service.
    
draft-ietf-bess-l2l3-vpn-mcast-mib-16.txt
 L2L3 VPN Multicast MIB
 
 draft-ietf-bess-l2l3-vpn-mcast-mib-16.txt
 Date: 07/09/2018
 Authors: Zhaohui Zhang, Hiroshi Tsunoda
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes two MIB modules which will be used by other MIB modules for monitoring and/or configuring Layer 2 and Layer 3 Virtual Private Networks that support multicast.
    
draft-ietf-bess-l3vpn-yang-03.txt
 Yang Data Model for BGP/MPLS L3 VPNs
 
 draft-ietf-bess-l3vpn-yang-03.txt
 Date: 17/04/2018
 Authors: Dhanendra Jain, Keyur Patel, Patrice Brissette, Zhenbin Li, Shunwan Zhuang, Xufeng Liu, Jeffrey Haas, Santosh Esale, Bin Wen
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This document defines a YANG data model that can be used to configure and manage BGP Layer 3 VPNs.
    
draft-ietf-bess-mvpn-expl-track-09.txt
 Explicit Tracking with Wild Card Routes in Multicast VPN
 
 draft-ietf-bess-mvpn-expl-track-09.txt
 Date: 19/04/2018
 Authors: Andrew Dolganow, Jayant Kotalwar, Eric Rosen, Zhaohui Zhang
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
The MVPN specifications provide procedures to allow a multicast ingress node to invoke "explicit tracking" for a multicast flow or set of flows, thus learning the egress nodes for that flow or set of flows. However, the specifications are not completely clear about how the explicit tracking procedures work in certain scenarios. This document provides the necessary clarifications. It also specifies a new, optimized explicit tracking procedure. This new procedure allows an ingress node, by sending a single message, to request explicit tracking of each of a set of flows, where the set of flows is specified using a wildcard mechanism. This document updates RFCs 6514, 6625, and 7524.
    
draft-ietf-bess-mvpn-fast-failover-03.txt
 Multicast VPN fast upstream failover
 
 draft-ietf-bess-mvpn-fast-failover-03.txt
 Date: 04/05/2018
 Authors: Thomas Morin, Robert Kebler, Gregory Mirsky
 Working Group: BGP Enabled ServiceS (bess)
 Formats: xml txt
This document defines multicast VPN extensions and procedures that allow fast failover for upstream failures, by allowing downstream PEs to take into account the status of Provider-Tunnels (P-tunnels) when selecting the upstream PE for a VPN multicast flow, and extending BGP MVPN routing so that a C-multicast route can be advertised toward a standby upstream PE.
    
draft-ietf-bess-mvpn-mib-12.txt
 BGP/MPLS Layer 3 VPN Multicast Management Information Base
 
 draft-ietf-bess-mvpn-mib-12.txt
 Date: 16/09/2018
 Authors: Hiroshi Tsunoda
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects to configure and/or monitor Multicast communication over IP Virtual Private Networks (VPNs) supported by MultiProtocol Label Switching/Border Gateway Protcol (MPLS/BGP) on a Provider Edge router.
    
draft-ietf-bess-mvpn-msdp-sa-interoperation-01.txt
 MVPN and MSDP SA Interoperation
 
 draft-ietf-bess-mvpn-msdp-sa-interoperation-01.txt
 Date: 25/04/2018
 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-nsh-bgp-control-plane-04.txt
 BGP Control Plane for NSH SFC
 
 draft-ietf-bess-nsh-bgp-control-plane-04.txt
 Date: 01/07/2018
 Authors: Adrian Farrel, John Drake, Eric Rosen, Jim Uttaro, Luay Jalil
 Working Group: BGP Enabled ServiceS (bess)
 Formats: xml txt
This document describes the use of BGP as a control plane for networks that support Service Function Chaining (SFC). The document introduces a new BGP address family called the SFC AFI/SAFI with two route types. One route type is originated by a node to advertise that it hosts a particular instance of a specified service function. This route type also provides "instructions" on how to send a packet to the hosting node in a way that indicates that the service function has to be applied to the packet. The other route type is used by a Controller to advertise the paths of "chains" of service functions, and to give a unique designator to each such path so that they can be used in conjunction with the Network Service Header. This document adopts the SFC architecture described in RFC 7665.
    
draft-ietf-bess-service-chaining-05.txt
 Service Function Chaining using Virtual Networks with BGP VPNs
 
 draft-ietf-bess-service-chaining-05.txt
 Date: 16/08/2018
 Authors: Rex Fernando, Stuart Mackie, Dhananjaya Rao, Bruno Rijsman, Maria Napierala, Thomas Morin
 Working Group: BGP Enabled ServiceS (bess)
 Formats: xml txt
This document describes how service function chains (SFC) can be applied to traffic flows using routing in a virtual (overlay) network to steer traffic between service nodes. Chains can include services running in routers, on physical appliances or in virtual machines. Service chains have applicability at the subscriber edge, business edge and in multi-tenant datacenters. The routing function into SFCs and between service functions within an SFC can be performed by physical devices (routers), be virtualized inside hypervisors, or run as part of a host OS. A BGP control plane for route distribution is used to create virtual networks implemented using IP MPLS, VXLAN or other suitable encapsulation, where the routes within the virtual networks cause traffic to flow through a sequence of service nodes that apply packet processing functions to the flows. Two techniques are described: in one the service chain is implemented as a sequence of distinct VPNs between sets of service nodes that apply each service function; in the other, the routes within a VPN are modified through the use of special route targets and modified next-hop resolution to achieve the desired result. In both techniques, service chains can be created by manual configuration of routes and route targets in routing systems, or through the use of a controller which contains a topological model of the desired service chains. This document also contains discussion of load balancing between network functions, symmetric forward and reverse paths when stateful services are involved, and use of classifiers to direct traffic into a service chain.
    
draft-ietf-bess-vpls-multihoming-02.txt
 BGP based Multi-homing in Virtual Private LAN Service
 
 draft-ietf-bess-vpls-multihoming-02.txt
 Date: 14/09/2018
 Authors: Bhupesh Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, Jim Uttaro
 Working Group: BGP Enabled ServiceS (bess)
 Formats: txt
Virtual Private LAN Service (VPLS) is a Layer 2 Virtual Private Network (VPN) that gives its customers the appearance that their sites are connected via a Local Area Network (LAN). It is often required for the Service Provider (SP) to give the customer redundant connectivity to some sites, often called "multi-homing". This memo shows how BGP-based multi-homing can be offered in the context of LDP and BGP VPLS solutions.
    
draft-ietf-bfcpbis-bfcp-websocket-15.txt
 The WebSocket Protocol as a Transport for the Binary Floor Control Protocol (BFCP)
 
 draft-ietf-bfcpbis-bfcp-websocket-15.txt
 Date: 08/02/2017
 Authors: Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo Salgueiro, Ram R
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies the use of Binary Floor Control Protocol(BFCP) as a new WebSocket sub-protocol enabling a reliable transport mechanism between BFCP entities in new scenarios.
    
draft-ietf-bfcpbis-rfc4582bis-16.txt
 The Binary Floor Control Protocol (BFCP)
 
 draft-ietf-bfcpbis-rfc4582bis-16.txt
 Date: 13/11/2015
 Authors: Gonzalo Camarillo, Keith Drage, Tom Kristensen, Joerg Ott, Charles Eckel
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
Floor control is a means to manage joint or exclusive access to shared resources in a (multiparty) conferencing environment. Thereby, floor control complements other functions -- such as conference and media session setup, conference policy manipulation, and media control -- that are realized by other protocols. This document specifies the Binary Floor Control Protocol (BFCP). BFCP is used between floor participants and floor control servers, and between floor chairs (i.e., moderators) and floor control servers. This document obsoletes RFC 4582. Changes from RFC 4582 are summarized in Section 16.
    
draft-ietf-bfcpbis-rfc4583bis-24.txt
 Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams
 
 draft-ietf-bfcpbis-rfc4583bis-24.txt
 Date: 19/06/2018
 Authors: Gonzalo Camarillo, Tom Kristensen, Christer Holmberg
 Working Group: Binary Floor Control Protocol Bis (bfcpbis)
 Formats: txt xml
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 15.
    
draft-ietf-bfd-multipoint-18.txt
 BFD for Multipoint Networks
 
 draft-ietf-bfd-multipoint-18.txt
 Date: 18/06/2018
 Authors: Dave Katz, David Ward, Juniper Networks, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks.
    
draft-ietf-bfd-multipoint-active-tail-09.txt
 BFD Multipoint Active Tails.
 
 draft-ietf-bfd-multipoint-active-tail-09.txt
 Date: 18/06/2018
 Authors: Dave Katz, David Ward, Juniper Networks, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: xml txt
This document describes active tail extensions to and updates the Bidirectional Forwarding Detection (BFD) protocol for multipoint networks.
    
draft-ietf-bfd-optimizing-authentication-05.txt
 Optimizing BFD Authentication
 
 draft-ietf-bfd-optimizing-authentication-05.txt
 Date: 25/05/2018
 Authors: Mahesh Jethanandani, Ashesh Mishra, Ankur Saxena, Manav Bhatia
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: xml txt
This document describes an optimization to BFD Authentication as described in Section 6.7 of BFD RFC5880.
    
draft-ietf-bfd-secure-sequence-numbers-02.txt
 Secure BFD Sequence Numbers
 
 draft-ietf-bfd-secure-sequence-numbers-02.txt
 Date: 25/05/2018
 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-02.txt
 BFD Stability
 
 draft-ietf-bfd-stability-02.txt
 Date: 25/05/2018
 Authors: Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena, Juniper Networks, Mach Chen, Peng Fan
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: xml txt
This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol to measure BFD stability. Specifically, it describes a mechanism for detection of BFD frame loss.
    
draft-ietf-bfd-vxlan-02.txt
 BFD for VXLAN
 
 draft-ietf-bfd-vxlan-02.txt
 Date: 18/08/2018
 Authors: Juniper Networks, Sudarsan Paragiri, Vengada Govindan, Mallik Mudigonda, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: xml txt
This document describes the use of the Bidirectional Forwarding Detection (BFD) protocol in Virtual eXtensible Local Area Network (VXLAN) overlay networks.
    
draft-ietf-bfd-yang-17.txt
 YANG Data Model for Bidirectional Forwarding Detection (BFD)
 
 draft-ietf-bfd-yang-17.txt
 Date: 02/08/2018
 Authors: Reshad Rahman, Lianshu Zheng, Mahesh Jethanandani, Juniper Networks, Gregory Mirsky
 Working Group: Bidirectional Forwarding Detection (bfd)
 Formats: txt xml
This document defines a YANG data model that can be used to configure and manage Bidirectional Forwarding Detection (BFD). The YANG modules in this document conform to the Network Management Datastore Architecture (NMDA).
    
draft-ietf-bier-bar-ipa-01.txt
 BIER Underlay Path Calculation Algorithm and Contraints
 
 draft-ietf-bier-bar-ipa-01.txt
 Date: 10/04/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 and IPA fields defined in [I-D.ietf-bier-isis-extensions] and [I-D.ietf-bier-ospf-bier-extensions].
    
draft-ietf-bier-bgp-ls-bier-ext-03.txt
 BGP Link-State extensions for BIER
 
 draft-ietf-bier-bgp-ls-bier-ext-03.txt
 Date: 31/08/2018
 Authors: Ran Chen, Zheng Zhang, Vengada Govindan, IJsbrand Wijnands
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bitstring in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document specifies extensions to the BGP Link-state address- family in order to advertising BIER information.
    
draft-ietf-bier-evpn-01.txt
 EVPN BUM Using BIER
 
 draft-ietf-bier-evpn-01.txt
 Date: 27/04/2018
 Authors: Zhaohui Zhang, Tony Przygienda, Ali Sajassi, Jorge Rabadan
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
This document specifies protocols and procedures for forwarding broadcast, unknown unicast and multicast (BUM) traffic of Ethernet VPNs (EVPN) using Bit Index Explicit Replication (BIER).
    
draft-ietf-bier-mld-01.txt
 BIER Ingress Multicast Flow Overlay using Multicast Listener Discovery Protocols
 
 draft-ietf-bier-mld-01.txt
 Date: 29/06/2018
 Authors: Pierre Pfister, IJsbrand Wijnands, Stig Venaas, Cui(Linda) Wang, Zheng Zhang, Markus Stenberg
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
This document specifies the ingress part of a multicast flow overlay for BIER networks. Using existing multicast listener discovery protocols, it enables multicast membership information sharing from egress routers, acting as listeners, toward ingress routers, acting as queriers. Ingress routers keep per-egress-router state, used to construct the BIER bit mask associated with IP multicast packets entering the BIER domain.
    
draft-ietf-bier-mvpn-11.txt
 Multicast VPN Using BIER
 
 draft-ietf-bier-mvpn-11.txt
 Date: 19/03/2018
 Authors: Eric Rosen, Mahesh Sivakumar, Sam Aldrin, Andrew Dolganow, Tony Przygienda
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
The Multicast Virtual Private Network (MVPN) specifications require the use of multicast tunnels ("P-tunnels") that traverse a Service Provider's backbone network. The P-tunnels are used for carrying multicast traffic across the backbone. A variety of P-tunnel types are supported. Bit Index Explicit Replication (BIER) is a new architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. This document specifies the protocol and procedures that allow MVPN to use BIER as the method of carrying multicast traffic over an SP backbone network.
    
draft-ietf-bier-non-mpls-bift-encoding-00.txt
 An Optional Encoding of the BIFT-id Field in the non-MPLS BIER Encapsulation
 
 draft-ietf-bier-non-mpls-bift-encoding-00.txt
 Date: 16/04/2018
 Authors: IJsbrand Wijnands, Xiaohu Xu, Hooman Bidgoli
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "multicast domain", without requiring intermediate routers to maintain any per-flow state or to engage in an explicit tree-building protocol. The Multicast packet is encapsulated using a BIER Header and transported through an MPLS or non-MPLS network. When MPLS is used as the transport, the Bit Indexed Forwarding Table (BIFT) is identified by a MPLS Label. When non-MPLS transport is used, the BIFT is identified by a 20bit value. This document describes one way of encoding the 20bit value.
    
draft-ietf-bier-oam-requirements-06.txt
 Operations,Administration and Maintenance (OAM) Requirements for Bit Index Explicit Replication (BIER) Layer
 
 draft-ietf-bier-oam-requirements-06.txt
 Date: 28/08/2018
 Authors: Gregory Mirsky, Erik Nordmark, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Lianshu Zheng, Mach Chen, Nobo Akiya, Santosh Pallagatti
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt xml
This document describes a list of functional requirement toward Operations, Administration and Maintenance (OAM) toolset in Bit Index Explicit Replication (BIER) layer of a network.
    
draft-ietf-bier-ospf-bier-extensions-18.txt
 OSPFv2 Extensions for BIER
 
 draft-ietf-bier-ospf-bier-extensions-18.txt
 Date: 01/06/2018
 Authors: Peter Psenak, Nagendra Kumar, IJsbrand Wijnands, Andrew Dolganow, Tony Przygienda, Zhaohui Zhang, Sam Aldrin
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits set in BIER packet header. This document describes the OSPF [RFC2328] protocol extension required for BIER with MPLS encapsulation [RFC8296]. Support for other encapsulation types is outside thescope of this document. The use of multiple encapsulation types is outside the scope of this document.
    
draft-ietf-bier-path-mtu-discovery-04.txt
 Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit Replication (BIER) Layer
 
 draft-ietf-bier-path-mtu-discovery-04.txt
 Date: 19/06/2018
 Authors: Gregory Mirsky, Tony Przygienda, Andrew Dolganow
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt xml
This document describes Path Maximum Transmission Unit Discovery (PMTUD) in Bit Indexed Explicit Replication (BIER) layer.
    
draft-ietf-bier-pim-signaling-03.txt
 PIM Signaling Through BIER Core
 
 draft-ietf-bier-pim-signaling-03.txt
 Date: 21/06/2018
 Authors: Hooman Bidgoli, Andrew Dolganow, Jayant Kotalwar, Fengman Xu, mankamana mishra, Zhaohui Zhang
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt
Bit Index Explicit Replication (BIER) is an architecture that provides multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain multicast related per-flow state. Neither does BIER require an explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. Such header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by the according set of bits switched on in BIER packet header. This document describes the procedure needed for PIM Joins and Prunes to be signaled through a BIER core. Allowing PIM routers to run traditional PIM multicast services through a BIER core.
    
draft-ietf-bier-pmmm-oam-04.txt
 Performance Measurement (PM) with Marking Method in Bit Index Explicit Replication (BIER) Layer
 
 draft-ietf-bier-pmmm-oam-04.txt
 Date: 19/06/2018
 Authors: Gregory Mirsky, Lianshu Zheng, Mach Chen, Giuseppe Fioccola
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: xml txt
This document describes a hybrid performance measurement method for multicast service over Bit Index Explicit Replication (BIER) domain.
    
draft-ietf-bier-use-cases-07.txt
 BIER Use Cases
 
 draft-ietf-bier-use-cases-07.txt
 Date: 28/07/2018
 Authors: Nagendra Kumar, Rajiv Asati, Mach Chen, Xiaohu Xu, Andrew Dolganow, Tony Przygienda, Arkadiy Gulko, Dom Robinson, Vishal Arya, Caitlin Bestler
 Working Group: Bit Indexed Explicit Replication (bier)
 Formats: txt xml
Bit Index Explicit Replication (BIER) is an architecture that provides optimal multicast forwarding through a "BIER domain" without requiring intermediate routers to maintain any multicast related per- flow state. BIER also does not require any explicit tree-building protocol for its operation. A multicast data packet enters a BIER domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router adds a BIER header to the packet. The BIER header contains a bit-string in which each bit represents exactly one BFER to forward the packet to. The set of BFERs to which the multicast packet needs to be forwarded is expressed by setting the bits that correspond to those routers in the BIER header. This document describes some of the use-cases for BIER.
    
draft-ietf-bmwg-evpntest-00.txt
 Benchmarking Methodology for EVPN and PBB-EVPN
 
 draft-ietf-bmwg-evpntest-00.txt
 Date: 17/09/2018
 Authors: sudhin jacob, Kishore Tiruveedhula
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
This document defines methodologies for benchmarking EVPN and PBB- EVPN performance. EVPN is defined in RFC 7432, and is being deployed in Service Provider networks. Specifically this document defines the methodologies for benchmarking EVPN/PBB-EVPN convergence, data plane performance, and control plane performance.
    
draft-ietf-bmwg-sdn-controller-benchmark-meth-09.txt
 Benchmarking Methodology for SDN Controller Performance
 
 draft-ietf-bmwg-sdn-controller-benchmark-meth-09.txt
 Date: 25/05/2018
 Authors: Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
This document defines methodologies for benchmarking control plane performance of SDN controllers. SDN controller is a core component in software-defined networking architecture that controls the network behavior. SDN controllers have been implemented with many varying designs in order to achieve their intended network functionality. Hence, the authors have taken the approach of considering an SDN controller as a black box, defining the methodology in a manner that is agnostic to protocols and network services supported by controllers. The intent of this document is to provide a method to measure the performance of all controller implementations.
    
draft-ietf-bmwg-sdn-controller-benchmark-term-10.txt
 Terminology for Benchmarking SDN Controller Performance
 
 draft-ietf-bmwg-sdn-controller-benchmark-term-10.txt
 Date: 25/05/2018
 Authors: Bhuvaneswaran Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks
 Working Group: Benchmarking Methodology (bmwg)
 Formats: txt
This document defines terminology for benchmarking an SDN controller's control plane performance. It extends the terminology already defined in RFC 7426 for the purpose of benchmarking SDN controllers. The terms provided in this document help to benchmark SDN controller's performance independent of the controller's supported protocols and/or network services.
    
draft-ietf-calext-caldav-attachments-03.txt
 CalDAV Managed Attachments
 
 draft-ietf-calext-caldav-attachments-03.txt
 Date: 24/07/2017
 Authors: Cyrus Daboo, Arnaud Quillaud, Ken Murchison
 Working Group: Calendaring Extensions (calext)
 Formats: txt xml
This specification defines an extension to the calendar access protocol (CalDAV) to allow attachments associated with iCalendar data to be stored and managed on the server. This specification documents existing code deployed by multiple vendors. It is published as an Informational specification rather than Standards-Track due to its non-standard method of updating an existing resource via HTTP.
    
draft-ietf-calext-eventpub-extensions-09.txt
 Event Publishing Extensions to iCalendar
 
 draft-ietf-calext-eventpub-extensions-09.txt
 Date: 30/08/2018
 Authors: Michael Douglass
 Working Group: Calendaring Extensions (calext)
 Formats: xml pdf txt
This specification updates [RFC5545] by introducing a number of new iCalendar properties and components which are of particular use for event publishers and in social networking. This specification also defines a new STRUCTURED-DATA property for iCalendar [RFC5545] to allow for data that is directly pertinent to an event or task to be included with the calendar data.
    
draft-ietf-calext-ical-relations-04.txt
 Support for iCalendar Relationships
 
 draft-ietf-calext-ical-relations-04.txt
 Date: 05/05/2018
 Authors: Michael Douglass
 Working Group: Calendaring Extensions (calext)
 Formats: pdf xml txt
This specification updates RELATED-TO defined in [RFC5545] and introduces new iCalendar properties LINK, CONCEPT and REFID to allow better linking and grouping of iCalendar components and related data.
    
draft-ietf-calext-jscalendar-07.txt
 JSCalendar: A JSON representation of calendar data
 
 draft-ietf-calext-jscalendar-07.txt
 Date: 20/09/2018
 Authors: Neil Jenkins, Robert Stepanek
 Working Group: Calendaring Extensions (calext)
 Formats: xml txt
This specification defines a data model and JSON representation of calendar data that can be used for storage and data exchange in a calendaring and scheduling environment. It aims to be an alternative to the widely deployed iCalendar data format and to be unambiguous, extendable and simple to process.
    
draft-ietf-capport-api-01.txt
 Captive Portal API
 
 draft-ietf-capport-api-01.txt
 Date: 01/07/2018
 Authors: Tommy Pauly, Darshak Thakore
 Working Group: Captive Portal Interaction (capport)
 Formats: xml txt
This document describes an HTTP API that allows hosts to interact with a Captive Portal system.
    
draft-ietf-capport-architecture-02.txt
 CAPPORT Architecture
 
 draft-ietf-capport-architecture-02.txt
 Date: 30/06/2018
 Authors: Kyle Larose, David Dolson
 Working Group: Captive Portal Interaction (capport)
 Formats: xml txt
This document aims to document consensus on the CAPPORT architecture. DHCP or Router Advertisements, an optional signaling protocol, and an HTTP API are used to provide the solution. The role of Provisioning Domains (PvDs) is described.
    
draft-ietf-cbor-7049bis-03.txt
 Concise Binary Object Representation (CBOR)
 
 draft-ietf-cbor-7049bis-03.txt
 Date: 20/09/2018
 Authors: Carsten Bormann, Paul Hoffman
 Working Group: Concise Binary Object Representation Maintenance and Extensions (cbor)
 Formats: txt
The Concise Binary Object Representation (CBOR) 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. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack.
    
draft-ietf-cbor-cddl-05.txt
 Concise data definition language (CDDL): a notational convention to express CBOR and JSON data structures
 
 draft-ietf-cbor-cddl-05.txt
 Date: 23/08/2018
 Authors: Henk Birkholz, Christoph Vigano, Carsten Bormann
 Working Group: Concise Binary Object Representation Maintenance and Extensions (cbor)
 Formats: txt
This document proposes a notational convention to express CBOR data structures (RFC 7049). Its main goal is to provide an easy and unambiguous way to express structures for protocol messages and data formats that use CBOR or JSON.
    
draft-ietf-ccamp-alarm-module-03.txt
 YANG Alarm Module
 
 draft-ietf-ccamp-alarm-module-03.txt
 Date: 20/09/2018
 Authors: Stefan Vallin, Martin Bjorklund
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
This document defines a YANG module for alarm management. It includes functions for alarm list management, alarm shelving and notifications to inform management systems. There are also RPCs to manage the operator state of an alarm and administrative alarm procedures. The module carefully maps to relevant alarm standards.
    
draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11.txt
 A framework for Management and Control of DWDM optical interface parameters
 
 draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-11.txt
 Date: 11/06/2018
 Authors: Ruediger Kunze, Gert Grammel, Dieter Beller, Gabriele Galimberti, Julien Meuric
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
The control and management of DWDM interfaces are a precondition for enhanced multilayer networking. They are needed to ensure an efficient data transport, to meet the requirements requested by today's IP-services and to provide a further automation of network provisioning and operations. This document describes use cases, requirements and solutions for the control and management of optical interface parameters according to different types of single channel DWDM interfaces. The focus is on automating the network provisioning process irrespective on how it is triggered i.e. by Element Manager System (EMS), Network Management System (NMS) or Generalized Multi Protocol Label Switching (GMPLS). This document covers management and control considerations in different scenarios of single channel DWDM interfaces. The purpose is to identify the necessary information and processes to be used by control or management systems to properly and efficiently drive the network.
    
draft-ietf-ccamp-flexigrid-media-channel-yang-00.txt
 YANG data model for Flexi-Grid media-channels
 
 draft-ietf-ccamp-flexigrid-media-channel-yang-00.txt
 Date: 24/05/2018
 Authors: Universidad de Madrid, Daniel Perdices, Victor Lopezalvarez, Oscar de Dios, Daniel King, Young Lee, Gabriele Galimberti
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
This document defines a YANG model for managing flexi-grid optical media channels, complementing the information provided by the flexi-grid TED model. It is also grounded on other defined YANG abstract models.
    
draft-ietf-ccamp-flexigrid-yang-01.txt
 YANG data model for Flexi-Grid Optical Networks
 
 draft-ietf-ccamp-flexigrid-yang-01.txt
 Date: 10/08/2018
 Authors: Universidad de Madrid, Daniel Perdices, Victor Lopezalvarez, Oscar de Dios, Daniel King, Young Lee, Gabriele Galimberti
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
This document defines a YANG model for managing flexi-grid optical Networks. The model described in this document defines a flexi-grid traffic engineering database. A complementary module is referenced to detail the flexi-grid media channels. This module is grounded on other defined YANG abstract models.
    
draft-ietf-ccamp-l1csm-yang-08.txt
 A YANG Data Model for L1 Connectivity Service Model (L1CSM)
 
 draft-ietf-ccamp-l1csm-yang-08.txt
 Date: 13/09/2018
 Authors: Giuseppe Fioccola, Kwang-koog Lee, Young Lee, Dhruv Dhody, Daniele Ceccarelli
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
This document provides a YANG data model for Layer 1 Connectivity Service Model (L1CSM). The intent of this document is to provide a transport service model exploiting YANG data model, which can be utilized by a client network controller to initiate a service request connectivity request as well as retrieving service states toward a transport network controller communicating with the client controller. This YANG model is NMDA-compliant.
    
draft-ietf-ccamp-microwave-framework-07.txt
 A framework for Management and Control of microwave and millimeter wave interface parameters
 
 draft-ietf-ccamp-microwave-framework-07.txt
 Date: 05/06/2018
 Authors: Jonas Ahlberg, Min Ye, Xi Li, Luis Contreras, Carlos Bernardos
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
The unification of control and management of microwave radio link interfaces is a precondition for seamless multilayer networking and automated network provisioning and operation. This document describes the required characteristics and use cases for control and management of radio link interface parameters using a YANG Data Model. The purpose is to create a framework for identification of the necessary information elements and definition of a YANG Data Model for control and management of the radio link interfaces in a microwave node. Some parts of the resulting model may be generic which could also be used by other technologies, e.g., Ethernet technology.
    
draft-ietf-ccamp-mw-yang-09.txt
 A YANG Data Model for Microwave Radio Link
 
 draft-ietf-ccamp-mw-yang-09.txt
 Date: 31/08/2018
 Authors: Jonas Ahlberg, Min Ye, Xi Li, Daniela Spreafico, Marko Vaupotic
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
This document defines a YANG data model for control and management of the radio link interfaces, and their connectivity to packet (typically Ethernet) interfaces in a microwave/millimeter wave node. The data nodes for management of the interface protection functionality is broken out into a separate and generic YANG data model in order to make it available also for other interface types. RFC Ed. Note // RFC Ed.: replace all XXXX throughout the document with actual RFC numbers and remove this note
    
draft-ietf-ccamp-otn-topo-yang-05.txt
 A YANG Data Model for Optical Transport Network Topology
 
 draft-ietf-ccamp-otn-topo-yang-05.txt
 Date: 23/08/2018
 Authors: zhenghaomian@huawei.com, Aihua Guo, Italo Busi, Anurag Sharma, Xufeng Liu, Sergio Belotti, Yunbin Xu, Lei Wang, Oscar de Dios
 Working Group: Common Control and Measurement Plane (ccamp)
 Formats: txt
A transport network is a server-layer network designed to provide connectivity services for a client-layer network to carry the client traffic transparently across the server-layer network resources. A transport network can be constructed from equipments utilizing any of a number of different transport technologies such as the evolving Optical Transport Networks (OTN) or packet transport as provided by the MPLS-Transport Profile (MPLS-TP). This document describes a YANG data model to describe the topologies of an Optical Transport Network (OTN). It is independent of control plane protocols and captures topological and resource related information pertaining to OTN. This model enables clients, which interact with a transport domain controller via a REST interface, for OTN topology related operations such as obtaining the relevant topology resource information.
    
draft-ietf-ccamp-otn-tunnel-model-05.txt
 OTN Tunnel YANG Model
 
 draft-ietf-ccamp-otn-tunnel-model-05.txt
 Date: 23/08/2018
 Authors: zhenghaomian@huawei.com, Aihua Guo, Italo Busi, Anurag Sharma, Rajan Rao, Sergio Belotti, Victor Lopezalvarez, Yunbo Li, Yunbin Xu
 Working Group: Common Control and Measureme