Current Internet-Drafts

This summary sheet provides a short synopsis of each Internet-Draft

available within the "internet-drafts" directory at the shadow
sites directory. These drafts are listed alphabetically by working
group acronym and start date. Generated 2016-05-07 14:06:55 UTC.
IPv6 over Networks of Resource-constrained Nodes (6lo)
-----------------------------------------------------"Transmission of IPv6 Packets over DECT Ultra Low Energy", Peter
Mariager, Jens Petersen, Zach Shelby, Marco van de Logt, Dominique
Barthel, 2016-02-26, <draft-ietf-6lo-dect-ule-04.txt,.pdf>
DECT Ultra Low Energy is a low power air interface technology that is
defined by the DECT Forum and specified by ETSI.
The DECT air interface technology has been used world-wide in
communication devices for more than 20 years, primarily carrying
voice for cordless telephony but has also been deployed for data
centric services.
The DECT Ultra Low Energy is a recent addition to the DECT interface
primarily intended for low-bandwidth, low-power applications such as
sensor devices, smart meters, home automation etc. As the DECT Ultra
Low Energy interface inherits many of the capabilities from DECT, it
benefits from long range, interference free operation, world wide
reserved frequency band, low silicon prices and maturity. There is
an added value in the ability to communicate with IPv6 over DECT ULE
such as for Internet of Things applications.
This document describes how IPv6 is transported over DECT ULE using
6LoWPAN techniques.
"Transmission of IPv6 over MS/TP Networks", Kerry Lynn, Jerry Martocci,
Carl Neilson, Stuart Donaldson, 2016-02-22,
<draft-ietf-6lo-6lobac-04.txt>
Master-Slave/Token-Passing (MS/TP) is a medium access control method
for the RS-485 physical layer, which is used extensively in building
automation networks. This specification defines the frame format for
transmission of IPv6 packets and the method of forming link-local and
statelessly autoconfigured IPv6 addresses on MS/TP networks.
"Transmission of IPv6 Packets over Near Field Communication", Yong-Geun
Hong, Joo-Sang Youn, 2016-03-21, <draft-ietf-6lo-nfc-03.txt>
Near field communication (NFC) is a set of standards for smartphones
and portable devices to establish radio communication with each other
by touching them together or bringing them into proximity, usually no
more than 10 cm. NFC standards cover communications protocols and
data exchange formats, and are based on existing radio-frequency
identification (RFID) standards including ISO/IEC 14443 and FeliCa.
The standards include ISO/IEC 18092 and those defined by the NFC
Forum. The NFC technology has been widely implemented and available
in mobile phones, laptop computers, and many other devices. This
document describes how IPv6 is transmitted over NFC using 6LowPAN
techniques.

"An Extension to Mesh Link Establishment (MLE) for Host Identity

Protocol Diet Exchange (HIP DEX)", Yoshihiro Ohba, 2016-04-19,
<draft-ietf-6lo-mle-hip-dex-01.txt>
HIP DEX (Host Identity Protocol Diet EXchange) is a light-weight key
exchange protocol designed for constrained devices. MLE (Mesh Link
Establishment) is defined for establishing and configuring secure
links in IEEE 802.15.4 mesh networks. This document defines an
extension of MLE protocol to encapsulate HIP DEX key exchange
protocol messages.
"Mesh Link Establishment", Richard Kelsey, 2015-12-01,
<draft-ietf-6lo-mesh-link-establishment-00.txt>
This document defines the mesh link establishment (MLE) protocol for
establishing and configuring secure radio links in IEEE 802.15.4
radio mesh networks. MLE extends IEEE 802.15.4 for use in multihop
mesh networks by adding three capabilities: 1) dynamically
configuring and securing radio connections between neighboring
devices, 2) enabling network-wide changes to shared radio parameters,
and 3) allowing the determination of radio link quality prior to
configuration. MLE operates below the routing layer, insulating it
from the details of configuring, securing, and maintaining individual
radio links within a larger mesh network.
"IPv6 Backbone Router", Pascal Thubert, 2016-03-18,
<draft-ietf-6lo-backbone-router-01.txt>
This specification proposes an update to IPv6 Neighbor Discovery, to
enhance the operation of IPv6 over wireless links that exhibit lossy
multicast support, and enable a large degree of scalability by
splitting the broadcast domains. A higher speed backbone federates
multiple wireless links to form a large MultiLink Subnet. Backbone
Routers acting as Layer-3 Access Point route packets to registered
nodes, where an classical Layer-2 Access Point would bridge.
Conversely, wireless nodes register to the Backbone Router to setup
routing services in a fashion that is essentially similar to a
classical Layer-2 association.
"6LoWPAN Paging Dispatch", Pascal Thubert, 2016-01-15,
<draft-ietf-6lo-paging-dispatch-01.txt>
This specification introduces a new context switch mechanism for
6LoWPAN compression, expressed in terms of Pages and signaled by a
new Paging Dispatch.
"IANA Registry for 6lowpan ESC Dispatch Code points", Samita
Chakrabarti, Gabriel Montenegro, Ralph Droms, james, 2016-04-07,
<draft-ietf-6lo-dispatch-iana-registry-03.txt>
RFC4944 defines ESC dispatch type for additional dispatch bytes in
the 6lowpan header. The value of ESC byte has been updated by
RFC6282. However, the usage of ESC extension byte has not been
defined in RFC6282 and RFC4944. The purpose of this document is to
define the ESC extension byte code points and to request
corresponding IANA actions.
"Assignment of an Ethertype for IPv6 with LoWPAN Encapsulation", Ralph
Droms, Paul Duffy, 2016-04-18, <draft-ietf-6lo-ethertype-request-00.txt>

When carried over layer 2 technologies such as Ethernet, IPv6

datagrams using LoWPAN encapsulation as defined in RFC 4944 must be
identified so the receiver can correctly interpret the encoded IPv6
datagram. This document requests the assignment of an Ethertype for
that purpose.
IPv6 Maintenance (6man)
----------------------"Recommendation on Stable IPv6 Interface Identifiers", Fernando Gont,
Alissa Cooper, Dave Thaler, Shucheng LIU, 2016-04-27,
<draft-ietf-6man-default-iids-11.txt>
This document changes the default scheme for generating stable
Interface Identifiers with SLAAC to that specified in RFC7217, and
recommends against embedding link-layer addresses in IPv6 Interface
Identifiers. It formally updates RFC2464, RFC2467, RFC2470, RFC2491,
RFC2492, RFC2497, RFC2590, RFC3146, RFC3572, RFC4291, RFC4338,
RFC4391, RFC5072, and RFC5121, by removing the text in these RFCs
that required the IPv6 Interface Identifiers to be derived from the
underlying link-layer address, and replacing the aforementioned text
with a pointer to this document. Additionally, this document updates
RFC3315 by specifying additional requirements on the generation of
Interface Identifiers used in Dynamic Host Configuration Protocol
version 6 (DHCPv6). It also provides advice to system administrators
who employ manual configuration. This document does not change any
existing recommendations concerning the use of temporary addresses as
specified in RFC 4941.
"Generation of IPv6 Atomic Fragments Considered Harmful", Fernando Gont,
Shucheng LIU, Tore Anderson, 2016-04-04,
<draft-ietf-6man-deprecate-atomfrag-generation-06.txt>
This document discusses the security implications of the generation
of IPv6 atomic fragments and a number of interoperability issues
associated with IPv6 atomic fragments, and concludes that the
aforementioned functionality is undesirable, thus documenting the
motivation for removing this functionality in the revision of the
core IPv6 protocol specification.
"IPv6 Neighbor Discovery Optional RS/RA Refresh", Erik Nordmark, Andrew
Yourtchenko, Suresh Krishnan, 2016-03-21,
<draft-ietf-6man-rs-refresh-01.txt>
IPv6 Neighbor Discovery relies on periodic multicast Router
Advertisement messages to update timer values and to distribute new
information (such as new prefixes) to hosts. On some links the use
of periodic multicast messages to all host becomes expensive, and in
some cases it results in hosts waking up frequently. Many
implementations of RFC 4861 also use multicast for solicited Router
Advertisement messages, even though that behavior is optional.
This specification provides an optional mechanism for hosts and
routers where instead of periodic multicast Router Advertisements the
hosts are instructed (by the routers) to use Router Solicitations to
request refreshed Router Advertisements. This mechanism is enabled
by configuring the router to include a new option in the Router
Advertisement in order to allow the network administrator to choose
host behavior based on whether periodic multicast are more efficient
on their link or not. The routers can also tell whether the hosts

are capable of the new behavior through a new flag in the Router
Solicitations.
"IPv6 Router Advertisement Options for DNS Configuration", Jaehoon
Jeong, Soohong Park, Luc Beloeil, Syam Madanapalli, 2016-04-07,
<draft-ietf-6man-rdnss-rfc6106bis-12.txt>
This document specifies IPv6 Router Advertisement options to allow
IPv6 routers to advertise a list of DNS recursive server addresses
and a DNS Search List to IPv6 hosts.
This document obsoletes RFC 6106 and allows a higher default value of
the lifetime of the RA DNS options to avoid the frequent expiry of
the options on links with a relatively high rate of packet loss.
"Republishing the IPV6-specific MIB modules as obsolete", Bill Fenner,
2016-02-18, <draft-ietf-6man-ipv6-mibs-obsolete-01.txt>
In 2005, the IPv6 MIB update group published updated versions of the
IP-MIB, UDP-MIB, TCP-MIB and IP-FORWARD-MIB modules, which use the
InetAddressType/InetAddress construct to handle IPv4 and IPv6 in the
same table. This document contains versions of the obsoleted
IPV6-MIB, IPV6-TC, IPV6-ICMP-MIB, IPV6-TCP-MIB and IPV6-UDP-MIB
modules, for the purpose of updating MIB module repositories.
"Routing packets from hosts in a multi-prefix network", Fred Baker,
Brian Carpenter, 2016-02-22, <draft-ietf-6man-multi-homed-host-06.txt>
This document describes expected IPv6 host behavior in a network that
has more than one prefix, each allocated by an upstream network that
implements BCP 38 ingress filtering, when the host has multiple
routers to choose from. It also applies to other scenarios such as
the usage of stateful firewalls that effectively act as address-based
filters. This host behavior may interact with source address
selection in a given implementation, but logically follows it. Given
that the network or host is, or appears to be, multihomed with
multiple provider-allocated addresses, that the host has elected to
use a source address in a given prefix, and that some but not all
neighboring routers are advertising that prefix in their Router
Advertisement Prefix Information Options, this document specifies to
which router a host should present its transmission. It updates RFC
4861.
"Internet Protocol, Version 6 (IPv6) Specification", Steve Deering,
Robert Hinden, 2016-03-21, <draft-ietf-6man-rfc2460bis-04.txt>
This document specifies version 6 of the Internet Protocol (IPv6).
It obsoletes RFC2460
"IPv6 Hop-by-Hop Options Extension Header", Fred Baker, Ron Bonica,
2016-03-16, <draft-ietf-6man-hbh-header-handling-03.txt>
This document clarifies requirements for IPv6 routers with respect to
the Hop-by-Hop (HBH) Options Extension Header. These requirements
are applicable to all IPv6 routers, regardless of whether they
maintain a strict separation between forwarding and control plane
hardware. In this respect, this document updates RFC 2460 and RFC
7045.
This document also describes forwarding plane procedures for

processing the HBH Options Extension Header. These procedures are

applicable to implementations that maintain a strict separation
between forwarding and control plane implementations.
The procedures described herein satisfy the above mentioned
requirements by processing HBH Options on the forwarding plane to the
greatest degree possible. If a packet containing HBH Options must be
dispatched to the control plane, it is rate limited before
dispatching. In order to comply with the requirements of this
specification, implementations may execute the procedures described
herein or any other procedures that result in compliant behavior.
"Path MTU Discovery for IP version 6", Jack McCann, Steve Deering,
Jeffrey Mogul, 2015-12-01, <draft-hinden-6man-rfc1981bis-01.txt>
This document describes Path MTU Discovery for IP version 6. It is
largely derived from RFC 1191, which describes Path MTU Discovery for
IP version 4. It obsoletes RFC1981.
"Support for adjustable maximum router lifetimes per-link", Suresh
Krishnan, Jouni Korhonen, Samita Chakrabarti, Erik Nordmark, Andrew
Yourtchenko, 2015-12-09, <draft-ietf-6man-maxra-00.txt>
The neighbor discovery protocol specifies the maximum time allowed
between sending unsolicited multicast Router Advertisements from a
router interface as well as the maximum router lifetime. It also
allows the limits to be overridden by link-layer specific documents.
This document allows for overriding these values on a per-link basis.
"IPv6 Segment Routing Header (SRH)", Stefano Previdi, Clarence Filsfils,
Brian Field, Ida Leung, J. Linkova, exa, Tomoya Kosugi, Eric Vyncke,
David Lebrun, 2016-03-18,
<draft-ietf-6man-segment-routing-header-01.txt>
Segment Routing (SR) allows a node to steer a packet through a
controlled set of instructions, called segments, by prepending an SR
header to the packet. A segment can represent any instruction,
topological or service-based. SR allows to enforce a flow through
any path (topological, or application/service based) while
maintaining per-flow state only at the ingress node to the SR domain.
Segment Routing can be applied to the IPv6 data plane with the
addition of a new type of Routing Extension Header. This draft
describes the Segment Routing Extension Header Type and how it is
used by SR capable nodes.
"IP Version 6 Addressing Architecture", Robert Hinden, Steve Deering,
2016-04-27, <draft-ietf-6man-rfc4291bis-02.txt>
This specification defines the addressing architecture of the IP
Version 6 (IPv6) protocol. The document includes the IPv6 addressing
model, text representations of IPv6 addresses, definition of IPv6
unicast addresses, anycast addresses, and multicast addresses, and an
IPv6 node's required addresses.
This document obsoletes RFC 4291, "IP Version 6 Addressing
Architecture".
"Path MTU Discovery for IP version 6", Jack <>, Stephen <>, Jeffrey <>,
Robert Hinden, 2016-04-27, <draft-ietf-6man-rfc1981bis-02.txt>

This document describes Path MTU Discovery for IP version 6. It is

largely derived from RFC 1191, which describes Path MTU Discovery for
IP version 4. It obsoletes RFC1981.
IPv6 over the TSCH mode of IEEE 802.15.4e (6tisch)
-------------------------------------------------"An Architecture for IPv6 over the TSCH mode of IEEE 802.15.4", Pascal
Thubert, 2015-11-27, <draft-ietf-6tisch-architecture-09.txt>
This document describes a network architecture that provides lowlatency, 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.
"Terminology in IPv6 over the TSCH mode of IEEE 802.15.4e", Maria
Palattella, Pascal Thubert, Thomas Watteyne, Qin Wang, 2016-03-21,
<draft-ietf-6tisch-terminology-07.txt>
6TiSCH proposes an architecture for an IPv6 multi-link subnet that is
composed of a high speed powered backbone and a number of
IEEE802.15.4e TSCH wireless networks attached and synchronized by
backbone routers. This document extends existing terminology
documents available for Low-power and Lossy Networks to provide
additional terminology elements.
"Minimal 6TiSCH Configuration", Xavier Vilajosana, Kris Pister,
2016-02-28, <draft-ietf-6tisch-minimal-15.txt>
This document describes a minimal mode of operation for a 6TiSCH
Network, to provide IPv6 connectivity over a Non-Broadcast MultiAccess (NBMA) mesh that is formed of IEEE 802.15.4 Timeslotted
Channel Hopping (TSCH) links.
This minimal mode uses a collection of protocols including the
6LoWPAN framework and RPL to enable interoperable IPv6 connectivity
over IEEE 802.15.4 TSCH with minimal network configuration and
infrastructure.
"6top Protocol (6P)", Qin Wang, Xavier Vilajosana, 2016-04-27,
<draft-ietf-6tisch-6top-protocol-00.txt>
This document defines the 6top Protocol (6P), which enables
distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes
in a 6TiSCH network to add/delete TSCH cells to one another. 6P is
part of the 6TiSCH Operation Sublayer (6top), the next higher layer
of the IEEE802.15.4 TSCH medium access control layer. The 6top
Scheduling Function (SF) decides when to add/delete cells, and
triggers 6P transactions. Several SFs can be defined, each
identified by a different 6top Scheduling Function Identifier (SFID).
This document lists the requirements for an SF, but leaves the
definition of the SF out of scope. Different SFs are expected to be
defined in future companion specifications.
Application Bridging for Federated Access Beyond web (abfab)
-----------------------------------------------------------"A RADIUS Attribute, Binding, Profiles, Name Identifier Format, and

Confirmation Methods for SAML", Josh Howlett, Sam Hartman, Alejandro

Perez-Mendez, 2016-01-11, <draft-ietf-abfab-aaa-saml-14.txt>
This document describes the use of the Security Assertion Mark-up
Language (SAML) with RADIUS in the context of the ABFAB architecture.
It defines two RADIUS attributes, a SAML binding, a SAML name
identifier format, two SAML profiles, and two SAML confirmation
methods. The RADIUS attributes permit encapsulation of SAML
assertions and protocol messages within RADIUS, allowing SAML
entities to communicate using the binding. The two profiles describe
the application of this binding for ABFAB authentication and
assertion query/request, enabling a Relying Party to request
authentication of, or assertions for, users or machines (Clients).
These Clients may be named using a NAI name identifier format.
Finally, the subject confirmation methods allow requests and queries
to be issued for a previously authenticated user or machine without
needing to explicitly identify them as the subject. The use of the
artifacts defined in this document is not exclusive to ABFAB. They
can be applied in any AAA scenario, such as the network access
control.
"Application Bridging for Federated Access Beyond web (ABFAB) Use
Cases", Rhys Smith, 2012-09-25, <draft-ietf-abfab-usecases-05.txt>
Federated identity is typically associated with Web-based services at
present, but there is growing interest in its application in non Webbased contexts. The goal of this document is to document a selection
of the wide variety of these contexts whose user experience could be
improved through the use of technologies based on the ABFAB
architecture and specifications.
"Application Bridging for Federated Access Beyond Web (ABFAB)
Architecture", Josh Howlett, Sam Hartman, Hannes Tschofenig, Eliot Lear,
Jim Schaad, 2014-07-21, <draft-ietf-abfab-arch-13.txt>
Over the last decade a substantial amount of work has occurred in the
space of federated access management. Most of this effort has
focused on two use cases: network access and web-based access.
However, the solutions to these use cases that have been proposed and
deployed tend to have few building blocks in common.
This memo describes an architecture that makes use of extensions to
the commonly used security mechanisms for both federated and nonfederated access management, including the Remote Authentication Dial
In User Service (RADIUS) the Generic Security Service Application
Program Interface (GSS-API), the Extensible Authentication Protocol
(EAP) and the Security Assertion Markup Language (SAML). The
architecture addresses the problem of federated access management to
primarily non-web-based services, in a manner that will scale to
large numbers of identity providers, relying parties, and
federations.
"Application Bridging for Federated Access Beyond web (ABFAB) Usability
and User Interface Considerations", Rhys Smith, Mark Donnelly,
2016-03-21, <draft-ietf-abfab-usability-ui-considerations-04.txt>
The real world use of ABFAB-based technologies requires that any
identity that is to be used for authentication has to be configured
on the ABFAB-enabled client device. Achieving this requires software
on that device (either built into the operating system or a

standalone utility) that will interact with the user, managing their
identity information and identity-to-service mappings. All designers
of software to fulfil this role will face the same set of challenges.
This document aims to document these challenges with the aim of
producing well-thought out UIs with some degree of consistency
between implementations.
Authentication and Authorization for Constrained Environments (ace)
------------------------------------------------------------------"An architecture for authorization in constrained environments",
Stefanie Gerdes, Ludwig Seitz, Goran Selander, Carsten Bormann,
2016-03-01, <draft-ietf-ace-actors-03.txt>
Constrained-node networks are networks where some nodes have severe
constraints on code size, state memory, processing capabilities, user
interface, power and communication bandwidth (RFC 7228).
This document provides terminology, and identifies the elements that
an architecture needs to address, providing a problem statement, for
authentication and authorization in these networks.
"Authorization for the Internet of Things using OAuth 2.0", Ludwig
Seitz, Goran Selander, Erik Wahlstroem, Samuel Erdtman, Hannes
Tschofenig, 2016-02-25, <draft-ietf-ace-oauth-authz-01.txt>
This memo defines how to use OAuth 2.0 as an authorization framework
with Internet of Things (IoT) deployments, thus bringing a well-known
and widely used security solution to IoT devices. Where possible
vanilla OAuth 2.0 is used, but where the limitations of IoT devices
require it, profiles and extensions are provided.
Automated Certificate Management Environment (acme)
--------------------------------------------------"Automatic Certificate Management Environment (ACME)", Richard Barnes,
Jacob Hoffman-Andrews, James Kasten, 2016-03-21,
<draft-ietf-acme-acme-02.txt>
Certificates in the Web's X.509 PKI (PKIX) are used for a number of
purposes, the most significant of which is the authentication of
domain names. Thus, certificate authorities in the Web PKI are
trusted to verify that an applicant for a certificate legitimately
represents the domain name(s) in the certificate. Today, this
verification is done through a collection of ad hoc mechanisms. This
document describes a protocol that a certificate authority (CA) and
an applicant can use to automate the process of verification and
certificate issuance. The protocol also provides facilities for
other certificate management functions, such as certificate
revocation.
Application-Layer Traffic Optimization (alto)
--------------------------------------------"ALTO Deployment Considerations", Martin Stiemerling, Sebastian Kiesel,
Michael Scharf, Hans Seidel, Stefano Previdi, 2016-04-18,
<draft-ietf-alto-deployments-14.txt>
Many Internet applications are used to access resources such as
pieces of information or server processes that are available in

several equivalent replicas on different hosts. This includes, but

is not limited to, peer-to-peer file sharing applications. The goal
of Application-Layer Traffic Optimization (ALTO) is to provide
guidance to applications that have to select one or several hosts
from a set of candidates, which are able to provide a desired
resource. This memo discusses deployment related issues of ALTO. It
addresses different use cases of ALTO such as peer-to-peer file
sharing and CDNs and presents corresponding examples. The document
also includes recommendations for network administrators and
application designers planning to deploy ALTO, such recommendations
how to generate ALTO map information.
"ALTO Incremental Updates Using Server-Sent Events (SSE)", Wendy Roome,
Y. Yang, 2016-04-04, <draft-ietf-alto-incr-update-sse-02.txt,.pdf>
The Application-Layer Traffic Optimization (ALTO) [RFC7285] protocol
provides network related information to client applications so that
clients may make informed decisions. To that end, an ALTO Server
provides Network and Cost Maps. Using those maps, an ALTO Client can
determine the costs between endpoints.
However, the ALTO protocol does not define a mechanism to allow an
ALTO client to obtain updates to those maps, other than by
periodically re-fetching them. Because the maps may be large
(potentially tens of megabytes), and because only parts of the maps
may change frequently (especially Cost Maps), that can be extremely
inefficient.
Therefore this document presents a mechanism to allow an ALTO Server
to provide updates to ALTO Clients. Updates can be both immediate,
in that the server can send updates as soon as they are available,
and incremental, in that if only a small section of a map changes,
the server can send just the changes.
Autonomic Networking Integrated Model and Approach (anima)
---------------------------------------------------------"A Generic Autonomic Signaling Protocol (GRASP)", Carsten Bormann, Brian
Carpenter, Bing Liu, 2016-03-10, <draft-ietf-anima-grasp-04.txt>
This document establishes requirements for a signaling protocol that
enables autonomic devices and autonomic service agents to dynamically
discover peers, to synchronize state with them, and to negotiate
parameter settings mutually with them. The document then defines a
general protocol for discovery, synchronization and negotiation,
while the technical objectives for specific scenarios are to be
described in separate documents. An Appendix briefly discusses
existing protocols with comparable features.
"An Autonomic Control Plane", Michael Behringer, Steinthor Bjarnason,
Balaji BL, Toerless Eckert, 2016-03-21,
<draft-ietf-anima-autonomic-control-plane-02.txt>
Autonomic functions need a control plane to communicate, which
depends on some addressing and routing. This Autonomic Control Plane
should ideally be self-managing, and as independent as possible of
configuration. This document defines an "Autonomic Control Plane",
with the primary use as a control plane for autonomic functions. It
also serves as a "virtual out of band channel" for OAM communications
over a network that is not configured, or mis-configured.

"Bootstrapping Key Infrastructures", Max Pritikin, Michael Richardson,

Michael Behringer, Steinthor Bjarnason, 2016-03-17,
<draft-ietf-anima-bootstrapping-keyinfra-02.txt>
This document specifies automated bootstrapping of a key
infrastructure (BSKI) using vendor installed IEEE 802.1AR
manufacturing installed certificates, in combination with a vendor
based service on the Internet. Before being authenticated, a new
device has only link-local connectivity, and does not require a
routable address. When a vendor provides an Internet based service,
devices can be forced to join only specific domains but in limited/
disconnected networks or legacy environments we describe a variety of
options that allow bootstrapping to proceed.
"A Reference Model for Autonomic Networking", Michael Behringer, Brian
Carpenter, Toerless Eckert, Laurent Ciavaglia, Bing Liu, Jeff, John
Strassner, 2016-03-21, <draft-ietf-anima-reference-model-01.txt>
This document describes a reference model for Autonomic Networking.
The goal is to define how the various elements in an autonomic
context work together, to describe their interfaces and relations.
While the document is written as generally as possible, the initial
solutions are limited to the chartered scope of the WG.
"Autonomic IPv6 Edge Prefix Management in Large-scale Networks", Sheng
Jiang, Zongpeng Du, Brian Carpenter, Qiong, 2016-01-11,
<draft-ietf-anima-prefix-management-00.txt>
This document describes an autonomic solution for IPv6 prefix
management at the edge of large-scale ISP networks. An important
purpose of the document is to use it for validation of the design of
various components of the autonomic networking infrastructure.
"Using Autonomic Control Plane for Stable Connectivity of Network OAM",
Toerless Eckert, Michael Behringer, 2016-01-13,
<draft-ietf-anima-stable-connectivity-00.txt>
OAM (Operations, Administration and Management) processes for data
networks are often subject to the problem of circular dependencies
when relying on network connectivity of the network to be managed for
the OAM operations itself. Provisioning during device/network bring
up tends to be far less easy to automate than service provisioning
later on, changes in core network functions impacting reachability
can not be automated either because of ongoing connectivity
requirements for the OAM equipment itself, and widely used OAM
protocols are not secure enough to be carried across the network
without security concerns.
This document describes how to integrate OAM processes with the
autonomic control plane (ACP) in Autonomic Networks (AN). to provide
stable and secure connectivity for those OAM processes.
ART Area General Applications Working Group (appsawg)
----------------------------------------------------"Message Disposition Notification", Tony Hansen, Alexey Melnikov,
2016-05-01, <draft-ietf-appsawg-mdn-3798bis-07.txt>
This memo defines a MIME content-type that may be used by a mail user

agent (MUA) or electronic mail gateway to report the disposition of a

message after it has been successfully delivered to a recipient.
This content-type is intended to be machine-processable. Additional
message header fields are also defined to permit Message Disposition
Notifications (MDNs) to be requested by the sender of a message. The
purpose is to extend Internet Mail to support functionality often
found in other messaging systems, such as X.400 and the proprietary
"LAN-based" systems, and often referred to as "read receipts,"
"acknowledgements", or "receipt notifications." The intention is to
do this while respecting privacy concerns, which have often been
expressed when such functions have been discussed in the past.
Because many messages are sent between the Internet and other
messaging systems (such as X.400 or the proprietary "LAN-based"
systems), the MDN protocol is designed to be useful in a multiprotocol messaging environment. To this end, the protocol described
in this memo provides for the carriage of "foreign" addresses, in
addition to those normally used in Internet Mail. Additional
attributes may also be defined to support "tunneling" of foreign
notifications through Internet Mail.
"The file URI Scheme", Matthew Kerwin, 2016-04-22,
<draft-ietf-appsawg-file-scheme-08.txt>
This document specifies the "file" Uniform Resource Identifier (URI)
scheme, obsoleting the definition in RFC 1738.
It defines a common syntax which is intended to interoperate across
the broad spectrum of existing usages. At the same time it notes
some other current practices around the use of file URIs.
Note to Readers (To be removed by the RFC Editor)
This draft should be discussed on the IETF Applications Area Working
Group discussion list <apps-discuss@ietf.org>.
Active Queue Management and Packet Scheduling (aqm)
--------------------------------------------------"AQM Characterization Guidelines", N. Kuhn, Preethi Natarajan, Naeem
Khademi, David Ros, 2016-02-15, <draft-ietf-aqm-eval-guidelines-11.txt>
Unmanaged large buffers in today's networks have given rise to a slew
of performance issues. These performance issues can be addressed by
some form of Active Queue Management (AQM) mechanism, optionally in
combination with a packet scheduling scheme such as fair queuing.
This document describes various criteria for performing precautionary
characterizations of AQM schemes.
"The Benefits of using Explicit Congestion Notification (ECN)", Gorry
Fairhurst, Michael Welzl, 2015-11-23,
<draft-ietf-aqm-ecn-benefits-08.txt>
The goal of this document is to describe the potential benefits when
applications use a transport that enables Explicit Congestion
Notification (ECN). The document outlines the principal gains in
terms of increased throughput, reduced delay and other benefits when
ECN is used over a network path that includes equipment that supports
Congestion Experienced (CE) marking. It also discusses challenges
for successful deployment of ECN. It does not propose new algorithms

to use ECN, nor does it describe the details of implementation of ECN

in endpoint devices (Internet hosts), routers or other network
devices.
"Controlled Delay Active Queue Management", Kathleen Nichols, Van
Jacobson, Andrew McGregor, Jana Iyengar, 2016-03-15,
<draft-ietf-aqm-codel-03.txt>
This document describes a general framework called CoDel (Controlled
Delay) [CODEL2012] that controls bufferbloat-generated excess delay
in modern networking environments. CoDel consists of an estimator, a
setpoint, and a control loop. It requires no configuration in normal
Internet deployments. CoDel comprises some major technical
innovations and has been made available as open source so that the
framework can be applied by the community to a range of problems. It
has been implemented in Linux (and available in the Linux
distribution) and deployed in some networks at the consumer edge. In
addition, the framework has been successfully applied in other ways.
Note: Code Components extracted from this document must include the
license as included with the code in Section 5.
"PIE: A Lightweight Control Scheme To Address the Bufferbloat Problem",
Rong Pan, Preethi Natarajan, Fred Baker, 2016-04-19,
<draft-ietf-aqm-pie-07.txt>
Bufferbloat is a phenomenon where excess buffers in the network cause
high latency and jitter. As more and more interactive applications
(e.g. voice over IP, real time video streaming and financial
transactions) run in the Internet, high latency and jitter degrade
application performance. There is a pressing need to design
intelligent queue management schemes that can control latency and
jitter; and hence provide desirable quality of service to users.
This document presents a lightweight active queue management design,
called PIE (Proportional Integral controller Enhanced), that can
effectively control the average queueing latency to a target value.
Simulation results, theoretical analysis and Linux testbed results
have shown that PIE can ensure low latency and achieve high link
utilization under various congestion situations. The design does not
require per-packet timestamp, so it incurs very small overhead and is
simple enough to implement in both hardware and software.
"The FlowQueue-CoDel Packet Scheduler and Active Queue Management
Algorithm", Toke Hoeiland-Joergensen, Paul McKenney,
dave.taht@gmail.com, Jim Gettys, Eric Dumazet, 2016-03-18,
<draft-ietf-aqm-fq-codel-06.txt>
This memo presents the FQ-CoDel hybrid packet scheduler/Active Queue
Management algorithm, a powerful tool for fighting bufferbloat and
reducing latency.
FQ-CoDel mixes packets from multiple flows and reduces the impact
head of line blocking from bursty traffic. It provides isolation
low-rate traffic such as DNS, web, and videoconferencing traffic.
improves utilisation across the networking fabric, especially for
bidirectional traffic, by keeping queue lengths short; and it can
implemented in a memory- and CPU-efficient fashion across a wide
range of hardware.

of
for
It
be

"A PIE-Based AQM for DOCSIS Cable Modems", Greg White, Rong Pan,
2016-02-15, <draft-ietf-aqm-docsis-pie-02.txt>
Cable modems based on the DOCSIS(R) specification provide broadband
Internet access to over one hundred million users worldwide. In some
cases, the cable modem connection is the bottleneck (lowest speed)
link between the customer and the Internet. As a result, the impact
of buffering and bufferbloat in the cable modem can have a
significant effect on user experience. The CableLabs DOCSIS 3.1
specification introduces requirements for cable modems to support an
Active Queue Management (AQM) algorithm that is intended to alleviate
the impact that buffering has on latency sensitive traffic, while
preserving bulk throughput performance. In addition, the CableLabs
DOCSIS 3.0 specifications have also been amended to contain similar
requirements. This document describes the requirements on Active
Queue Management that apply to DOCSIS equipment, including a
description of the "DOCSIS-PIE" algorithm that is required on DOCSIS
3.1 cable modems.
Applications and Real-Time Area (art)
------------------------------------"Brotli Compressed Data Format", Jyrki Alakuijala, Zoltan Szabadka,
2016-05-04, <draft-alakuijala-brotli-10.txt>
This specification defines a lossless compressed data format that
compresses data using a combination of the LZ77 algorithm and Huffman
coding, with efficiency comparable to the best currently available
general-purpose compression methods.
"Lightweight Directory Access Protocol (LDAP) Registrations for PKCS
#9", Sean Leonard, 2016-03-12, <draft-seantek-ldap-pkcs9-04.txt>
PKCS #9 includes several useful definitions that are not yet
reflected in the LDAP IANA registry. This document adds those
definitions to the IANA registry.
"DISPATCH-Style Working Groups and the SIP-Change Process", Ben
Campbell, Alissa Cooper, Barry Leiba, 2016-03-11,
<draft-campbell-art-rfc5727-update-03.txt>
RFC 5727 defined several processes for the former Real-time
Applications and Infrastructure (RAI) area. These processes include
the evolution of the Session Initiation Protocol (SIP) and related
protocols, as well as the operation of the DISPATCH and SIPCORE
working groups. This document updates RFC 5727 to allow flexibility
for the area and working group structure, while preserving the SIPchange processes. It also generalizes the DISPATCH working group
processes so that they can be easily adopted by other working groups.
"A URN Namespace for Globus", Stuart Martin, Steve Tuecke, Brendan
McCollam, Mattias Lidman, 2016-03-18, <draft-martin-urn-globus-03.txt>
This document describes a URN (Uniform Resource Name) namespace that
is used by Globus for naming persistent resources.
"Clarifying registry procedures for the Websockets sub-protocol
registry", Ted Hardie, 2016-04-27,
<draft-hardie-rfc6455-iana-clarification-02.txt>

This document clarifies the instructions to IANA for the sub-protocol

registry set up for Websockets in RFC 6455.
"Sieve Email Filtering: Delivering to Special-Use Mailboxes", Stephan
Bosch, 2016-04-04, <draft-bosch-sieve-special-use-00.txt>
The SPECIAL-USE capability of the IMAP protocol (RFC 6154) allows
clients to identify special-use mailboxes; e.g., where draft or sent
messages should be put. This simplifies client configuration. In
contrast, the Sieve mail filtering language (RFC 5228) currently has
no such capability. This memo defines a Sieve extension that fills
this gap: it adds a test for checking whether a special-use attribute
is assigned for a particular mailbox or any mailbox, and it adds the
ability to file messages into an anonymous mailbox that has a
particular special-use attribute assigned.
"Advertising Digital Identification (Ad-ID) URN Namespace Definition",
jwold@ad-id.org, 2016-04-14, <draft-adid-urn-00.txt>
Advertising Digital Identification (Ad-ID) Identifiers are used
identifying Advertising Assets across all media platforms (over the
air, on-line, over the top, mobile, place based). This document
defines the formal Uniform Resource Name (URN) Namespace Identifier
(NID) for Ad-ID Identifiers.
Audio/Video Transport Core Maintenance (avtcore)
-----------------------------------------------"The ARIA Algorithm and Its Use with the Secure Real-time Transport
Protocol(SRTP)", Woo-Hwan Kim, Jungkeun Lee, Je-Hong Park, Daesung Kwon,
2015-11-25, <draft-ietf-avtcore-aria-srtp-09.txt>
This document defines the use of the ARIA block cipher algorithm
within the Secure Real-time Transport Protocol (SRTP). It details
two modes of operation (CTR, GCM) and a SRTP Key Derivation Function
for ARIA. Additionally, this document defines DTLS-SRTP protection
profiles and MIKEY parameter sets for the use with ARIA.
"Sending Multiple Types of Media in a Single RTP Session", Magnus
Westerlund, Colin Perkins, Jonathan Lennox, 2015-12-18,
<draft-ietf-avtcore-multi-media-rtp-session-13.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.
"Multimedia Congestion Control: Circuit Breakers for Unicast RTP
Sessions", Colin Perkins, Varun, 2016-04-30,
<draft-ietf-avtcore-rtp-circuit-breakers-15.txt>
The Real-time Transport Protocol (RTP) is widely used in telephony,
video conferencing, and telepresence applications. Such applications
are often run on best-effort UDP/IP networks. If congestion control
is not implemented in these applications, then network congestion can
lead to uncontrolled packet loss, and a resulting deterioration of
the user's multimedia experience. The congestion control algorithm
acts as a safety measure, stopping RTP flows from using excessive

resources, and protecting the network from overload. At the time of

this writing, however, while there are several proprietary solutions,
there is no standard algorithm for congestion control of interactive
RTP flows.
This document does not propose a congestion control algorithm. It
instead defines a minimal set of RTP circuit breakers: conditions
under which an RTP sender needs to stop transmitting media data, to
protect the network from excessive congestion. It is expected that,
in the absence of long-lived excessive congestion, RTP applications
running on best-effort IP networks will be able to operate without
triggering these circuit breakers. Future RTP congestion control
specifications will be expected to operate within the constraints
defined by these circuit breakers.
"Sending Multiple RTP Streams in a Single RTP Session", Jonathan Lennox,
Magnus Westerlund, Qin Wu, Colin Perkins, 2015-12-11,
<draft-ietf-avtcore-rtp-multi-stream-11.txt>
This memo expands and clarifies the behaviour of Real-time Transport
Protocol (RTP) endpoints that use multiple synchronization sources
(SSRCs). This occurs, for example, when an endpoint sends multiple
RTP streams in a single RTP session. This memo updates RFC 3550 with
regards to handling multiple SSRCs per endpoint in RTP sessions, with
a particular focus on RTCP behaviour. It also updates RFC 4585 to
update and clarify the calculation of the timeout of SSRCs and the
inclusion of feedback messages.
"Sending Multiple RTP Streams in a Single RTP Session: Grouping RTCP
Reception Statistics and Other Feedback", Jonathan Lennox, Magnus
Westerlund, Qin Wu, Colin Perkins, 2016-03-02,
<draft-ietf-avtcore-rtp-multi-stream-optimisation-12.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.
"Multipath RTP (MPRTP)", Varun, Teemu Karkkainen, Joerg Ott, Saba Ahsan,
Lars Eggert, 2016-03-21, <draft-ietf-avtcore-mprtp-02.txt,.pdf>
The Real-time Transport Protocol (RTP) is used to deliver real-time
content and, along with the RTP Control Protocol (RTCP), forms the
control channel between the sender and receiver. However, RTP and
RTCP assume a single delivery path between the sender and receiver
and make decisions based on the measured characteristics of this
single path. Increasingly, endpoints are becoming multi-homed, which
means that they are connected via multiple Internet paths. Network
utilization can be improved when endpoints use multiple parallel
paths for communication. The resulting increase in reliability and
throughput can also enhance the user experience. This document
extends the Real-time Transport Protocol (RTP) so that a single
session can take advantage of the availability of multiple paths
between two endpoints.

"Multiplexing Scheme Updates for Secure Real-time Transport Protocol

(SRTP) Extension for Datagram Transport Layer Security (DTLS)", Marc
Petit-Huguenin, Gonzalo Salgueiro, 2016-03-02,
<draft-ietf-avtcore-rfc5764-mux-fixes-06.txt>
This document defines how Datagram Transport Layer Security (DTLS),
Real-time Transport Protocol (RTP), RTP Control Protocol (RTCP),
Session Traversal Utilities for NAT (STUN), and Traversal Using
Relays around NAT (TURN) packets are multiplexed on a single
receiving socket. It overrides the guidance from SRTP Extension for
DTLS [RFC5764], which suffered from three issues described and fixed
in this document.
"The Addition of SRTP crypto suites based on the ARIA algorithms to the
SDP Security Descritpions", Woo-Hwan Kim, Jungkeun Lee, Je-Hong Park,
Daesung Kwon, 2015-11-25, <draft-ietf-avtcore-aria-sdes-01.txt>
This document defines SRTP crypto suites based on the ARIA block
cipher algorithm for use with the Session Descritpion Protocol (SDP)
security descriptions.
"A General Mechanism for RTP Header Extensions", Roni Even, David
Singer, HariKishan Desineni, 2015-12-23,
<draft-ietf-avtcore-rfc5285-bis-01.txt,.pdf>
This document provides a general mechanism to use the header
extension feature of RTP (the Real-Time Transport Protocol). It
provides the option to use a small number of small extensions in each
RTP packet, where the universe of possible extensions is large and
registration is de-centralized. The actual extensions in use in a
session are signaled in the setup information for that session.
Audio/Video Transport Extensions (avtext)
----------------------------------------"RTP/RTCP extension for RTP Splicing Notification", Jinwei Xia, Roni
Even, Rachel Huang, Deng Lingli, 2016-04-06,
<draft-ietf-avtext-splicing-notification-06.txt>
Content splicing is a process that replaces the content of a main
multimedia stream with other multimedia content, and delivers the
substitutive multimedia content to the receivers for a period of
time. The splicer is designed to handle RTP splicing and needs to
know when to start and end the splicing.
This memo defines two RTP/RTCP extensions to indicate the splicing
related information to the splicer: an RTP header extension that
conveys the information in-band and an RTCP packet that conveys the
information out-of-band.
"RTP Header Extension for RTCP Source Description Items", Magnus
Westerlund, Bo Burman, Roni Even, Mo Zanaty, 2016-04-26,
<draft-ietf-avtext-sdes-hdr-ext-06.txt>
Source Description (SDES) items are normally transported in RTP
control protocol (RTCP). In some cases it can be beneficial to speed
up the delivery of these items. Mainly when a new source (SSRC)
joins an RTP session and the receivers needs this source's identity,
relation to other sources, or its synchronization context, all of
which may be fully or partially identified using SDES items. To

enable this optimization, this document specifies a new RTP header

extension that can carry SDES items.
"The Layer Refresh Request (LRR) RTCP Feedback Message", Jonathan
Lennox, Danny Hong, Justin Uberti, Stefan Holmer, Magnus Flodman,
2016-03-21, <draft-ietf-avtext-lrr-02.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.
"Frame Marking RTP Header Extension", Espen Berger, Suhas Nandakumar, Mo
Zanaty, 2016-03-21, <draft-ietf-avtext-framemarking-01.txt>
This document describes a Frame Marking RTP header extension used to
convey information about video frames that is critical for error
recovery and packet forwarding in RTP middleboxes or network nodes.
It is most useful when media is encrypted, and essential when the
middlebox or node has no access to the media encryption keys. It is
also useful for codec-agnostic processing of encrypted or unencrypted
media, while it also supports extensions for codec-specific
information.
"RTP Stream Identifier Source Description (SDES)", Adam Roach, Suhas
Nandakumar, Peter Thatcher, 2016-05-02, <draft-ietf-avtext-rid-02.txt>
This document defines and registers two new RTCP 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.
"Using Codec Control Messages in the RTP Audio-Visual Profile with
Feedback with Layered Codecs", Stephan Wenger, Jonathan Lennox, Bo
Burman, Magnus Westerlund, 2016-04-25,
<draft-ietf-avtext-avpf-ccm-layered-00.txt>
This document fixes a shortcoming in the specification language of
the Codec Control Message Full Intra Request (FIR) as defined in
RFC5104 when using with layered codecs. In particular, a Decoder
Refresh Point needs to be sent by a media sender when a FIR is
received on any layer of the layered bitstream, regardless on whether
those layers are being sent in a single or in multiple RTP flows.
The other payload-specific feedback messages defined in RFC 5104 and
RFC 4585 as updated by RFC 5506 have also been analyzed, and no
corresponding shortcomings have been found.
BGP Enabled ServiceS (bess)
--------------------------"BGP-signaled end-system IP/VPNs.", Pedro Marques, Luyuan Fang, Nischal
Sheth, Maria Napierala, Nabil Bitar, 2015-10-08,
<draft-ietf-l3vpn-end-system-05.txt>
This document describes a solution in which the control plane
protocol specified in BGP/MPLS IP VPNs is used and extended via the
XMPP protocol to provide a Virtual Network service to end-systems.
These end-systems may be used to provide network services or may
directly host end-to-end applications.

"L2L3 VPN Multicast MIB", Jeffrey Zhang, 2016-04-16,

<draft-ietf-bess-l2l3-vpn-mcast-mib-03.txt>
This memo defines a portion of the Management Information Base for
use with network management protocols in the Internet community.
In particular, it describes common managed objects used to configure
and/or monitor both L2 and L3 VPN Multicast.
"MPLS/BGP Layer 3 VPN Multicast Management Information Base", Jeffrey
Zhang, Saud Asif, Andy Green, Sameer Gulrajani, Pradeep Jain,
2016-03-14, <draft-ietf-bess-mvpn-mib-02.txt>
This memo defines an 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 in MPLS/BGP IP VPNs (MVPN) on a router.
"BGP based Multi-homing in Virtual Private LAN Service", Bhupesh
Kothari, Kireeti Kompella, Wim Henderickx, Florin Balus, Jim Uttaro,
Senad Palislamovic, Wen Lin, 2016-01-06,
<draft-ietf-bess-vpls-multihoming-01.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.
"Usage and applicability of BGP MPLS based Ethernet VPN", Jorge Rabadan,
Senad Palislamovic, Wim Henderickx, Keyur Patel, Ali Sajassi, Aldrin
Isaac, 2016-03-19, <draft-ietf-bess-evpn-usage-02.txt>
This document discusses the usage and applicability of BGP MPLS based
Ethernet VPN (EVPN) in a simple and fairly common deployment
scenario. The different EVPN procedures will be explained on the
example scenario, analyzing the benefits and trade-offs of each
option. Along with [RFC7432], this document is intended to provide a
simplified guide for the deployment of EVPN in Service Provider
networks.
"Extranet Multicast in BGP/IP MPLS VPNs", Yakov Rekhter, Eric Rosen,
Rahul Aggarwal, Yiqun Cai, Thomas Morin, 2016-04-12,
<draft-ietf-bess-mvpn-extranet-07.txt>
Previous RFCs specify the procedures necessary to allow IP multicast
traffic to travel from one site to another within a BGP/MPLS IP VPN
(Virtual Private Network). However, it is sometimes desirable to
allow multicast traffic whose source is in one VPN to be received by
systems that are in another VPN. This is known as a "Multicast VPN
(MVPN) extranet". This document updates RFCs 6513, 6514, and 6625 by
specifying the procedures that are necessary in order to provide MVPN
extranet service.
"Ingress Replication Tunnels in Multicast VPN", Eric Rosen, Karthik
Subramanian, Jeffrey Zhang, 2016-04-11, <draft-ietf-bess-ir-03.txt>

RFCs 6513, 6514, and other RFCs describe procedures by which a

Service Provider may offer Multicast VPN service to its customers.
These procedures create point-to-multipoint (P2MP) or multipoint-tomultipoint trees across the Service Provider's backbone. One type of
P2MP tree that may be used is known as an "Ingress Replication (IR)
tunnel". In an IR tunnel, a parent node need not be "directly
connected" to its child nodes. When a parent node has to send a
multicast data packet to its child nodes, it does not use layer 2
multicast, IP multicast, or MPLS multicast to do so. Rather, it
makes n individual copies, and then unicasts each copy, through an IP
or MPLS unicast tunnel, to exactly one child node. While the prior
MVPN specifications allow the use of IR tunnels, those specifications
are not always very clear or explicit about how the MVPN protocol
elements and procedures are applied to IR tunnels. This document
updates RFCs 6513 and 6514 by adding additional details that are
specific to the use of IR tunnels.
"Interconnect Solution for EVPN Overlay networks", Jorge Rabadan,
Senthil Sathappan, Wim Henderickx, Senad Palislamovic, Ali Sajassi,
Dennis Cai, 2016-02-29, <draft-ietf-bess-dci-evpn-overlay-02.txt>
This document describes how Network Virtualization Overlay networks
(NVO) can be connected to a Wide Area Network (WAN) in order to
extend the layer-2 connectivity required for some tenants. The
solution analyzes the interaction between NVO networks running EVPN
and other L2VPN technologies used in the WAN, such as VPLS/PBB-VPLS
or EVPN/PBB-EVPN, and proposes a solution for the interworking
between both.
"FIB Reduction in Virtual Subnet", Xiaohu Xu, Christian Jacquenet,
Truman Boyes, Brendan Fee, Wim Henderickx, 2016-02-29,
<draft-ietf-bess-virtual-subnet-fib-reduction-02.txt>
Virtual Subnet is a BGP/MPLS IP VPN-based subnet extension solution
which is intended for building Layer3 network virtualization overlays
within and/or between data centers. This document describes a
mechanism for reducing the FIB size of PE routers in the Virtual
Subnet context.
"VPWS support in EVPN", Sami Boutros, Ali Sajassi, Samer Salam, John
Drake, Jeff Tantsura, Dirk Steinberg, Thomas Beckhaus, Jorge Rabadan,
2016-03-16, <draft-ietf-bess-evpn-vpws-03.txt>
This document describes how EVPN can be used to support virtual
private wire service (VPWS) in MPLS/IP networks. EVPN enables the
following characteristics for VPWS: single-active as well as allactive multi-homing with flow-based load-balancing, eliminates the
need for single-segment and multi-segment PW signaling, and provides
fast protection using data-plane prefix independent convergence upon
node or link failure.
"Multicast VPN state damping", Thomas Morin, Stephane Litkowski, Keyur
Patel, Jeffrey Zhang, Robert Kebler, Jeffrey Haas, 2016-05-04,
<draft-ietf-bess-multicast-damping-05.txt>
This document describes procedures to damp multicast VPN routing
state changes and control the effect of the churn due to the
multicast dynamicity in customer sites. The procedures described in
this document are applicable to BGP-based multicast VPN and help
avoid uncontrolled control plane load increase in the core routing

infrastructure. New procedures are proposed inspired from BGP

unicast route damping principles, but adapted to multicast.
"Registry and Extensions for P-Multicast Service Interface Tunnel
Attribute Flags", Eric Rosen, Thomas Morin, 2016-05-03,
<draft-ietf-bess-pta-flags-03.txt>
The BGP-based control procedures for Multicast Virtual Private
Networks make use of a BGP attribute known as the "P-Multicast
Service Interface (PMSI) Tunnel" attribute. The attribute contains a
one-octet "Flags" field. The purpose of this document is to
establish an IANA registry for the assignment of the bits in this
field. Since the Flags field contains only eight bits, this document
also defines a new BGP Extended Community, "Additional PMSI Tunnel
Attribute Flags", that can be used to carry additional flags for the
PMSI Tunnel attribute. This document updates RFC 6514.
"E-TREE Support in EVPN & PBB-EVPN", Ali Sajassi, Samer Salam, Sami
Boutros, Jim Uttaro, 2016-01-31, <draft-ietf-bess-evpn-etree-04.txt>
The Metro Ethernet Forum (MEF) has defined a rooted-multipoint
Ethernet service known as Ethernet Tree (E-Tree). [ETREE-FMWK]
proposes a solution framework for supporting this service in MPLS
networks. This document discusses how those functional requirements
can be easily met with (PBB-)EVPN and how (PBB-)EVPN offers a more
efficient implementation of these functions.
"Multicast VPN fast upstream failover", Thomas Morin, Robert Kebler,
2015-12-09, <draft-ietf-bess-mvpn-fast-failover-00.txt>
This document defines multicast VPN extensions and procedures that
allow fast failover for upstream failures, by allowing downstream PEs
to take into account the status of Provider-Tunnels (P-tunnels) when
selecting the upstream PE for a VPN multicast flow, and extending BGP
MVPN routing so that a C-multicast route can be advertized toward a
standby upstream PE.
"Updated processing of control flags for BGP VPLS", Ravi Singh, Kireeti
Kompella, Senad Palislamovic, 2016-01-05,
<draft-ietf-bess-bgp-vpls-control-flags-00.txt>
This document updates the meaning of the "control flags" fields
inside the "layer2 info extended community" used for BGP-VPLS NLRI.
"Optimized Ingress Replication solution for EVPN", Jorge Rabadan,
Senthil Sathappan, Wim Henderickx, Ali Sajassi, Aldrin Isaac,
2016-02-29, <draft-ietf-bess-evpn-optimized-ir-00.txt>
Network Virtualization Overlay (NVO) networks using EVPN as control
plane may use ingress replication (IR) or PIM-based trees to convey
the overlay multicast traffic. PIM provides an efficient solution to
avoid sending multiple copies of the same packet over the same
physical link, however it may not always be deployed in the NVO core
network. IR avoids the dependency on PIM in the NVO network core.
While IR provides a simple multicast transport, some NVO networks
with demanding multicast applications require a more efficient
solution without PIM in the core. This document describes a solution
to optimize the efficiency of IR in NVO networks.
"Operational Aspects of Proxy-ARP/ND in EVPN Networks", Jorge Rabadan,

Senthil Sathappan, Kiran Nagaraj, Wim Henderickx, Greg Hankins, Thomas

King, Daniel Melzer, Erik Nordmark, 2016-04-04,
<draft-ietf-bess-evpn-proxy-arp-nd-00.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 'unicastforward' 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 proxyARP/ND function may be implemented to help IXPs and other operators
deal with the issues derived from Address Resolution in large
broadcast domains.
"A new Designated Forwarder Election for the EVPN", satyamoh@cisco.com,
Keyur Patel, Ali Sajassi, John Drake, A. Przygienda, 2016-04-06,
<draft-ietf-bess-evpn-df-election-00.txt>
This document describes an improved EVPN Designated Forwarder
Election (DF) algorithm which can be used to enhance operational
experience in terms of convergence speed and robustness over a WAN
deploying EVPN
"Service Chaining using Virtual Networks with BGP VPNs", Rex Fernando,
Stuart Mackie, Dhananjaya Rao, Bruno Rijsman, Maria Napierala, Thomas
Morin, 2016-04-14, <draft-ietf-bess-service-chaining-00.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.
Binary Floor Control Protocol Bis (bfcpbis)
-------------------------------------------"The Binary Floor Control Protocol (BFCP)", Gonzalo Camarillo, Keith
Drage, Tom Kristensen, Joerg Ott, Charles Eckel, 2015-11-13,
<draft-ietf-bfcpbis-rfc4582bis-16.txt>
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.
"Session Description Protocol (SDP) Format for Binary Floor Control
Protocol (BFCP) Streams", Gonzalo Camarillo, Tom Kristensen, Paul Jones,
2016-02-09, <draft-ietf-bfcpbis-rfc4583bis-13.txt>
This document specifies how to describe Binary Floor Control Protocol
(BFCP) streams in Session Description Protocol (SDP) descriptions.
User agents using the offer/answer model to establish BFCP streams
use this format in their offers and answers.
This document obsoletes RFC 4583. Changes from RFC 4583 are
summarized in Section 14.
"The WebSocket Protocol as a Transport for the Binary Floor Control
Protocol (BFCP)", Victor Pascual, Anton Roman, Stephane Cazeaux, Gonzalo
Salgueiro, Ram R, Sergio Murillo, 2016-05-03,
<draft-ietf-bfcpbis-bfcp-websocket-07.txt>
The WebSocket protocol enables two-way realtime communication between
clients and servers. This document specifies a new WebSocket subprotocol as a reliable transport mechanism between Binary Floor
Control Protocol (BFCP) entities to enable usage of BFCP in new
scenarios.
"Session Description Protocol (SDP) WebSocket Connection URI Attribute",
Ram R, Gonzalo Salgueiro, 2016-05-02,
<draft-ietf-bfcpbis-sdp-ws-uri-03.txt>
The WebSocket protocol enables bidirectional real-time communication
between clients and servers in web-based applications. This document
specifies extensions to Session Description Protocol (SDP) for
application protocols using WebSocket as a transport.
Bidirectional Forwarding Detection (bfd)
---------------------------------------"BFD for Multipoint Networks", Dave Katz, David Ward, Juniper Networks,

2016-04-18, <draft-ietf-bfd-multipoint-08.txt>
This document describes extensions to the Bidirectional Forwarding
Detection (BFD) protocol for its use in multipoint and multicast
networks. Comments on this draft should be directed to rtgbfd@ietf.org.
"BFD Management Information Base (MIB) extensions for MPLS and MPLS-TP
Networks", Sam Aldrin, Venkatesan Mahalingam, Kannan Sampath, Tom
Nadeau, 2015-12-01, <draft-ietf-bfd-mpls-mib-07.txt>
This draft defines a portion of the Management Information Base (MIB)
for use with network management protocols in the Internet community.
In particular, it extends the BFD Management Information Base and
describes the managed objects for modeling Bidirectional Forwarding
Detection (BFD) protocol for MPLS and MPLS-TP networks.
"Seamless Bidirectional Forwarding Detection (S-BFD) Use Cases", Sam
Aldrin, Carlos Pignataro, Greg Mirsky, Nagendra Kumar, 2016-05-06,
<draft-ietf-bfd-seamless-use-case-08.txt>
This document describes various use cases for a Seamless
Bidirectional Forwarding Detection (S-BFD), and provides requirements
such that protocol mechanisms allow for a simplified detection of
forwarding failures.
These use cases support S-BFD, as a simplified mechanism to use
Bidirectional Forwarding Detection (BFD) with large portions of
negotiation aspects eliminated, accelerating the establishment of a
BFD session. S-BFD benefits include quick provisioning as well as
improved control and flexibility to network nodes initiating the path
monitoring.
"Seamless Bidirectional Forwarding Detection (S-BFD)", Carlos Pignataro,
David Ward, Nobo Akiya, Manav Bhatia, Juniper Networks, 2016-05-06,
<draft-ietf-bfd-seamless-base-11.txt>
This document defines a simplified mechanism to use Bidirectional
Forwarding Detection (BFD) with large portions of negotiation aspects
eliminated, thus providing benefits such as quick provisioning as
well as improved control and flexibility to network nodes initiating
the path monitoring.
This document updates RFC5880.
"Seamless Bidirectional Forwarding Detection (S-BFD) for IPv4, IPv6 and
MPLS", Carlos Pignataro, David Ward, Nobo Akiya, 2016-05-06,
<draft-ietf-bfd-seamless-ip-06.txt>
This document defines procedures to use Seamless Bidirectional
Forwarding Detection (S-BFD) for IPv4, IPv6 and MPLS environments.
"BFD Multipoint Active Tails.", Dave Katz, David Ward, Juniper Networks,
2015-11-17, <draft-ietf-bfd-multipoint-active-tail-01.txt>
This document describes active tail extensions to the Bidirectional
Forwarding Detection (BFD) protocol for multipoint and multicast
networks. Comments on this draft should be directed to rtgbfd@ietf.org.

"Yang Data Model for Bidirectional Forwarding Detection (BFD)", Lianshu

Zheng, Reshad Rahman, Juniper Networks, Mahesh Jethanandani, Greg
Mirsky, 2016-02-19, <draft-ietf-bfd-yang-01.txt>
This document defines a YANG data model that can be used to configure
and manage Bidirectional Forwarding Detection (BFD).
"Optimizing BFD Authentication", Mahesh Jethanandani, Ashesh Mishra,
Ankur Saxena, Manav Bhatia, 2016-02-17,
<draft-ietf-bfd-optimizing-authentication-01.txt,.pdf>
This document describes an optimization to BFD Authentication as
described in Section 6.7 of BFD [RFC5880].
Bit Indexed Explicit Replication (bier)
--------------------------------------"Multicast using Bit Index Explicit Replication", IJsbrand Wijnands,
Eric Rosen, Andrew Dolganow, A. Przygienda, Sam Aldrin, 2016-01-19,
<draft-ietf-bier-architecture-03.txt>
This document specifies a new architecture for the forwarding of
multicast data packets. It provides optimal forwarding of multicast
packets through a "multicast domain". However, it does not require a
protocol for explicitly building multicast distribution trees, nor
does it require intermediate nodes to maintain any per-flow state.
This architecture is known as "Bit Index Explicit Replication"
(BIER). When a multicast data packet enters the domain, the ingress
router determines the set of egress routers to which the packet needs
to be sent. The ingress router then encapsulates the packet in a
BIER header. The BIER header contains a bitstring in which each bit
represents exactly one egress router in the domain; to forward the
packet to a given set of egress routers, the bits corresponding to
those routers are set in the BIER header. Elimination of the perflow state and the explicit tree-building protocols results in a
considerable simplification.
"OSPF Extensions for BIER", Peter Psenak, Nagendra Kumar, IJsbrand
Wijnands, Andrew Dolganow, A. Przygienda, Jeffrey Zhang, Sam Aldrin,
2016-03-21, <draft-ietf-bier-ospf-bier-extensions-02.txt>
Bit Index Explicit Replication (BIER) is an architecture that
provides multicast forwarding through a "BIER domain" without
requiring intermediate routers to maintain multicast related per-flow
state. Neither does BIER require an explicit tree-building protocol
for its operation. A multicast data packet enters a BIER domain at a
"Bit-Forwarding Ingress Router" (BFIR), and leaves the BIER domain at
one or more "Bit-Forwarding Egress Routers" (BFERs). The BFIR router
adds a BIER header to the packet. Such header contains a bit-string
in which each bit represents exactly one BFER to forward the packet
to. The set of BFERs to which the multicast packet needs to be
forwarded is expressed by the according set of bits switched on in
BIER packet header.
This document describes the OSPF protocol extension required for BIER
with MPLS encapsulation.
"Encapsulation for Bit Index Explicit Replication in MPLS Networks",
IJsbrand Wijnands, Eric Rosen, Andrew Dolganow, Jeff Tantsura, Sam
Aldrin, 2016-04-18, <draft-ietf-bier-mpls-encapsulation-04.txt>

Bit Index Explicit Replication (BIER) is an architecture that

provides optimal multicast forwarding through a "multicast domain",
without requiring intermediate routers to maintain any per-flow state
or to engage in an explicit tree-building protocol. When a multicast
data packet enters the domain, the ingress router determines the set
of egress routers to which the packet needs to be sent. The ingress
router then encapsulates the packet in a BIER header. The BIER
header contains a bitstring in which each bit represents exactly one
egress router in the domain; to forward the packet to a given set of
egress routers, the bits corresponding to those routers are set in
the BIER header. The details of the encapsulation depend on the type
of network used to realize the multicast domain. This document
specifies the BIER encapsulation to be used in an MPLS network.
"Multicast VPN Using BIER", Eric Rosen, Mahesh Sivakumar, Sam Aldrin,
Andrew Dolganow, A. Przygienda, 2015-12-28,
<draft-ietf-bier-mvpn-02.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.
"BIER Use Cases", Nagendra Kumar, Rajiv Asati, Mach Chen, Xiaohu Xu,
Andrew Dolganow, A. Przygienda, arkadiy.gulko@thomsonreuters.com, Dom
Robinson, Vishal Arya, Caitlin Bestler, 2016-01-26,
<draft-ietf-bier-use-cases-02.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 perflow 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.
"BIER support via ISIS", Les Ginsberg, A. Przygienda, Sam Aldrin,
Jeffrey Zhang, 2016-03-19, <draft-ietf-bier-isis-extensions-02.txt>
Specification of an ISIS extension to support BIER domains and subdomains.
"Operations, Administration and Maintenance (OAM) Requirements for Bit
Index Explicit Replication (BIER) Layer", Greg Mirsky, Erik Nordmark,
Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Lianshu Zheng, Mach Chen,

Nobo Akiya, Santosh Pallagatti, 2016-03-21,

<draft-ietf-bier-oam-requirements-01.txt>
This document describes a list of functional requirement toward
Operations, Administration and Maintenance (OAM) toolset in Bit Index
Explicit Replication (BIER) layer of a network.
"Bit Indexed Explicit Replication (BIER) Problem Statement", Greg
Shepherd, Andrew Dolganow, arkadiy.gulko@thomsonreuters.com, 2016-04-03,
<draft-ietf-bier-problem-statement-00.txt>
There is a need to simplify network operations for multicast
services. Current solutions require a tree-building control plane to
build and maintain end-to-end tree state per flow, impacting router
state capacity and network convergence times. Multi-point tree
building protocols are often considered complex to deploy and debug
and may include mechanics from legacy use-cases and/or assumptions
which no longer apply to the current use-cases. When multicast
services are transiting a provider network through an overlay, the
core network has a choice to either aggregate customer state into a
minimum set of core states resulting in flooding traffic to unwanted
network end-points, or to map per-customer, per-flow tree state
directly into the provider core state amplifying the network-wide
state problem.
Benchmarking Methodology (bmwg)
------------------------------"Considerations for Benchmarking Virtual Network Functions and Their
Infrastructure", Al Morton, 2016-03-21,
<draft-ietf-bmwg-virtual-net-02.txt>
Benchmarking Methodology Working Group has traditionally conducted
laboratory characterization of dedicated physical implementations of
internetworking functions. This memo investigates additional
considerations when network functions are virtualized and performed
in general purpose hardware.
See the new version history section for updates.
"Data Center Benchmarking Terminology", Lucien Avramov,
jhrapp@gmail.com, 2016-04-27,
<draft-ietf-bmwg-dcbench-terminology-05.txt>
The purpose of this informational document is to establish definitions,
discussion and measurement techniques for data center benchmarking.
Also, it is to introduce new terminologies applicable to data center
performance evaluations. The purpose of this document is not to define
the test methodology, but rather establish the important concepts when
one is interested in benchmarking network switches and routers in the
data center.
"Data Center Benchmarking Methodology", Lucien Avramov,
jhrapp@gmail.com, 2016-04-27,
<draft-ietf-bmwg-dcbench-methodology-02.txt>
The purpose of this informational document is to establish test and
evaluation methodology and measurement techniques for physical
network equipment in the data center.

"Benchmarking IPv6 Neighbor Cache Behavior", William Cerveny, Ron

Bonica, 2016-04-05, <draft-ietf-bmwg-ipv6-nd-02.txt>
This document is a benchmarking instantiation of RFC 6583:
"Operational Neighbor Discovery Problems" [RFC6583]. It describes a
general testing procedure and measurements that can be performed to
evaluate how the problems described in RFC 6583 may impact the
functionality or performance of intermediate nodes.
"Benchmarking Methodology for IPv6 Transition Technologies", Marius,
Gabor Lencse, 2016-03-16,
<draft-ietf-bmwg-ipv6-tran-tech-benchmarking-01.txt>
There are benchmarking methodologies addressing the performance of
network interconnect devices that are IPv4- or IPv6-capable, but the
IPv6 transition technologies are outside of their scope. This
document provides complementary guidelines for evaluating the
performance of IPv6 transition technologies. More specifically,
this document targets IPv6 transition technologies that employ
encapsulation or translation mechanisms, as dual-stack nodes can be
very well tested using the recommendations of RFC2544 and RFC5180.
The methodology also includes a tentative metric for benchmarking
load scalability.
"Terminology for Benchmarking SDN Controller Performance", Bhuvaneswaran
Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks,
2016-03-21, <draft-ietf-bmwg-sdn-controller-benchmark-term-01.txt>
This document defines terminology for benchmarking an SDN
controller's control plane performance. It extends the terminology
already defined in RFC 7426 for the purpose of benchmarking SDN
controllers. The terms provided in this document help to benchmark
SDN controller's performance independent of the controller's
supported protocols and/or network services. A mechanism for
benchmarking the performance of SDN controllers is defined in the
companion methodology document. These two documents provide a
standard mechanism to measure and evaluate the performance of
various controller implementations.
"Benchmarking Methodology for SDN Controller Performance", Bhuvaneswaran
Vengainathan, Anton Basil, Mark Tassinari, Vishwas Manral, Sarah Banks,
2016-03-21, <draft-ietf-bmwg-sdn-controller-benchmark-meth-01.txt>
This document defines the methodologies for benchmarking control
plane performance of SDN controllers. Terminology related to
benchmarking SDN controllers is described in the companion
terminology document. SDN controllers have been implemented with
many varying designs in order to achieve their intended network
functionality. Hence, the authors have taken the approach of
considering an SDN controller as a black box, defining the
methodology in a manner that is agnostic to protocols and network
services supported by controllers. The intent of this document is to
provide a standard mechanism to measure the performance of all
controller implementations.
Calendaring Extensions (calext)
------------------------------"Calendar Availability", Cyrus Daboo, Mike Douglass, 2015-11-23,
<draft-ietf-calext-availability-01.txt>

This document specifies a new iCalendar calendar component that

allows the publication of available and unavailable time periods
associated with a calendar user. This component can be used in
standard iCalendar free-busy lookups, including iTIP free-busy
requests, to generate repeating blocks of available or busy time with
exceptions as needed.
This document also defines extensions to CalDAV calendar-access and
calendar-auto-schedule which specify how this new calendar component
can be used when doing free-busy time evaluation in CalDAV.
Common Control and Measurement Plane (ccamp)
-------------------------------------------"Link Management Protocol Extensions for Grid Property Negotiation",
Qilei Wang, Guoying Zhang, Yao Li, Ramon Casellas, Yu Wang, 2016-03-21,
<draft-ietf-ccamp-grid-property-lmp-03.txt>
ITU-T [G.694.1] introduces the flexible-grid DWDM technique, which
provides a new tool that operators can implement to provide a higher
degree of network optimization than is possible with fixed-grid
systems. This document describes the extensions to the Link
Management Protocol (LMP) to negotiate link grid property between the
adjacent DWDM nodes before the link is brought up.
"GMPLS OSPF-TE Extensions in support of Flexi-grid DWDM networks", Xian
Zhang, zhenghaomian@huawei.com, Ramon Casellas, Oscar Gonzalez de Dios,
Daniele Ceccarelli, 2016-04-24,
<draft-ietf-ccamp-flexible-grid-ospf-ext-04.txt>
This memo describes the OSPF-TE extensions in support of GMPLS
control of networks that include devices that use the new flexible
optical grid.
"OSPF Routing Extension for Links with Variable Discrete Bandwidth", Hao
Long, Min Ye, Greg Mirsky, Alessandro D'Alessandro, Himanshu Shah,
2016-02-22, <draft-ietf-ccamp-ospf-availability-extension-04.txt>
A network may contain links with variable discrete bandwidth, e.g.,
copper, radio, etc. The bandwidth of such links may change
discretely in reaction to changing external environment.
Availability is typically used for describing such links during
network planning. This document introduces an optional ISCD
Availability sub-TLV in OSPF routing protocol. This extension can be
used for route computation in a network that contains links with
variable discrete bandwidth.
"Ethernet Traffic Parameters with Availability Information", Hao Long,
Min Ye, Greg Mirsky, Alessandro D'Alessandro, Himanshu Shah, 2016-02-22,
<draft-ietf-ccamp-rsvp-te-bandwidth-availability-04.txt>
A Packet switching network may contain links with variable bandwidth,
e.g., copper, radio, etc. The bandwidth of such links is sensitive
to external environment. Availability is typically used for
describing the link during network planning. This document
introduces an optional Availability TLV in Resource ReSerVation
Protocol -- Traffic Engineer (RSVP-TE) signaling. This extension can
be used to set up a label switching path (LSP) in a Packet Switched
Network (PSN) that contains links with discretely variable bandwidth.

"IANA Allocation Procedures for OTN Signal Type Subregistry of the GMPLS
Signaling Parameters Registry", Zafar Ali, Antonello Bonfanti, Matt
Hartley, Fatai Zhang, 2016-03-17,
<draft-ietf-ccamp-otn-signal-type-subregistry-05.txt>
IANA has defined an "OTN Signal Type" subregistry of the
"Generalized Multi-Protocol Label Switching (GMPLS) Signaling
Parameters" registry. This document updates the OTN Signal Type
subregistry specified in RFC 7139 to allow Specification Required
policies, as defined in RFC 5226.
"Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extension
for Additional Signal Types in G.709 OTN", Zafar Ali, Antonello
Bonfanti, Matt Hartley, Fatai Zhang, 2016-02-08,
<draft-ietf-ccamp-additional-signal-type-g709v3-03.txt>
RFC 4328 and RFC 7139 provide Resource ReserVation Protocol-Traffic
Engineering (RSVP-TE) signaling extensions to control the full set
of Optical Transport Network (OTN) features. However, these
specifications do not cover the additional Optical channel Data
Unit (ODU) containers defined in G.Sup43 (ODU1e, ODU3e1 and
ODU3e2). This document updates RFC 7139 to define new signal types
for these additional containers.
"A framework for Management and Control of DWDM optical interface
parameters", Ruediger Kunze, Gert Grammel, Dieter Beller, Gabriele
Galimberti, 2016-04-06, <draft-ietf-ccamp-dwdm-if-mng-ctrl-fwk-01.txt>
To ensure an efficient data transport, meeting the requirements
requested by today's IP-services the control and management of DWDM
interfaces is a precondition for enhanced multilayer networking and
for an further automation of network provisioning and operation.
This document describes use cases and requirements for the control
and management of optical interfaces parameters according to
different types of single channel DMDM interfaces. The focus is on
automating the network provisioning process irrespective on how it is
triggered i.e. by EMS, NMS or GMPLS. This document covers management
as well as control plane considerations in different management cases
of a single channel DWDM interface The purpose is to identify the
necessary information elements and processes to be used by control or
management systems for further processing.
"A Yang Data Model for WSON Optical Networks", Young Lee, Dhruv Dhody,
Xian Zhang, Aihua Guo, Victor Lopezalvarez, Daniel King, Bin-Yeong Yoon,
2016-04-05, <draft-ietf-ccamp-wson-yang-01.txt>
This document provides a YANG data model for the routing and
wavelength assignment (RWA) TE topology in wavelength switched
optical networks (WSONs).
Content Delivery Networks Interconnection (cdni)
-----------------------------------------------"CDN Interconnection Metadata", Ben Niven-Jenkins, Rob Murray, Matt
Caulfield, Kevin Ma, 2016-04-28, <draft-ietf-cdni-metadata-16.txt>
The Content Delivery Networks Interconnection (CDNI) metadata
interface enables interconnected Content Delivery Networks (CDNs) to
exchange content distribution metadata in order to enable content

acquisition and delivery. The CDNI metadata associated with a piece

of content provides a downstream CDN with sufficient information for
the downstream CDN to service content requests on behalf of an
upstream CDN. This document describes both a base set of CDNI
metadata and the protocol for exchanging that metadata.
"CDNI Logging Interface", Francois Le Faucheur, Gilles Bertrand, Iuniana
Oprescu, Roy Peterkofsky, 2016-04-07, <draft-ietf-cdni-logging-25.txt>
This memo specifies the Logging interface between a downstream CDN
(dCDN) and an upstream CDN (uCDN) that are interconnected as per the
CDN Interconnection (CDNI) framework. First, it describes a
reference model for CDNI logging. Then, it specifies the CDNI
Logging File format and the actual protocol for exchange of CDNI
Logging Files.
"CDNI Control Interface / Triggers", Rob Murray, Ben Niven-Jenkins,
2016-04-17, <draft-ietf-cdni-control-triggers-13.txt>
This document describes the part of the CDN Interconnection Control
Interface that allows a CDN to trigger activity in an interconnected
CDN that is configured to deliver content on its behalf. The
upstream CDN can use this mechanism to request that the downstream
CDN pre-positions metadata or content, or that it invalidates or
purges metadata or content. The upstream CDN can monitor the status
of activity that it has triggered in the downstream CDN.
"Request Routing Redirection interface for CDN Interconnection", Ben
Niven-Jenkins, Ray van Brandenburg, 2016-04-15,
<draft-ietf-cdni-redirection-18.txt>
The Request Routing Interface comprises (1) the asynchronous
advertisement of footprint and capabilities by a downstream Content
Delivery Network (CDN) that allows an upstream CDN to decide whether
to redirect particular user requests to that downstream CDN; and (2)
the synchronous operation of an upstream CDN requesting whether a
downstream CDN is prepared to accept a user request and of a
downstream CDN responding with how to actually redirect the user
request. This document describes an interface for the latter part,
i.e., the CDNI Request Routing Redirection interface.
"CDNI Request Routing: Footprint and Capabilities Semantics", Jan
Seedorf, Jon Peterson, Stefano Previdi, Ray van Brandenburg, Kevin Ma,
2016-04-28, <draft-ietf-cdni-footprint-capabilities-semantics-18.txt>
This document captures the semantics of the "Footprint and
Capabilities Advertisement" part of the CDNI Request Routing
interface, i.e., the desired meaning of "Footprint" and
"Capabilities" in the CDNI context, and what the "Footprint and
Capabilities Advertisement Interface (FCI)" offers within CDNI. The
document also provides guidelines for the CDNI FCI protocol. It
further defines a Base Advertisement Object, the necessary registries
for capabilities and footprints, and guidelines on how these
registries can be extended in the future.
"URI Signing for CDN Interconnection (CDNI)", Kent Leung, Francois Le
Faucheur, Ray van Brandenburg, Bill Downey, Michel Fisher, 2016-04-05,
<draft-ietf-cdni-uri-signing-07.txt>
This document describes how the concept of URI signing supports the

content access control requirements of CDNI and proposes a URI

signing scheme.
The proposed URI signing method specifies the information needed to
be included in the URI and the algorithm used to authorize and to
validate access requests for the content referenced by the URI. The
mechanism described can be used both in CDNI and single CDN
scenarios.
Crypto Forum (cfrg)
------------------"Hash-Based Signatures", David McGrew, Michael Curcio, 2016-03-21,
<draft-mcgrew-hash-sigs-04.txt>
This note describes a digital signature system based on cryptographic
hash functions, following the seminal work in this area of Lamport,
Diffie, Winternitz, and Merkle, as adapted by Leighton and Micali in
1995. It specifies a one-time signature scheme and a general
signature scheme. These systems provide asymmetric authentication
without using large integer mathematics and can achieve a high
security level. They are suitable for compact implementations, are
relatively simple to implement, and naturally resist side-channel
attacks. Unlike most other signature systems, hash-based signatures
would still be secure even if it proves feasible for an attacker to
build a quantum computer.
"Augmented Password-Authenticated Key Exchange (AugPAKE)", SeongHan
Shin, Kazukuni Kobara, 2016-01-21, <draft-irtf-cfrg-augpake-05.txt>
This document describes a secure and highly-efficient augmented
password-authenticated key exchange (AugPAKE) protocol where a user
remembers a low-entropy password and its verifier is registered in
the intended server. In general, the user password is chosen from a
small set of dictionary whose space is within the off-line dictionary
attacks. The AugPAKE protocol described here is secure against
passive attacks, active attacks and off-line dictionary attacks (on
the obtained messages with passive/active attacks). Also, this
protocol provides resistance to server compromise in the context that
an attacker, who obtained the password verifier from the server, must
at least perform off-line dictionary attacks to gain any advantage in
impersonating the user. The AugPAKE protocol is not only provably
secure in the random oracle model but also the most efficient over
the previous augmented PAKE protocols (SRP and AMP).
"SPAKE2, a PAKE", Watson Ladd, 2016-02-15,
<draft-irtf-cfrg-spake2-03.txt>
This Internet-Draft describes SPAKE2, a secure, efficient password
based key exchange protocol.
"XMSS: Extended Hash-Based Signatures", Andreas Huelsing, Denis Butin,
Stefan-Lukas Gazdag, Aziz Mohaisen, 2016-02-15,
<draft-irtf-cfrg-xmss-hash-based-signatures-03.txt,.pdf>
This note describes the eXtended Merkle Signature Scheme (XMSS), a
hash-based digital signature system. It follows existing
descriptions in scientific literature. The note specifies the WOTS+
one-time signature scheme, a single-tree (XMSS) and a multi-tree
variant (XMSS^MT) of XMSS. Both variants use WOTS+ as a main

building block. XMSS provides cryptographic digital signatures

without relying on the conjectured hardness of mathematical problems.
Instead, it is proven that it only relies on the properties of
cryptographic hash functions. XMSS provides strong security
guarantees and, besides some special instantiations, is even secure
when the collision resistance of the underlying hash function is
broken. It is suitable for compact implementations, relatively
simple to implement, and naturally resists side-channel attacks.
Unlike most other signature systems, hash-based signatures withstand
attacks using quantum computers.
"Requirements for PAKE schemes", Joern-Marc Schmidt, 2016-05-03,
<draft-irtf-cfrg-pake-reqs-03.txt>
Password-Authenticated Key Agreement (PAKE) schemes are interactive
protocols that allow the participants to authenticate each other and
derive shared cryptographic keys using a (weaker) shared password.
This document reviews different types of PAKE schemes and discusses
their requirements.
"Edwards-curve Digital Signature Algorithm (EdDSA)", Simon Josefsson,
Ilari Liusvaara, 2016-03-21, <draft-irtf-cfrg-eddsa-05.txt>
The elliptic curve signature scheme Edwards-curve Digital Signature
Algorithm (EdDSA) is described. The algorithm is instantiated with
recommended parameters for the edwards25519 and edwards448 curves.
An example implementation and test vectors are provided.
"Security Guidelines for Cryptographic Algorithms in the W3C Web
Cryptography API", Harry Halpin, Graham Steel, 2015-11-17,
<draft-irtf-cfrg-webcrypto-algorithms-00.txt>
This overview document provides information on the current state of
algorithms made available by the W3C Web Cryptography API, including
whether protocols have security proofs or known weaknesses.
"The memory-hard Argon2 password hash and proof-of-work function", Alex
Biryukov, Daniel Dinu, Dmitry Khovratovich, Simon Josefsson, 2016-03-21,
<draft-irtf-cfrg-argon2-00.txt>
This document describes the Argon2 memory-hard function for password
hashing and proof-of-work applications. We provide an implementer
oriented description together with sample code and test vectors. The
purpose is to simplify adoption of Argon2 for Internet protocols.
"AES-GCM-SIV: Nonce Misuse-Resistant Authenticated Encryption", Shay
Gueron, Adam Langley, Yehuda Lindell, 2016-04-19,
<draft-irtf-cfrg-gcmsiv-00.txt>
This memo specifies two authenticated encryption algorithms that are
nonce misuse-resistant - that is that they do not fail
catastrophically if a nonce is repeated.
ControLling mUltiple streams for tElepresence (clue)
---------------------------------------------------"Framework for Telepresence Multi-Streams", Mark Duckworth, Andrew
Pepperell, Stephan Wenger, 2016-01-08,
<draft-ietf-clue-framework-25.txt>

This document defines a framework for a protocol to enable devices

in a telepresence conference to interoperate. The protocol enables
communication of information about multiple media streams so a
sending system and receiving system can make reasonable decisions
about transmitting, selecting and rendering the media streams.
This protocol is used in addition to SIP signaling and SDP
negotiation for setting up a telepresence session.
"Mapping RTP streams to CLUE media captures", Roni Even, Jonathan
Lennox, 2016-01-17, <draft-ietf-clue-rtp-mapping-06.txt,.pdf>
This document describes how the Real Time transport Protocol (RTP) is
used in the context of the CLUE protocol. It also describes the
mechanisms and recommended practice for mapping RTP media streams
defined in SDP to CLUE media captures.
"An XML Schema for the CLUE data model", Roberta Presta, Simon Romano,
2016-05-06, <draft-ietf-clue-data-model-schema-14.txt>
This document provides an XML schema file for the definition of CLUE
data model types.
"CLUE Protocol data channel", Christer Holmberg, 2016-03-17,
<draft-ietf-clue-datachannel-12.txt>
This document defines how to use the WebRTC data channel mechanism in
order to realize a data channel, referred to as a CLUE data channel,
for transporting CLUE protocol messages between two CLUE entities.
The document defines how to describe the SCTPoDTLS association used
to realize the CLUE data channel using the Session Description
Protocol (SDP), and defines usage of SDP-based "SCTP over DTLS" data
channel negotiation mechanism for establishing a CLUE data channel.
Details and procedures associated with the CLUE protocol, and the SDP
Offer/Answer procedures for negotiating usage of a CLUE data channel,
are outside the scope of this document.
"CLUE Signaling", Paul Kyzivat, Lennard Xiao, Christian Groves, Robert
Hansen, 2016-03-21, <draft-ietf-clue-signaling-09.txt>
This document specifies how CLUE-specific
protocol [I-D.ietf-clue-protocol] and the
[I-D.ietf-clue-datachannel] are used with
existing signaling mechanisms such as SIP
telepresence call.

signaling such as the CLUE

CLUE data channel
each other and with
and SDP to produce a

"CLUE protocol", Roberta Presta, Simon Romano, 2016-03-21,

<draft-ietf-clue-protocol-07.txt>
The CLUE protocol is an application protocol conceived for the
description and negotiation of a CLUE telepresence session. The
design of the CLUE protocol takes into account the requirements and
the framework defined, respectively, in [I-D.ietf-clue-framework] and
[RFC7262]. The companion document [I-D.ietf-clue-signaling] delves
into CLUE signaling details, as well as on the SIP/SDP session
establishment phase. CLUE messages flow upon the CLUE data channel,
based on reliable and ordered SCTP over DTLS transport, as described
in [I-D.ietf-clue-datachannel]. Message details, together with the
behavior of CLUE Participants acting as Media Providers and/or Media

Consumers, are herein discussed.

Congestion Exposure (conex)
--------------------------"IPv6 Destination Option for Congestion Exposure (ConEx)", Suresh
Krishnan, Mirja Khlewind, Bob Briscoe, Carlos Ucendo, 2016-01-17,
<draft-ietf-conex-destopt-12.txt>
Congestion Exposure (ConEx) is a mechanism by which senders inform
the network about the congestion encountered by packets earlier in
the same flow. This document specifies an IPv6 destination option
that is capable of carrying ConEx markings in IPv6 datagrams.
"TCP modifications for Congestion Exposure", Mirja Khlewind, Richard
Scheffenegger, 2015-10-13, <draft-ietf-conex-tcp-modifications-10.txt>
Congestion Exposure (ConEx) is a mechanism by which senders inform
the network about expected congestion based on congestion feedback
from previous packets in the same flow. This document describes the
necessary modifications to use ConEx with the Transmission Control
Protocol (TCP).
Constrained RESTful Environments (core)
--------------------------------------"Block-wise transfers in CoAP", Carsten Bormann, Zach Shelby,
2016-04-29, <draft-ietf-core-block-20.txt>
CoAP is a RESTful transfer protocol for constrained nodes and
networks. Basic CoAP messages work well for the small payloads we
expect from temperature sensors, light switches, and similar
building-automation devices. Occasionally, however, applications
will need to transfer larger payloads -- for instance, for firmware
updates. With HTTP, TCP does the grunt work of slicing large
payloads up into multiple packets and ensuring that they all arrive
and are handled in the right order.
CoAP is based on datagram transports such as UDP or DTLS, which
limits the maximum size of resource representations that can be
transferred without too much fragmentation. Although UDP supports
larger payloads through IP fragmentation, it is limited to 64 KiB
and, more importantly, doesn't really work well for constrained
applications and networks.
Instead of relying on IP fragmentation, this specification extends
basic CoAP with a pair of "Block" options, for transferring multiple
blocks of information from a resource representation in multiple
request-response pairs. In many important cases, the Block options
enable a server to be truly stateless: the server can handle each
block transfer separately, with no need for a connection setup or
other server-side memory of previous block transfers.
In summary, the Block options provide a minimal way to transfer
larger representations in a block-wise fashion.
"Representing CoRE Formats in JSON and CBOR", Kepeng Li, Akbar Rahman,
Carsten Bormann, 2016-04-27, <draft-ietf-core-links-json-05.txt>
JavaScript Object Notation, JSON (RFC7159) is a text-based data

format which is popular for Web based data exchange. Concise Binary
Object Representation, CBOR (RFC7049) is a binary data format which
has been optimized for data exchange for the Internet of Things
(IoT). For many IoT scenarios, CBOR formats will be preferred since
it can help decrease transmission payload sizes as well as
implementation code sizes compared to other data formats.
Web Linking (RFC5988) provides a way to represent links between Web
resources as well as the relations expressed by them and attributes
of such a link. In constrained networks, a collection of Web links
can be exchanged in the CoRE link format (RFC6690). Outside of
constrained environments, it may be useful to represent these
collections of Web links in JSON, and similarly, inside constrained
environments, in CBOR. This specification defines a common format
for this.
Group Communication for the Constrained Application Protocol
(RFC7390) defines a number of JSON formats for controlling
communication between groups of nodes employing the Constrained
Application Protocol (CoAP). In a similar vein, this specification
defines CBOR variants of these formats.
"CoRE Resource Directory", Zach Shelby, Michael Koster, Carsten Bormann,
Peter Van der Stok, 2016-03-21,
<draft-ietf-core-resource-directory-07.txt>
In many M2M applications, direct discovery of resources is not
practical due to sleeping nodes, disperse networks, or networks where
multicast traffic is inefficient. These problems can be solved by
employing an entity called a Resource Directory (RD), which hosts
descriptions of resources held on other servers, allowing lookups to
be performed for those resources. This document specifies the web
interfaces that a Resource Directory supports in order for web
servers to discover the RD and to register, maintain, lookup and
remove resources descriptions. Furthermore, new link attributes
useful in conjunction with an RD are defined.
"Guidelines for HTTP-CoAP Mapping Implementations", Angelo Castellani,
Salvatore Loreto, Akbar Rahman, Thomas Fossati, Esko Dijk, 2016-04-06,
<draft-ietf-core-http-mapping-09.txt>
This document provides reference information for implementing a proxy
that performs translation between the HTTP protocol and the CoAP
protocol, focusing on the reverse proxy case. It describes how a
HTTP request is mapped to a CoAP request and how a CoAP response is
mapped back to a HTTP response. Furthermore, it defines a template
for URI mapping and provides a set of guidelines for HTTP to CoAP
protocol translation and related proxy implementations.
"A TCP and TLS Transport for the Constrained Application Protocol
(CoAP)", Carsten Bormann, Simon Lemay, Zebra Technologies, Hannes
Tschofenig, 2016-04-21, <draft-ietf-core-coap-tcp-tls-02.txt>
The Hypertext Transfer Protocol (HTTP) was designed with TCP as the
underlying transport protocol. The Constrained Application Protocol
(CoAP), while inspired by HTTP, has been defined to make use of UDP
instead of TCP. Therefore, reliable delivery and a simple congestion
control and flow control mechanism are provided by the message layer
of the CoAP protocol.

A number of environments benefit from the use of CoAP directly over a

reliable byte stream such as TCP, which already provides these
services. This document defines the use of CoAP over TCP as well as
CoAP over TLS.
"Media Types for Sensor Markup Language (SenML)", Cullen Jennings, Zach
Shelby, Jari Arkko, Ari Keranen, 2016-04-19,
<draft-ietf-core-senml-00.txt>
This specification defines media types for representing simple sensor
measurements and device parameters in the Sensor Markup Language
(SenML). Representations are defined in JavaScript Object Notation
(JSON), Concise Binary Object Representation (CBOR), eXtensible
Markup Language (XML), and Efficient XML Interchange (EXI), which
share the common SenML data model. A simple sensor, such as a
temperature sensor, could use this media type in protocols such as
HTTP or CoAP to transport the measurements of the sensor or to be
configured.
"CBOR Encoding of Data Modeled with YANG", Michel Veillette, Alexander
Pelov, Abhinav Somaraju, Randy Turner, Ana Minaburo, 2016-04-30,
<draft-ietf-core-yang-cbor-00.txt>
This document defines encoding rules for serializing configuration
data, state data, RPC input and RPC output, Action input, Action
output and notifications defined within YANG modules using the
Concise Binary Object Representation (CBOR) [RFC7049].
CBOR Object Signing and Encryption (cose)
----------------------------------------"CBOR Encoded Message Syntax", Jim Schaad, 2016-03-21,
<draft-ietf-cose-msg-11.txt>
Concise Binary Object Representation (CBOR) is data format designed
for small code size and small message size. There is a need for the
ability to have the basic security services defined for this data
format. This document specifies processing for signatures, message
authentication codes, and encryption using CBOR. This document also
specifies a representation for cryptographic keys using CBOR.
CURves, Deprecating and a Little more Encryption (curdle)
--------------------------------------------------------"Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448",
Aris Adamantiadis, Simon Josefsson, 2016-03-08,
<draft-ietf-curdle-ssh-curves-00.txt>
How to implement the Curve25519 and Curve448 key exchange methods in
the Secure Shell (SSH) protocol is described.
"Key Exchange (KEX) Method Updates and Recommendations for Secure Shell
(SSH)", Mark Baushke, 2016-03-14,
<draft-ietf-curdle-ssh-kex-sha2-03.txt>
This document adds recommendations for adoption of ssh-curves from
the [I-D.ietf-curdle-ssh-curves], adds some new Modular Exponential
(MODP) Groups, and deprecates some previously specified Key Exchange
Method algorithm names for the Secure Shell (SSH) protocol. It also
updates [RFC4253], [RFC4419], [RFC4462], and [RFC5656] by specifying

the set key exchange algorithms that currently exist and which ones
MUST, SHOULD, MAY, and SHOULD NOT be implemented. New key exchange
methods use the SHA-2 family of hashes.
"Use of RSA Keys with SHA-2 256 and 512 in Secure Shell (SSH)", denis
bider, 2016-03-10, <draft-ietf-curdle-rsa-sha2-00.txt>
This memo defines an algorithm name, public key format, and signature
format for use of RSA keys with SHA-2 512 for server and client
authentication in SSH connections.
"Extension Negotiation in Secure Shell (SSH)", denis bider, 2016-03-10,
<draft-ietf-curdle-ssh-ext-info-00.txt>
This memo defines a mechanism for SSH clients and servers to exchange
information about supported protocol extensions confidentially after
completed key exchange.
"Using EdDSA with Ed25519/Ed448 in the Internet X.509 Public Key
Infrastructure", Simon Josefsson, Nikos Mavrogiannopoulos, 2016-03-20,
<draft-ietf-curdle-pkix-eddsa-00.txt>
This document specify algorithm identifiers and ASN.1 encoding
formats for EdDSA digital signatures and subject public keys used in
the Internet X.509 Public Key Infrastructure (PKIX) for Certificates
and CRLs. Parameters for Ed25519, Ed25519ph, Ed448, and Ed448ph are
defined.
"Using Curve25519 and Curve448 in PKIX", Simon Josefsson, 2016-03-20,
<draft-ietf-curdle-pkix-newcurves-00.txt>
This document specify "named curve" object identifiers for the
Curve25519 and Curve448 curves, for use in various X.509 PKIX
structures.
"EdDSA, Ed25519, Ed448, Curve25519 and Curve448 for X.509", Simon
Josefsson, 2016-04-08, <draft-ietf-curdle-pkix-00.txt>
This document specify algorithm identifiers and ASN.1 encoding
formats for EdDSA digital signatures, subject public keys, and a
"named curve" object identifier, used in the Internet X.509 Public
Key Infrastructure. Parameters for Ed25519, Ed25519ph, Ed448,
Ed448ph, Curve25519 and Curve448 are defined.
"EdDSA for DNSSEC", Ond ej Sur, Robert Edmonds, 2016-04-18,
<draft-ietf-curdle-dnskey-eddsa-00.txt>
This document describes how to specify EdDSA keys and signatures in
DNS Security (DNSSEC). It uses the Edwards-curve Digital Security
Algorithm (EdDSA) with the choice of two curves, Ed25519 and Ed448.
"Ed25519 public key algorithm for the Secure Shell (SSH) protocol", Ben
Harris, 2016-05-04, <draft-ietf-curdle-ssh-ed25519-00.txt>
This document describes the use of the Ed25519 digital signature
algorithm in the Secure Shell (SSH) protocol.
"Using ChaCha20-Poly1305 Authenticated Encryption in the Cryptographic
Message Syntax (CMS)", Russ Housley, 2016-05-04,
<draft-ietf-curdle-cms-chacha20-poly1305-00.txt>

This document describes the conventions for using ChaCha20-Poly1305

Authenticated Encryption in the Cryptographic Message Syntax (CMS).
ChaCha20-Poly1305 is a construction of the ChaCha stream cipher and
Poly1305 authenticator.
"Use of the Elliptic Curve Diffie-Hellamn Key Agreement Algorithm with
curve25519 and curve448 in the Cryptographic Message Syntax (CMS)", Russ
Housley, 2016-05-05, <draft-ietf-curdle-cms-ecdh-new-curves-00.txt>
This document describes the conventions for using Elliptic Curve
Diffie-Hellamn (ECDH) key agreement algorithm using curve25519 and
curve448 in the Cryptographic Message Syntax (CMS).
DNS-based Authentication of Named Entities (dane)
------------------------------------------------"Using Secure DNS to Associate Certificates with Domain Names For
S/MIME", Paul Hoffman, Jakob Schlyter, 2016-02-24,
<draft-ietf-dane-smime-10.txt>
This document describes how to use secure DNS to associate an S/MIME
user's certificate with the intended domain name, similar to the way
that DANE (RFC 6698) does for TLS.
"Using DANE to Associate OpenPGP public keys with email addresses", Paul
Wouters, 2016-05-02, <draft-ietf-dane-openpgpkey-12.txt>
OpenPGP is a message format for email (and file) encryption that
lacks a standardized lookup mechanism to securely obtain OpenPGP
public keys. DNS-Based Authentication of Named Entities ("DANE") is
a method for publishing public keys in DNS. This document specifies
a DANE method for publishing and locating OpenPGP public keys in DNS
for a specific email address using a new OPENPGPKEY DNS Resource
Record. Security is provided via Secure DNS, however the OPENPGPKEY
record is not a replacement for verification of authenticity via the
"Web Of Trust" or manual verification. The OPENPGPKEY record can be
used to encrypt an email that would otherwise have to be sent
unencrypted.
Deterministic Networking (detnet)
--------------------------------"Deterministic Networking Use Cases", Ethan Grossman, Craig Gunther,
Pascal Thubert, Patrick Wetterwald, Jean Raymond, Jouni Korhonen, Yu
Kaneko, Subir Das, Yiyong Zha, Balazs Varga, Janos Farkas, Franz-Josef
Goetz, Jrgen Schmitt, 2016-03-21, <draft-ietf-detnet-use-cases-09.txt>
This draft documents requirements in several diverse industries to
establish multi-hop paths for characterized flows with deterministic
properties. In this context deterministic implies that streams can
be established which provide guaranteed bandwidth and latency which
can be established from either a Layer 2 or Layer 3 (IP) interface,
and which can co-exist on an IP network with best-effort traffic.
Additional requirements include optional redundant paths, very high
reliability paths, time synchronization, and clock distribution.
Industries considered include wireless for industrial applications,
professional audio, electrical utilities, building automation
systems, radio/mobile access networks, automotive, and gaming.

For each case, this document will identify the application, identify
representative solutions used today, and what new uses an IETF DetNet
solution may enable.
"Deterministic Networking Problem Statement", Norman Finn, Pascal
Thubert, 2016-04-05, <draft-ietf-detnet-problem-statement-00.txt>
This paper documents the needs in various industries to establish
multi-hop paths for characterized flows with deterministic properties
.
Dynamic Host Configuration (dhc)
-------------------------------"Access Network Identifier Option in DHCP", Shwetha Bhandari, Sri
Gundavelli, Mark Grayson, Bernie Volz, Jouni Korhonen, 2016-02-01,
<draft-ietf-dhc-access-network-identifier-13.txt>
This document specifies the format and mechanism that is to be used
for encoding access network identifiers in DHCPv4 and DHCPv6 messages
by defining new access network identifier options and sub-options.
"Customizing DHCP Configuration on the Basis of Network Topology", Ted
Lemon, Tomek Mrugalski, 2016-05-06, <draft-ietf-dhc-topo-conf-08.txt>
DHCP servers have evolved over the years to provide significant
functionality beyond that which is described in the DHCP base
specifications. One aspect of this functionality is support for
context-specific configuration information. This memo describes some
such features and explains their operation.
"Secure DHCPv6", Sheng Jiang, Lishan Li, Yong Cui, Tatuya Jinmei, Ted
Lemon, Dacheng Zhang, 2016-04-24, <draft-ietf-dhc-sedhcpv6-12.txt>
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) enables
DHCPv6 servers to pass configuration parameters. It offers
configuration flexibility. If not secured, DHCPv6 is vulnerable to
various attacks. This document analyzes the security issues of
DHCPv6 and specifies the secure DHCPv6 mechanism for authentication
and encryption of messages between a DHCPv6 client and a DHCPv6
server.
"Privacy considerations for DHCPv6", Suresh Krishnan, Tomek Mrugalski,
Sheng Jiang, 2016-02-24, <draft-ietf-dhc-dhcpv6-privacy-05.txt>
DHCPv6 is a protocol that is used to provide addressing
configuration information to IPv6 hosts. This document
privacy issues associated with the use of DHCPv6 by the
users. It is intended to be an analysis of the present
does not propose any solutions.

and
describes the
Internet
situation and

"Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Tomek

Mrugalski, Marcin Siodelski, Bernie Volz, Andrew Yourtchenko, Michael
Richardson, Sheng Jiang, Ted Lemon, 2016-03-21,
<draft-ietf-dhc-rfc3315bis-04.txt>
This document describes the Dynamic Host Configuration Protocol for
IPv6 (DHCPv6): an extensible mechanism for configuring hosts with
network configuration parameters, IP addresses, and prefixes.

Parameters can be provided statelessly, or in combination with

stateful assignment of one or more IPv6 addresses and/or IPv6
prefixes. DHCPv6 can operate either in place of or in addition to
stateless address autoconfiguration (SLAAC).
This document updates the text from RFC 3315, the original DHCPv6
specification, and incorporates the stateless DHCPv6 extensions (RFC
3736) and prefix delegation (RFC 3633), clarifying the interactions
between these modes of operation (RFC 7550) and providing a mechanism
for throttling DHCPv6 clients when DHCPv6 service is not available
(RFC 7083). As such, this document obsoletes RFC3315, RFC3633,
RFC3736, RFC7083, RFC7550.
"Anonymity profile for DHCP clients", Christian Huitema, Tomek
Mrugalski, Suresh Krishnan, 2016-02-19,
<draft-ietf-dhc-anonymity-profile-08.txt>
Some DHCP options carry unique identifiers. These identifiers can
enable device tracking even if the device administrator takes care of
randomizing other potential identifications like link-layer addresses
or IPv6 addresses. The anonymity profile is designed for clients
that wish to remain anonymous to the visited network. The profile
provides guidelines on the composition of DHCP or DHCPv6 requests,
designed to minimize disclosure of identifying information.
"Forcerenew Reconfiguration Extensions for DHCPv4", Luyuan Fang, Deepak
Bansal, Fabio Chiussi, 2016-03-21,
<draft-fang-dhc-dhcpv4-forcerenew-extensions-02.txt>
This document extends the definition of the DHCPFORCERENEW message
for parameter reconfiguration in DHCPv4. This extension makes the
DHCPFORCERENEW message more suitable to reconfigure configuration
parameters other than IP addresses, and aligns the behavior of the
reconfiguration procedure in DHCPv4 to the corresponding behavior in
DHCPv6.
"secure DHCPv6 deployment", Lishan Li, Yong Cui, Jianping Wu, Sheng
Jiang, 2016-03-06, <draft-li-dhc-secure-dhcpv6-deployment-03.txt>
Secure DHCPv6 provides authentication and encryption mechanisms for
DHCPv6. This draft analyses DHCPv6 threat model and provides
guideline for secure DHCPv6 deployment.
"YANG Data Model for DHCPv6 Configuration", Yong Cui, Hao Wang, Linhui
Sun, Ted Lemon, Ian Farrer, Sladjana Zoric, 2016-03-21,
<draft-ietf-dhc-dhcpv6-yang-01.txt>
This document describes a YANG data model [RFC6020] for the
configuration and management of DHCPv6 servers, relays and clients.
"DHCPv6 Failover Protocol", Tomek Mrugalski, Kim Kinnear, 2015-12-24,
<draft-ietf-dhc-dhcpv6-failover-protocol-01.txt>
DHCPv6 as defined in "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)" (RFC3315) does not offer server redundancy. This document
defines a protocol implementation to provide for DHCPv6 failover, a
mechanism for running two servers on the same network with the
capability for either server to take over clients' leases in case of
server failure or network partition. It meets the requirements for
DHCPv6 failover detailed in "DHCPv6 Failover Requirements" (RFC7031).

"DHCPv6 Prefix Length Hint Issues", Yong Cui, Tianxiang Li, Cong Liu,
2016-04-28, <draft-ietf-dhc-dhcpv6-prefix-length-hint-issue-01.txt>
DHCPv6 Prefix Delegation [RFC3633] allows a requesting router to
include a prefix-length hint value in the IA_PD option to indicate a
preference for the size of the prefix to be delegated, but is unclear
about how the requesting router and delegating router should act in
different situations involving the prefix-length hint. This document
provides a summary of the existing problems with the prefix-length
hint and guidance on what the requesting router and delegating router
could do in different situations.
DTLS In Constrained Environments (dice)
--------------------------------------"TLS/DTLS Profiles for the Internet of Things", Hannes Tschofenig,
Thomas Fossati, 2015-10-18, <draft-ietf-dice-profile-17.txt>
A common design pattern in Internet of Things (IoT) deployments is
the use of a constrained device that collects data via sensors or
controls actuators for use in home automation, industrial control
systems, smart cities and other IoT deployments.
This document defines a Transport Layer Security (TLS) and Datagram
TLS (DTLS) 1.2 profile that offers communications security for this
data exchange thereby preventing eavesdropping, tampering, and
message forgery. The lack of communication security is a common
vulnerability in Internet of Things products that can easily be
solved by using these well-researched and widely deployed Internet
security protocols.
Diameter Maintenance and Extensions (dime)
-----------------------------------------"Diameter Group Signaling", Mark Jones, Marco Liebsch, Lionel Morand,
2016-03-21, <draft-ietf-dime-group-signaling-06.txt>
In large network deployments, a single Diameter node can support over
a million concurrent Diameter sessions. Recent use cases have
revealed the need for Diameter nodes to apply the same operation to a
large group of Diameter sessions concurrently. The Diameter base
protocol commands operate on a single session so these use cases
could result in many thousands of command exchanges to enforce the
same operation on each session in the group. In order to reduce
signaling, it would be desirable to enable bulk operations on all (or
part of) the sessions managed by a Diameter node using a single or a
few command exchanges. This document specifies the Diameter protocol
extensions to achieve this signaling optimization.
"Diameter AVP Level Security End-to-End Security: Scenarios and
Requirements", Hannes Tschofenig, Jouni Korhonen, Glen Zorn, Kervin
Pillay, 2016-01-13, <draft-ietf-dime-e2e-sec-req-04.txt>
This specification discusses requirements for providing Diameter
security at the level of individual Attribute-Value Pairs.
"Diameter Overload Rate Control", Steve Donovan, Eric Noel, 2016-03-18,
<draft-ietf-dime-doic-rate-control-03.txt>

This specification documents an extension to the Diameter Overload

Indication Conveyance (DOIC) [RFC7683] base solution. This extension
adds a new overload control abatement algorithm. This abatement
algorithm allows for a DOIC reporting node to specify a maximum rate
at which a DOIC reacting node sends Diameter requests to the DOIC
reporting node.
Requirements
"Diameter Agent Overload and the Peer Overload Report", Steve Donovan,
2016-03-18, <draft-ietf-dime-agent-overload-04.txt>
This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) [RFC7683] base solution. The extension
defines the Peer overload report type. The initial use case for the
Peer report is the handling of occurrences of overload of a Diameter
agent.
Requirements
"Diameter Load Information Conveyance", Ben Campbell, Steve Donovan,
Jean-Jacques Trottin, 2016-03-18, <draft-ietf-dime-load-02.txt>
This document defines a mechanism for sharing of Diameter load
information. [RFC7068] describes requirements for Overload Control
in Diameter. This includes a requirement to allow Diameter nodes to
send "load" information, even when the node is not overloaded. The
Diameter Overload Information Conveyance (DOIC) [RFC7683] solution
describes a mechanism meeting most of the requirements, but does not
currently include the ability to send load information.
"Diameter Routing Message Priority", Steve Donovan, 2016-04-05,
<draft-ietf-dime-drmp-05.txt>
When making routing and resource allocation decisions, Diameter nodes
currently have no generic mechanism to determine the relative
priority of Diameter messages. This document addresses this by
defining a mechanism to allow Diameter endpoints to indicate the
relative priority of Diameter transactions. With this information
Diameter nodes can factor that priority into routing, resource
allocation and overload abatement decisions.
Domain-based Message Authentication, Reporting & Conformance (dmarc)
-------------------------------------------------------------------"Interoperability Issues Between DMARC and Indirect Email Flows", Franck
Martin, Eliot Lear, Tim Draegen, Elizabeth Zwicky, Kurt Andersen,
2016-01-18, <draft-ietf-dmarc-interoperability-14.txt>
DMARC introduces a mechanism for expressing domain-level policies and
preferences for email message validation, disposition, and reporting.
The DMARC mechanism can encounter interoperability issues when
messages do not flow directly from the author's administrative domain
to the final recipients. Collectively these email flows are referred
to as indirect email flows. This document describes interoperability
issues between DMARC and indirect email flows. Possible methods for
addressing interoperability issues are presented.
Distributed Mobility Management (dmm)
-------------------------------------

"On Demand Mobility Management", Alper Yegin, Kisuk Kweon, Jinsung Lee,
Jungshin Park, Danny Moses, 2016-05-03,
<draft-ietf-dmm-ondemand-mobility-03.txt>
Applications differ with respect to whether they need IP session
continuity and/or IP address reachability. The network providing the
same type of service to any mobile host and any application running
on the host yields inefficiencies. This document describes a
solution for taking the application needs into account in selectively
providing IP session continuity and IP address reachability on a persocket basis.
"Protocol for Forwarding Policy Configuration (FPC) in DMM", Marco
Liebsch, Satoru Matsushima, Sri Gundavelli, Danny Moses, Lyle Bertz,
2016-03-21, <draft-ietf-dmm-fpc-cpdp-03.txt>
This specification supports the separation of the Control-Plane for
mobility- and session management from the Data-Plane. The protocol
semantics abstract the configuration of Data-Plane nodes and applies
it between a Client function, which is used by an application of the
mobility Control-Plane, and an Agent function, which is associated
with the configuration of Data-Plane nodes, according to the DataPlane rules issued by the mobility Control-Plane. The scope of the
rules comprises traffic description and treatment of packets in terms
of encapsulation, IP address re-writing and QoS. Additional protocol
semantics are described to support the maintenance of the Data-Plane
path.
"MAG Multipath Binding Option", Pierrick Seite, Alper Yegin, Sri
Gundavelli, 2016-03-02, <draft-ietf-dmm-mag-multihoming-01.txt>
The document [RFC4908] proposes to rely on multiple Care-of Addresses
(CoAs) capabilities of Mobile IP [RFC6275] an Network Mobility (NEMO;
[RFC3963]) to enable Multihoming technology for Small-Scale Fixed
Networks. In the continuation of [RFC4908], this document specifies
a multiple proxy Care-of Addresses (pCoAs) extension for Proxy Mobile
IPv6 [RFC5213]. This extension allows a multihomed Mobile Access
Gateway (MAG) to register more than one proxy care-of-address to the
Local Mobility Anchor (LMA).
"LMA Controlled MAG Session Parameters", Dhananjay Patki, Sri
Gundavelli, Jong-Hyouk Lee, Qiao Fu, Lyle Bertz, 2016-04-13,
<draft-ietf-dmm-lma-controlled-mag-params-01.txt>
This specification defines a new extension, LMA-Controlled-MAGSession-Params to Proxy Mobile IPv6. This option can be used by the
LMA in PMIPv6 signaling for notifying the MAG to conform to various
parameters contained in this extension.
"Home Network Prefix Renumbering in PMIPv6", Zhiwei Yan, Jong-Hyouk Lee,
XiaoDong Lee, 2015-12-16, <draft-ietf-dmm-hnprenum-00.txt>
In the basic Proxy Mobile IPv6 (PMIPv6) specification, a Mobile Node
(MN) is assigned with a 64-bit Home Network Prefix (HNP) during its
initial attachment for the Home Address (HoA) configuration. During
the movement of the MN, this prefix remains unchanged and in this way
it is unnecessary for the MN to reconfigure its HoA and reconnect the
ongoing communications. However, the current protocol (RFC5213) does
not specify related operations to support the MN to timely receive

and use a new HNP when the allocated HNP changes. In this draft, a
solution to support the HNP renumbering is proposed, as an update of
RFC5213.
Domain Name System Operations (dnsop)
------------------------------------"Initializing a DNS Resolver with Priming Queries", Peter Koch, M.
Larson, Paul Hoffman, 2016-03-19,
<draft-ietf-dnsop-resolver-priming-07.txt>
This document describes the queries that a DNS resolver should emit
to initialize its cache. The result is that the resolver gets both a
current NS RRSet for the root zone and the necessary address
information for reaching the root servers.
"Add 100.64.0.0/10 prefixes to IPv4 Locally-Served DNS Zones Registry.",
Mark Andrews, 2015-10-11, <draft-ietf-dnsop-rfc6598-rfc6303-05.txt>
RFC6598 specified that: "Reverse DNS queries for Shared Address Space
addresses [100.64.0.0/10] MUST NOT be forwarded to the global DNS
infrastructure."
This document formally directs IANA to add the associated zones to
the "IPv4 Locally-Served DNS Zones Registry" to prevent such queries
accidently leaking to the global DNS infrastructure.
"DNSSEC Roadblock Avoidance", Wesley Hardaker, lafur Gumundsson,
Suresh Krishnaswamy, 2016-04-03,
<draft-ietf-dnsop-dnssec-roadblock-avoidance-04.txt>
This document describes problems that a DNSSEC aware resolver/
application might run into within a non-compliant infrastructure. It
outline potential detection and mitigation techniques. The scope of
the document is to create a shared approach to detect and overcome
network issues that a DNSSEC software/system may face.
"Chain Query requests in DNS", Paul Wouters, 2016-02-18,
<draft-ietf-dnsop-edns-chain-query-07.txt>
This document defines an EDNS0 extension that can be used by a
security-aware validating resolver configured to use a Forwarder to
send a single query, requesting a complete validation path along with
the regular query answer. The reduction in queries potentially
lowers the latency and reduces the need to send multiple queries at
once. This extension mandates the use of source IP verified
transport such as TCP or UDP with EDNS-COOKIE so it cannot be abused
in amplification attacks.
"Client Subnet in DNS Queries", Carlo Contavalli, Wilmer van der Gaast,
tale, Warren Kumari, 2016-04-19,
<draft-ietf-dnsop-edns-client-subnet-08.txt>
This document describes an EDNS0 extension that is in active use to
carry information about the network that originated a DNS query, and
the network for which the subsequent response can be cached. Since
it has some known operational and privacy shortcomings, a revision
will be worked through the IETF for improvement.
"Domain Name System (DNS) Cookies", Donald Eastlake, Mark Andrews,

2016-04-05, <draft-ietf-dnsop-cookies-10.txt>
DNS cookies are a lightweight DNS transaction security mechanism that
provides limited protection to DNS servers and clients against a
variety of increasingly common denial-of-service and amplification /
forgery or cache poisoning attacks by off-path attackers. DNS Cookies
are tolerant of NAT, NAT-PT, and anycast and can be incrementally
deployed. (Since DNS Cookies are only returned to the IP address from
which they were originally received, they cannot be used to generally
track Internet users.)
"Aggressive use of NSEC/NSEC3", Kazunori Fujiwara, Akira Kato,
2016-03-17, <draft-fujiwara-dnsop-nsec-aggressiveuse-03.txt>
While DNS highly depends on cache, its cache usage of non-existence
information has been limited to exact matching. This draft proposes
the aggressive use of a NSEC/NSEC3 resource record, which is able to
express non-existence of a range of names authoritatively. With this
proposal, it is expected that shorter latency to many of negative
responses as well as some level of mitigation of random sub-domain
attacks (referred to as "Water Torture" attacks). It is also
expected that non-existent TLD queries to Root DNS servers will
decrease.
"The ALT Special Use Top Level Domain", Warren Kumari, Andrew Sullivan,
2016-03-21, <draft-ietf-dnsop-alt-tld-04.txt>
This document reserves a string (ALT) to be used as a TLD label in
non-DNS contexts or for names that have no meaning in a global
context. It also provides advice and guidance to developers
developing alternate namespaces.
[ Ed note: This document lives in GitHub at:
https://github.com/wkumari/draft-wkumari-dnsop-alt-tld . Issues and
pull requests happily accepted. ]
"Reverse DNS in IPv6 for Internet Service Providers", Lee Howard,
2015-12-22, <draft-ietf-dnsop-isp-ip6rdns-01.txt>
In IPv4, Internet Service Providers (ISPs) commonly provide INADDR.ARPA information for their customers by prepopulating the zone
with one PTR record for every available address. This practice does
not scale in IPv6. This document analyzes different approaches and
considerations for ISPs in managing the ip6.arpa zone for IPv6
address space assigned to many customers.
"Providing Minimal-Sized Responses to DNS Queries with QTYPE=ANY", Joe
Abley, lafur Gumundsson, Marek Majkowski, 2016-04-06,
<draft-ietf-dnsop-refuse-any-01.txt>
The Domain Name System (DNS) specifies a query type (QTYPE) "ANY".
The operator of an authoritative DNS server might choose not to
respond to such queries for reasons of local policy, motivated by
security, performance or other reasons.
The DNS specification does not include specific guidance for the
behaviour of DNS servers or clients in this situation. This document
aims to provide such guidance.
"A Common Operational Problem in DNS Servers - Failure To Respond.",

Mark Andrews, 2016-04-06, <draft-ietf-dnsop-no-response-issue-03.txt>

The DNS is a query / response protocol. Failure to respond or to
respond correctly to queries causes both immediate operational
problems and long term problems with protocol development.
This document identifies a number of common kinds of queries to which
some servers either fail to respond or else respond incorrectly.
This document also suggests procedures for TLD and other similar zone
operators to apply to help reduce / eliminate the problem.
The document does not look at the DNS data itself, just the structure
of the responses.
"The EDNS Key Tag Option", Duane Wessels, Warren Kumari, 2016-03-09,
<draft-ietf-dnsop-edns-key-tag-01.txt>
The DNS Security Extensions (DNSSEC) were developed to provide origin
authentication and integrity protection for DNS data by using digital
signatures. These digital signatures can be verified by building a
chain-of-trust starting from a trust anchor and proceeding down to a
particular node in the DNS. This document specifies a way for
validating end-system resolvers to signal to a server which keys are
referenced in their chain-of-trust. The extensions allow zone
administrators to monitor the progress of rollovers in a DNSSECsigned zone.
"Managing DS records from parent via CDS/CDNSKEY", lafur Gumundsson,
Paul Wouters, 2016-04-03, <draft-ietf-dnsop-maintain-ds-02.txt>
RFC7344 specifies how DNS trust can be partially maintained in-band
between parent and child. There are two features missing in that
specification: initial trust setup and removal of trust anchor. This
document addresses both these omissions.
Changing a domain's DNSSEC status can be a complicated matter
involving multiple unrelated parties. Some of these parties, such as
the DNS operator, might not even be known by all organizations
involved. The inability to disable DNSSEC via in-band signalling is
seen as a problem or liability that prevents some DNSSEC adoption at
large scale. This document adds a method for in-band signalling of
this DNSSEC status changes.
Initial trust is considered a much harder problem, this document will
seek to clarify and simplify the initial acceptance policy.
"NXDOMAIN really means there is nothing underneath", Stephane
Bortzmeyer, Shumon Huque, 2016-04-07,
<draft-ietf-dnsop-nxdomain-cut-02.txt>
This document states clearly that when a DNS resolver receives a
response with response code of NXDOMAIN, it means that the domain
name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
REMOVE BEFORE PUBLICATION: this document should be discussed in the
IETF DNSOP (DNS Operations) group, through its mailing list. The
source of the document, as well as a list of open issues, is
currently kept at Github [1].
This documents clarifies RFC 1034 and modifies a bit RFC 2308 so it

updates both of them.

"DNS Terminology", Paul Hoffman, Andrew Sullivan, Kazunori Fujiwara,
2016-01-12, <draft-ietf-dnsop-terminology-bis-00.txt>
The DNS is defined in literally dozens of different RFCs. The
terminology used by implementers and developers of DNS protocols, and
by operators of DNS systems, has sometimes changed in the decades
since the DNS was first defined. This document gives current
definitions for many of the terms used in the DNS in a single
document.
This document will be the successor to RFC 7719. It will update many
of the original RFCs. This first draft is essentially the same text
as RFC 7719 and is used as a baseline for creating diffs during the
document prepration process.
"Classless IN-ADDR.ARPA delegation and dynamic reverse DNS UPDATE", Tony
Finch, 2016-01-13, <draft-ietf-dnsop-rfc2317bis-00.txt>
This memo describes how to do IN-ADDR.ARPA delegation on any nonoctet boundary, and how to consolidate reverse DNS for multiple
address blocks into one zone. It obsoletes RFC 2317.
It also clarifies the behaviour of dynamic reverse DNS UPDATE
clients. It updates RFC 2136.
"DNS Scoped Data Through '_Underscore' Attribute Leaves", dcrocker,
2016-03-15, <draft-ietf-dnsop-attrleaf-00.txt>
Historically, any DNS RR may occur for any domain name. Recent
additions have defined DNS leaf nodes that contain a reserved node
name, beginning with an underscore. The underscore construct is used
to define a semantic scope for DNS records that are associated with
the parent domain. This specification explores the nature of this
DNS usage and defines the "underscore names" registry with IANA.
Extensions for Scalable DNS Service Discovery (dnssd)
-----------------------------------------------------"Hybrid Unicast/Multicast DNS-Based Service Discovery", Stuart Cheshire,
2016-02-04, <draft-ietf-dnssd-hybrid-03.txt>
Performing DNS-Based Service Discovery using purely link-local
Multicast DNS enables discovery of services that are on the local
link, but not (without some kind of proxy or similar special support)
discovery of services that are outside the local link. Using a very
large local link with thousands of hosts facilitates service
discovery, but at the cost of large amounts of multicast traffic.
Performing DNS-Based Service Discovery using purely Unicast DNS is
more efficient and doesn't require excessively large multicast
domains, but requires that the relevant data be available in the
Unicast DNS namespace. This can be achieved by manual DNS
configuration (as has been done for many years at IETF meetings to
advertise the IETF Terminal Room printer) but this is labor
intensive, error prone, and requires a reasonable degree of DNS
expertise. The Unicast DNS namespace can be populated with the
required data automatically by the devices themselves, but that
requires configuration of DNS Update keys on the devices offering the

services, which has proven onerous and impractical for simple devices
like printers and network cameras.
Hence, to facilitate efficient and reliable DNS-Based Service
Discovery, a compromise is needed that combines the ease-of-use of
Multicast DNS with the efficiency and scalability of Unicast DNS.
"DNS Push Notifications", Tom Pusateri, Stuart Cheshire, 2016-04-04,
<draft-ietf-dnssd-push-07.txt>
The Domain Name System (DNS) was designed to return matching records
efficiently for queries for data that is relatively static. When
those records change frequently, DNS is still efficient at returning
the updated results when polled. But there exists no mechanism for a
client to be asynchronously notified when these changes occur. This
document defines a mechanism for a client to be notified of such
changes to DNS records, called DNS Push Notifications.
DDoS Open Threat Signaling (dots)
--------------------------------"Use cases for DDoS Open Threat Signaling", Roland Dobbins, Stephane
Fouant, Daniel Migault, Robert Moskowitz, Nik Teague, Liang Xia,
2016-03-21, <draft-ietf-dots-use-cases-01.txt>
This document delineates principal and ancillary use cases for DDoS
Open Threat Signaling (DOTS), a communications protocol intended to
facilitate the programmatic, coordinated mitigation of Distributed
Denial of Service (DDoS) attacks via a standards-based mechanism.
DOTS is purposely designed to support requests for DDoS mitigation
services and status updates across inter-organizational
administrative boundaries.
"Distributed Denial of Service (DDoS) Open Threat Signaling
Requirements", Andrew Mortensen, Robert Moskowitz, Tirumaleswar Reddy,
2016-03-21, <draft-ietf-dots-requirements-01.txt>
This document defines the requirements for the Distributed Denial of
Service (DDoS) Open Threat Signaling (DOTS) protocols coordinating
attack response against DDoS attacks.
DNS PRIVate Exchange (dprive)
----------------------------"DNS over DTLS (DNSoD)", Tirumaleswar Reddy, Dan Wing, Prashanth Patil,
2016-04-04, <draft-ietf-dprive-dnsodtls-06.txt>
DNS queries and responses are visible to network elements on the path
between the DNS client and its server. These queries and responses
can contain privacy-sensitive information which is valuable to
protect. An active attacker can send bogus responses causing
misdirection of the subsequent connection.
To counter passive listening and active attacks, this document
proposes the use of Datagram Transport Layer Security (DTLS) for DNS,
to protect against passive listeners and certain active attacks. As
DNS needs to remain fast, this proposal also discusses mechanisms to
reduce DTLS round trips and reduce DTLS handshake size. The proposed
mechanism runs over port 853.

"Specification for DNS over TLS", Zi, Liang Zhu, John Heidemann, Allison
Mankin, Duane Wessels, Paul Hoffman, 2016-03-17,
<draft-ietf-dprive-dns-over-tls-09.txt>
This document describes the use of TLS to provide privacy for DNS.
Encryption provided by TLS eliminates opportunities for eavesdropping
and on-path tampering with DNS queries in the network, such as
discussed in RFC 7626. In addition, this document specifies two
usage profiles for DNS-over-TLS and provides advice on performance
considerations to minimize overhead from using TCP and TLS with DNS.
This document focuses on securing stub-to-recursive traffic, as per
the charter of the DPRIVE working group. It does not prevent future
applications of the protocol to recursive-to-authoritative traffic.
Note: this document was formerly named draft-ietf-dprive-start-tlsfor-dns. Its name has been changed to better describe the mechanism
now used. Please refer to working group archives under the former
name for history and previous discussion. [RFC Editor: please remove
this paragraph prior to publication]
"The EDNS(0) Padding Option", Alexander Mayrhofer, 2016-03-06,
<draft-ietf-dprive-edns0-padding-03.txt>
This document specifies the EDNS(0) 'Padding' option, which allows
DNS clients and servers to pad request and response messages by a
variable number of octets.
"Authentication and (D)TLS Profile for DNS-over-TLS and DNS-over-DTLS",
Sara Dickinson, Daniel Kahn Gillmor, Tirumaleswar Reddy, 2016-03-21,
<draft-ietf-dprive-dtls-and-tls-profiles-01.txt>
This document describes how a DNS client can use a domain name to
authenticate a DNS server that uses Transport Layer Security (TLS)
and Datagram TLS (DTLS). Additionally, it defines (D)TLS profiles
for DNS clients and servers implementing DNS-over-TLS and DNS-overDTLS.
"Evaluation of Privacy for DNS Private Exchange", Aziz Mohaisen, Allison
Mankin, 2016-02-03, <draft-ietf-dprive-eval-00.txt,.pdf>
The set of DNS requests that an individual makes can provide a
monitor with a large amount of information about that individual.
DNS Private Exchange (DPRIVE) aims to deprive this actor of this
information. This document describes methods for measuring the
performance of DNS privacy mechanisms, particularly it provides
methods for measuring effectiveness in the face of pervasive
monitoring as defined in RFC7258. The document includes example
evaluations for common use cases.
Data for Reachability of Inter/tra-NetworK SIP (drinks)
------------------------------------------------------"Session Peering Provisioning (SPP) Protocol over SOAP", Kenneth
Cartwright, Vikas Bhatia, Jean-Francois Mule, Alexander Mayrhofer,
2016-04-04, <draft-ietf-drinks-spp-protocol-over-soap-09.txt>
The Session Peering Provisioning Framework (SPPF) specifies the data
model and the overall structure to provision session establishment
data into Session Data Registries and SIP Service Provider data

stores. To utilize this framework one needs a substrate protocol.

Given that Simple Object Access Protocol (SOAP) is currently widely
used for messaging between elements of such provisioning systems,
this document specifies the usage of SOAP (via HTTPS) as the
substrate protocol for SPPF. The benefits include leveraging
prevalent expertise, and a higher probability that existing
provisioning systems will be able to easily migrate to using an SPPF
based protocol.
"Session Peering Provisioning Framework (SPPF)", Kenneth Cartwright,
Vikas Bhatia, Syed Ali, David Schwartz, 2015-08-12,
<draft-ietf-drinks-spp-framework-12.txt>
This document specifies the data model and the overall structure for
a framework to provision session establishment data into Session Data
Registries and SIP Service Provider data stores. The framework is
called the Session Peering Provisioning Framework (SPPF). The
provisioned data is typically used by network elements for session
establishment.
Delay/Disruption Tolerant Networking (dtn)
-----------------------------------------"Bundle Protocol", Scott Burleigh, Kevin Fall, Edward Birrane,
2016-03-04, <draft-ietf-dtn-bpbis-03.txt>
This Internet Draft presents a specification for Bundle Protocol,
adapted from the experimental Bundle Protocol specification
developed by the Delay-Tolerant Networking Research group of the
Internet Research Task Force and documented in RFC 5050.
"Bundle Protocol Security Specification", Edward Birrane, Jeremy
Pierce-Mayer, Dennis Iannicca, 2016-03-19, <draft-ietf-dtn-bpsec-01.txt>
This document defines a security protocol providing data integrity
and confidentiality services for the Bundle Protocol. Capabilities
are provided to protect blocks in a bundle along a single path
through a network.
Delay-Tolerant Networking (dtnrg)
--------------------------------"DTN IP Neighbor Discovery (IPND)", Daniel Ellard, Richard Altmann, Alex
Gladd, Ronald Velt, Daniel Brown, 2015-11-10,
<draft-irtf-dtnrg-ipnd-03.txt>
Disruption Tolerant Networking (DTN) IP Neighbor Discovery (IPND), is
a method for otherwise oblivious nodes to learn of the existence,
availability, and addresses of other DTN participants. IPND both
sends and listens for small IP UDP announcement "beacons." Beacon
messages are addressed to an IP unicast, multicast, or broadcast
destination to discover specified or unspecified remote neighbors, or
unspecified local neighbors in the topology, e.g. within wireless
range. IPND beacons advertise neighbor availability by including the
DTN node's canonical endpoint identifier. IPND beacons optionally
include service availability and parameters. In this way, neighbor
discovery and service discovery may be coupled or decoupled as
required. Once discovered, new neighbor pairs use advertised
availabilities to connect, exchange routing information, etc. This
document describes DTN IPND.

Emergency Context Resolution with Internet Technologies (ecrit)

--------------------------------------------------------------"Data-Only Emergency Calls", Brian Rosen, Henning Schulzrinne, Hannes
Tschofenig, Randall Gellens, 2016-03-01,
<draft-ietf-ecrit-data-only-ea-11.txt>
RFC 6443 'Framework for Emergency Calling Using Internet Multimedia'
describes how devices use the Internet to place emergency calls and
how Public Safety Answering Points (PSAPs) handle Internet multimedia
emergency calls natively. The exchange of multimedia traffic for
emergency services involves a SIP session establishment starting with
a SIP INVITE that negotiates various parameters for that session.
In some cases, however, the transmission of application data is all
that is needed. Examples of such environments include alerts issued
by a temperature sensor, burglar alarm, or chemical spill sensor.
Often these alerts are conveyed as one-shot data transmissions.
These type of interactions are called 'data-only emergency calls'.
This document describes a container for the data based on the Common
Alerting Protocol (CAP) and its transmission using the SIP MESSAGE
transaction.
"Additional Data Related to an Emergency Call", Randall Gellens, Brian
Rosen, Hannes Tschofenig, Roger Marshall, James Winterbottom,
2016-04-05, <draft-ietf-ecrit-additional-data-38.txt>
When an emergency call is sent to a Public Safety Answering Point
(PSAP), the originating device, the access network provider to which
the device is connected, and all service providers in the path of the
call have information about the call, the caller or the location
which is helpful for the PSAP to have in handling the emergency.
This document describes data structures and mechanisms to convey such
data to the PSAP. The intent is that every emergency call carry as
much as possible of the information described here using the
mechanisms described here.
The mechanisms permit the data to be conveyed by reference (as an
external resource) or by value (within the body of a SIP message or a
location object). This follows the tradition of prior emergency
services standardization work where data can be conveyed by value
within the call signaling (i.e., in the body of the SIP message) or
by reference.
"Next-Generation Pan-European eCall", Randall Gellens, Hannes
Tschofenig, 2016-02-19, <draft-ietf-ecrit-ecall-07.txt>
This document describes how to use IP-based emergency services
mechanisms to support the next generation of the Pan European invehicle emergency call service defined under the eSafety initiative
of the European Commission (generally referred to as "eCall"). eCall
is a standardized and mandated system for a special form of emergency
calls placed by vehicles. eCall deployment is required in the very
near future in European Union member states, and eCall (and eCallcompatible systems) are also being deployed in other regions. eCall
provides an integrated voice path and a standardized set of vehicle,
sensor (e.g., crash related), and location data. An eCall is
recognized and handled as a specialized form of emergency call and is
routed to a specialized eCall-capable Public Safety Answering Point

(PSAP) capable of processing the vehicle data and trained in handling

emergency calls from vehicles.
Currently, eCall functions over circuit-switched cellular telephony;
work on next-generation eCall (NG-eCall, sometimes called packetswitched eCall or PS-eCall) is now in process, and this document
assists in that work by describing how to support eCall within the
IP-based emergency services infrastructure.
This document also registers a MIME Content Type and an Emergency
Call Additional Data Block for the eCall vehicle data.
"Next-Generation Vehicle-Initiated Emergency Calls", Randall Gellens,
Brian Rosen, Hannes Tschofenig, 2016-02-19,
<draft-ietf-ecrit-car-crash-07.txt>
This document describes how to use IP-based emergency services
mechanisms to support the next generation of emergency calls placed
by vehicles (automatically in the event of a crash or serious
incident, or manually invoked by a vehicle occupant) and conveying
vehicle, sensor, and location data related to the crash or incident.
Such calls are often referred to as "Automatic Crash Notification"
(ACN), or "Advanced Automatic Crash Notification" (AACN), even in the
case of manual trigger. The "Advanced" qualifier refers to the
ability to carry a richer set of data.
This document also registers a MIME Content Type and an Emergency
Call Additional Data Block for the vehicle, sensor, and location data
(often referred to as "crash data" even though there is not
necessarily a crash). An external specification for the data format,
contents, and structure are referenced in this document.
This document reuses the technical aspects of next-generation panEuropean eCall (a mandated and standardized system for emergency
calls by in-vehicle systems within Europe and other regions).
However, this document specifies a different set of vehicle (crash)
data, specifically, the Vehicle Emergency Data Set (VEDS) rather than
the eCall Minimum Set of Data (MSD). This document is an extension
of the eCall document, with the differences being that this document
makes the MSD data set optional and VEDS mandatory. This document
also discusses legacy (curcuit-switched) ACN systems and their
migration to next-generation emergency calling.
"A LoST extension to return complete and similar location info", Roger
Marshall, Jeff Martin, Brian Rosen, 2016-03-21,
<draft-ietf-ecrit-similar-location-02.txt>
This document introduces a new way to provide returned location
information in LoST responses that is either of a completed or
similar form to the original input civic location, based on whether
valid or invalid civic address elements are returned within the
findServiceResponse message. This document defines a new extension
to the findServiceResponse message within the LoST protocol [RFC5222]
that enables the LoST protocol to return a completed civic address
element set for a valid location response, and one or more suggested
sets of similar location information for invalid LoST responses.
These two types of civic addresses are referred to as either
"complete location" or "similar location", and are included as a
compilation of CAtype xml elements within the existing LoST
findServiceResponse message structure.

"A Routing Request Extension for the HELD Protocol", James Winterbottom,
Hannes Tschofenig, Laura Liess, 2016-02-09,
<draft-ietf-ecrit-held-routing-05.txt>
For cases where location servers have access to emergency routing
information they are able to return routing information with the
location information if the location request includes a request for
the desired routing information. This document specifies an
extension to the HELD protocol that updates RFC5985, to support this
funciton. Allowing location and routing information to be acquired
in a single request response exchange updates RFC6881, as current
location acquisition and route determination procedures are separate
operations.
Extensible Provisioning Protocol Extensions (eppext)
---------------------------------------------------"Mark and Signed Mark Objects Mapping", Gustavo Lozano, 2016-03-10,
<draft-ietf-eppext-tmch-smd-06.txt>
Domain Name Registries (DNRs) may operate in special modes for
certain periods of time enabling trademark holders to protect their
rights during the introduction of a Top Level Domain (TLD).
One of those special modes of operation is the Sunrise Period. The
Sunrise Period allows trademark holders an advance opportunity to
register domain names corresponding to their trademarks before names
are generally available to the public.
This document describes the format of a mark and a digitally signed
mark used by trademark holders for registering domain names during
the sunrise phase of generic Top Level Domains (gTLDs). Three types
of mark objects are defined in this specification: registered
trademarks, court-validated marks, and marks protected by statue or
treaty.
Global Access to the Internet for All (gaia)
-------------------------------------------"Alternative Network Deployments: Taxonomy, characterization,
technologies and architectures", Jose Saldana, Andres Arcia-Moret, Bart
Braem, Ermanno Pietrosemoli, Arjuna Sathiaseelan, Marco Zennaro,
2016-04-26,
<draft-irtf-gaia-alternative-network-deployments-05.txt,.pdf>
This document presents a taxonomy of a set of "Alternative Network
Deployments" emerged in the last decade with the aim of bringing
Internet connectivity to people or of providing a local communication
infrastructure to serve various complementary needs and objectives.
They employ architectures and topologies different from those of
mainstream networks, and rely on alternative governance and business
models.
The document also surveys the technologies deployed in these
networks, and their differing architectural characteristics,
including a set of definitions and shared properties.
The classification considers models such as Community Networks,
Wireless Internet Service Providers (WISPs), networks owned by

individuals but leased out to network operators who use them as a

low-cost medium to reach the underserved population, and networks
that provide connectivity by sharing wireless resources of the users.
General Area (gen)
-----------------"Experiences from Cross-Area Work at the IETF", Jari Arkko, 2013-02-06,
<draft-arkko-iesg-crossarea-03.txt>
This memo discusses the reasons for IETF work on topics that cross
area boundaries. Such cross-area work presents challenges for the
organization of the IETF as well as on how interested parties can
participate the work. The memo also provides some suggestions on
managing these challenges.
"Intellectual Property Rights in IETF Technology", Scott Bradner, Jorge
Contreras, 2016-03-21, <draft-bradner-rfc3979bis-08.txt>
The IETF policies about Intellectual Property Rights (IPR), such as
patent rights, relative to technologies developed in the IETF are
designed to ensure that IETF working groups and participants have as
much information as possible about any IPR constraints on a technical
proposal as early as possible in the development process. The
policies are intended to benefit the Internet community and the
public at large, while respecting the legitimate rights of IPR
holders. This memo sets out the IETF policies concerning IPR related
to technology worked on within the IETF. It also describes the
objectives that the policies are designed to meet. This memo updates
RFC 2026 and obsoletes RFC 3979 and RFC 4879.
Geographic JSON (geojson)
------------------------"The GeoJSON Format", H. Butler, M. Daly, A. Doyle, Sean Gillies, T.
Schaub, T. Schaub, 2016-04-07, <draft-ietf-geojson-02.txt>
GeoJSON is a geospatial data interchange format based on JavaScript
Object Notation (JSON). It defines several types of JSON objects and
the manner in which they are combined to represent data about
geographic features, their properties, and their spatial extents.
This document recommends a single coordinate reference system based
on WGS 84. Other coordinate reference systems are not recommended.
"GeoJSON Text Sequences", Sean Gillies, 2016-04-18,
<draft-ietf-geojson-text-sequence-00.txt>
A proposed standard for geographic data that can be parsed and
produced incrementally.
Global Routing Operations (grow)
-------------------------------"BGP Monitoring Protocol", John Scudder, Rex Fernando, Stephen Stuart,
2016-01-13, <draft-ietf-grow-bmp-17.txt>
This document defines a protocol, BMP, that can be used to monitor
BGP sessions. BMP is intended to provide a convenient interface for
obtaining route views. Prior to introduction of BMP, screen-scraping
was the most commonly-used approach to obtaining such views. The

design goals are to keep BMP simple, useful, easily implemented, and
minimally service-affecting. BMP is not suitable for use as a
routing protocol.
"Internet Exchange BGP Route Server Operations", Nick Hilliard, Elisa
Jasinska, Robert Raszuk, Niels Bakker, 2015-06-08,
<draft-ietf-grow-ix-bgp-route-server-operations-05.txt>
The popularity of Internet exchange points (IXPs) brings new
challenges to interconnecting networks. While bilateral eBGP
sessions between exchange participants were historically the most
common means of exchanging reachability information over an IXP, the
overhead associated with this interconnection method causes serious
operational and administrative scaling problems for IXP participants.
Multilateral interconnection using Internet route servers can
dramatically reduce the administrative and operational overhead
associated with connecting to IXPs; in some cases, route servers are
used by IXP participants as their preferred means of exchanging
routing information.
This document describes operational considerations for multilateral
interconnections at IXPs.
"Problem Definition and Classification of BGP Route Leaks", Kotikalapudi
Sriram, Doug Montgomery, Danny McPherson, Eric Osterweil, Brian Dickson,
2016-05-05, <draft-ietf-grow-route-leak-problem-definition-06.txt>
A systemic vulnerability of the Border Gateway Protocol routing
system, known as 'route leaks', has received significant attention in
recent years. Frequent incidents that result in significant
disruptions to Internet routing are labeled "route leaks", but to
date a common definition of the term has been lacking. This document
provides a working definition of route leaks, keeping in mind the
real occurrences that have received significant attention. Further,
this document attempts to enumerate (though not exhaustively)
different types of route leaks based on observed events on the
Internet. The aim is to provide a taxonomy that covers several forms
of route leaks that have been observed and are of concern to Internet
user community as well as the network operator community.
"By default reject propagation when no policy is associated with a BGP
peering session.", Jared Mauch, Job Snijders, 2015-12-28,
<draft-ietf-grow-bgp-reject-00.txt>
This document defines the default behaviour of a BGP speaker when no
explicit policy is associated with a BGP peering session.
"BLACKHOLE BGP Community for Blackholing", Thomas King, Christoph
Dietzel, Job Snijders, Gert Doering, Greg Hankins, 2016-01-11,
<draft-ietf-grow-blackholing-00.txt>
This document describes the use of a well-known Border Gateway
Protocol (BGP) community for blackholing at IP networks and Internet
Exchange Points (IXP). This well-known advisory transitive BGP
community, namely BLACKHOLE, allows an origin AS to specify that a
neighboring IP network or IXP should blackhole a specific IP prefix.
"Multi-Threaded Routing Toolkit (MRT) Routing Information Export Format
with BGP Additional Paths Extensions", Colin Petrie, Thomas King,

2016-01-11, <draft-ietf-grow-mrt-add-paths-00.txt>
This document updates the Multi-threaded Routing Toolkit (MRT) export
format for Border Gateway Protocol (BGP) routing information by
extending it to support the Advertisement of Multiple Paths in BGP
extensions.
Host Identity Protocol (hip)
---------------------------"Host Identity Protocol (HIP) Registration Extension", Julien Laganier,
Lars Eggert, 2016-01-31, <draft-ietf-hip-rfc5203-bis-10.txt>
This document specifies a registration mechanism for the Host
Identity Protocol (HIP) that allows hosts to register with services,
such as HIP rendezvous servers or middleboxes. This document
obsoletes RFC5203.
"Host Identity Protocol (HIP) Rendezvous Extension", Julien Laganier,
Lars Eggert, 2015-12-17, <draft-ietf-hip-rfc5204-bis-07.txt>
This document defines a rendezvous extension for the Host Identity
Protocol (HIP). The rendezvous extension extends HIP and the HIP
registration extension for initiating communication between HIP nodes
via HIP rendezvous servers. Rendezvous servers improve reachability
and operation when HIP nodes are multi-homed or mobile. This
document obsoletes RFC5204.
"Host Identity Protocol Architecture", Robert Moskowitz, Miika Komu,
2015-12-14, <draft-ietf-hip-rfc4423-bis-13.txt>
This memo describes a new namespace, the Host Identity namespace, and
a new protocol layer, the Host Identity Protocol, between the
internetworking and transport layers. Herein are presented the
basics of the current namespaces, their strengths and weaknesses, and
how a new namespace will add completeness to them. The roles of this
new namespace in the protocols are defined.
This document obsoletes RFC 4423 and addresses the concerns raised by
the IESG, particularly that of crypto agility. It incorporates
lessons learned from the implementations of RFC 5201 and goes further
to explain how HIP works as a secure signaling channel.
"Host Identity Protocol (HIP) Domain Name System (DNS) Extension",
Julien Laganier, 2016-01-31, <draft-ietf-hip-rfc5205-bis-09.txt>
This document specifies a new resource record (RR) for the Domain
Name System (DNS), and how to use it with the Host Identity Protocol
(HIP). This RR allows a HIP node to store in the DNS its Host
Identity (HI, the public component of the node public-private key
pair), Host Identity Tag (HIT, a truncated hash of its public key),
and the Domain Names of its rendezvous servers (RVSs). This document
obsoletes RFC5205.
"Host Mobility with the Host Identity Protocol", Thomas Henderson,
Christian Vogt, Jari Arkko, 2016-05-05,
<draft-ietf-hip-rfc5206-bis-11.txt>
This document defines mobility extensions to the Host Identity
Protocol (HIP). Specifically, this document defines a general

"LOCATOR_SET" parameter for HIP messages that allows for a HIP host
to notify peers about alternate addresses at which it may be reached.
This document also defines elements of procedure for mobility of a
HIP host -- the process by which a host dynamically changes the
primary locator that it uses to receive packets. While the same
LOCATOR_SET parameter can also be used to support end-host
multihoming, detailed procedures are out of scope for this document.
This document obsoletes RFC 5206.
"Native NAT Traversal Mode for the Host Identity Protocol", Ari Keranen,
Jan Melen, 2016-01-19, <draft-ietf-hip-native-nat-traversal-10.txt>
This document specifies a new Network Address Translator (NAT)
traversal mode for the Host Identity Protocol (HIP). The new mode is
based on the Interactive Connectivity Establishment (ICE) methodology
and UDP encapsulation of data and signaling traffic. The main
difference from the previously specified modes is the use of HIP
messages for all NAT traversal procedures.
"Host Multihoming with the Host Identity Protocol", Thomas Henderson,
Christian Vogt, Jari Arkko, 2016-04-07,
<draft-ietf-hip-multihoming-08.txt>
This document defines host multihoming extensions to the Host
Identity Protocol (HIP), by leveraging protocol components defined
for host mobility.
"Host Identity Protocol Certificates", Tobias Heer, Samu Varjonen,
2016-04-22, <draft-ietf-hip-rfc6253-bis-08.txt>
The Certificate (CERT) parameter is a container for digital
certificates. It is used for carrying these certificates in Host
Identity Protocol (HIP) control packets. This document specifies the
certificate parameter and the error signaling in case of a failed
verification. Additionally, this document specifies the
representations of Host Identity Tags in X.509 version 3 (v3).
The concrete use cases of certificates, including how certificates
are obtained, requested, and which actions are taken upon successful
or failed verification, are specific to the scenario in which the
certificates are used. Hence, the definition of these scenariospecific aspects is left to the documents that use the CERT
parameter.
This document updates RFC7401 and obsoletes RFC6253.
"HIP Diet EXchange (DEX)", Robert Moskowitz, Rene Hummen, 2016-03-21,
<draft-ietf-hip-dex-02.txt>
This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The
HIP DEX protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and hash
functions. In doing so, the main goal is to still deliver similar
security properties to HIPv2.
The HIP DEX protocol is primarily designed for computation or memoryconstrained sensor/actuator devices. Like HIPv2, it is expected to
be used together with a suitable security protocol such as the
Encapsulated Security Payload (ESP) for the protection of upper layer

protocol data. In addition, HIP DEX can also be used as a keying

mechanism for security primitives at the MAC layer, e.g., for IEEE
802.15.4 networks.
Home Networking (homenet)
------------------------"Homenet Routing Consensus Call", Ray Bellis, Mark Townsley, 2016-01-21,
<draft-ietf-homenet-routing-consensus-call-01.txt>
In order to support arbitrary network topologies and multi-homing the
IETF Homenet Architecture [RFC7368] requires that a routing protocol
operates inside each home network. For interoperability reasons it
is necessary for there be a single "mandatory to implement" routing
protocol. With the Homenet Working Group unable to reach clear
consensus on which protocol that should be the Working Group Chairs
(with the support of the Internet Area Director) declared rough
consensus that the chosen protocol is BABEL [RFC6126]. This document
(not intended for publication as an RFC) serves as an additional
record of that decision.
"Homenet profile of the Babel routing protocol", Juliusz Chroboczek,
2016-03-21, <draft-chroboczek-homenet-babel-profile-00.txt>
This document defines the subset of the Babel routing protocol
[RFC6126] and its extensions that a Homenet router must implement.
Hypertext Transfer Protocol Authentication (httpauth)
----------------------------------------------------"Mutual Authentication Protocol for HTTP", Yutaka Oiwa, Hajime Watanabe,
Hiromitsu Takagi, Kaoru Maeda, lef, Yuichi Ioku, 2016-01-06,
<draft-ietf-httpauth-mutual-06.txt>
This document specifies a mutual authentication method for the Hypertext Transfer Protocol (HTTP). This method provides a true mutual
authentication between an HTTP client and an HTTP server using
password-based authentication. Unlike the Basic and Digest
authentication methods, the Mutual authentication method specified in
this document assures the user that the server truly knows the user's
encrypted password.
"HTTP Authentication Extensions for Interactive Clients", Yutaka Oiwa,
Hajime Watanabe, Hiromitsu Takagi, lef, Yuichi Ioku, 2016-01-06,
<draft-ietf-httpauth-extension-05.txt>
This document specifies a few extensions of HTTP authentication
framework for interactive clients. Recently, fundamental features of
HTTP-level authentication is not enough for complex requirements of
various Web-based applications. This makes these applications to
implement their own authentication frameworks using HTML Forms and
other means, which becomes one of the hurdles against introducing
secure authentication mechanisms handled jointly by servers and useragent clients. The extended framework fills gaps between Web
application requirements and HTTP authentication provisions to solve
the above problems, while maintaining compatibility against existing
Web and non-Web uses of HTTP authentications.
"Mutual Authentication Protocol for HTTP: KAM3-based Cryptographic
Algorithms", Yutaka Oiwa, Hajime Watanabe, Hiromitsu Takagi, Kaoru

Maeda, lef, Yuichi Ioku, 2016-01-06,

<draft-ietf-httpauth-mutual-algo-04.txt>
This document specifies some cryptographic algorithms which will be
used for the Mutual user authentication method for the Hyper-text
Transport Protocol (HTTP).
Hypertext Transfer Protocol (httpbis)
------------------------------------"Opportunistic Security for HTTP", Mark Nottingham, Martin Thomson,
2016-03-16, <draft-ietf-httpbis-http2-encryption-04.txt>
This document describes how "http" URIs can be accessed using
Transport Layer Security (TLS) to mitigate pervasive monitoring
attacks.
Note to Readers
Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ .
Working Group information can be found at http://httpwg.github.io/ ;
source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/opp-sec .
"Same-site Cookies", Mike West, Mark Goodwin, 2016-04-06,
<draft-west-first-party-cookies-07.txt>
This document updates RFC6265 by defining a "SameSite" attribute
which allows servers to assert that a cookie ought not to be sent
along with cross-site requests. This assertion allows user agents to
mitigate the risk of cross-origin information leakage, and provides
some protection against cross-site request forgery attacks.
"The ORIGIN HTTP/2 Frame", Mark Nottingham, Erik Nygren, 2016-01-30,
<draft-nottingham-httpbis-origin-frame-01.txt>
This document specifies the ORIGIN frame for HTTP/2, to indicate what
origins are available on a given connection.
"Indicating Character Encoding and Language for HTTP Header Field
Parameters", Julian Reschke, 2016-03-04,
<draft-ietf-httpbis-rfc5987bis-01.txt>
By default, message header field parameters in Hypertext Transfer
Protocol (HTTP) messages cannot carry characters outside the ISO8859-1 character set. RFC 2231 defines an encoding mechanism for use
in Multipurpose Internet Mail Extensions (MIME) headers. This
document specifies an encoding suitable for use in HTTP header fields
that is compatible with a profile of the encoding defined in RFC
2231.
"The Key HTTP Response Header Field", Roy Fielding, Mark Nottingham,
2016-03-01, <draft-ietf-httpbis-key-01.txt>
The 'Key' header field for HTTP responses allows an origin server to
describe the secondary cache key (RFC 7234, Section 4.1) for a
resource, by conveying what is effectively a short algorithm that can

be used upon later requests to determine if a stored response is

reusable for a given request.
Key has the advantage of avoiding an additional round trip for
validation whenever a new request differs slightly, but not
significantly, from prior requests.
Key also informs user agents of the request characteristics that
might result in different content, which can be useful if the user
agent is not sending request header fields in order to reduce the
risk of fingerprinting.
"Reactive Certificate-Based Client Authentication in HTTP/2", Martin
Thomson, Mike Bishop, 2016-03-14,
<draft-thomson-http2-client-certs-02.txt>
Some HTTP servers provide a subset of resources that require
additional authentication to interact with. HTTP/1.1 servers rely on
TLS renegotiation that is triggered by a request to a protected
resource. HTTP/2 made this pattern impossible by forbidding the use
of TLS renegotiation. While TLS 1.3 provides an alternate mechanism
to obtain client certificates, this mechanism does not map well to
usage in TLS 1.2.
This document describes a how client authentication might be
requested by a server as a result of receiving a request to a
protected resource.
"HTTP Client Hints", Ilya Grigorik, 2015-11-24,
<draft-ietf-httpbis-client-hints-00.txt>
An increasing diversity of Web-connected devices and software
capabilities has created a need to deliver optimized content for each
device.
This specification defines a set of HTTP request header fields,
colloquially known as Client Hints, to address this. They are
intended to be used as input to proactive content negotiation; just
as the Accept header allows clients to indicate what formats they
prefer, Client Hints allow clients to indicate a list of device and
agent specific preferences.
"Encrypted Content-Encoding for HTTP", Martin Thomson, 2016-03-20,
<draft-ietf-httpbis-encryption-encoding-01.txt>
This memo introduces a content-coding for HTTP that allows message
payloads to be encrypted.
Note to Readers
Discussion of this draft takes place on the HTTP working group
mailing list (ietf-http-wg@w3.org), which is archived at
https://lists.w3.org/Archives/Public/ietf-http-wg/ .
Working Group information can be found at http://httpwg.github.io/ ;
source code and issues list for this draft can be found at
https://github.com/httpwg/http-extensions/labels/encryption .
"Cookie Prefixes", Mike West, 2016-02-23,
<draft-ietf-httpbis-cookie-prefixes-00.txt>

This document updates RFC6265 by adding a set of restrictions upon

the names which may be used for cookies with specific properties.
These restrictions enable user agents to smuggle cookie state to the
server within the confines of the existing "Cookie" request header
syntax, and limits the ways in which cookies may be abused in a
conforming user agent.
"Deprecate modification of 'secure' cookies from non-secure origins",
Mike West, 2016-02-23, <draft-ietf-httpbis-cookie-alone-00.txt>
This document updates RFC6265 by removing the ability for a nonsecure origin to set cookies with a 'secure' flag, and to overwrite
cookies whose 'secure' flag is set. This deprecation improves the
isolation between HTTP and HTTPS origins, and reduces the risk of
malicious interference.
Interface to Network Security Functions (i2nsf)
----------------------------------------------"Analysis of Existing work for I2NSF", Susan Hares, Robert Moskowitz,
Dacheng Zhang, 2016-04-04, <draft-ietf-i2nsf-gap-analysis-01.txt,.pdf>
This document analyzes the current state of the art for security
management devices and security devices technologies in industries
and the existing IETF work/protocols that are relevant to the
Interface to Network Security Function (I2NSF). The I2NSF focus is
to define data models and interfaces in order to control and monitor
the physical and virtual aspects of network security functions.
"I2NSF Problem Statement and Use cases", Susan Hares, Linda Dunbar,
Diego Lopez, Myo Zarny, Christian Jacquenet, 2016-02-02,
<draft-ietf-i2nsf-problem-and-use-cases-00.txt,.pdf>
This document describes the problem statement for Interface to
Network Security Functions (I2NSF) and summary of the I2NSF use
cases.
"Interface to Network Security Functions (I2NSF) Terminology", Susan
Hares, John Strassner, Diego Lopez, Liang Xia, 2016-05-02,
<draft-ietf-i2nsf-terminology-00.txt>
This document defines a set of terms that are used for the Interface
to Network Security Functions (I2NSF) effort.
"Framework for Interface to Network Security Functions", Ed, Diego
Lopez, Linda Dunbar, John Strassner, Xiaojun Zhuang, Joe Parrott, Ram
(Ramki) Krishnan, Seetharama Durbha, 2016-05-02,
<draft-ietf-i2nsf-framework-00.txt>
This document defines the framework for guiding the functionality
provided by I2NSF. Network security functions (NSFs) are packetprocessing engines that inspect and optionally modify packets
traversing networks, either directly or in the context of sessions
in which the packet is associated. This document provides an
overview of how NSFs are used, and describes how NSF software
interfaces are controlled and monitored using rulesets. The design
of these software interfaces must prevent the creation of implied
constraints on NSF capability and functionality.

Interface to the Routing System (i2rs)

-------------------------------------"An Architecture for the Interface to the Routing System", Alia Atlas,
Joel Halpern, Susan Hares, David Ward, Tom Nadeau, 2016-04-22,
<draft-ietf-i2rs-architecture-15.txt,.pdf>
This document describes the IETF architecture for a standard,
programmatic interface for state transfer in and out of the Internet
routing system. It describes the high-level architecture, the
building blocks of this high-level architecture, and their interfaces
with particular focus on those to be standardized as part of the
Interface to Routing System (I2RS).
"Interface to the Routing System Problem Statement", Alia Atlas, Tom
Nadeau, David Ward, 2016-02-12,
<draft-ietf-i2rs-problem-statement-10.txt>
Traditionally, routing systems have implemented routing and signaling
(e.g. MPLS) to control traffic forwarding in a network. Route
computation has been controlled by relatively static policies that
define link cost, route cost, or import and export routing policies.
With the advent of highly dynamic data center networking, on-demand
WAN services, dynamic policy-driven traffic steering and service
chaining, the need for real-time security threat responsiveness via
traffic control, and a paradigm of separating policy-based decisionmaking from the router itself, the need has emerged to more
dynamically manage and program routing systems in order to control
routing information and traffic paths and to extract network topology
information, traffic statistics, and other network analytics from
routing systems.
This document proposes meeting this need via an Interface to the
Routing System (I2RS).
"Summary of I2RS Use Case Requirements", Susan Hares, Mach Chen,
2016-03-15, <draft-ietf-i2rs-usecase-reqs-summary-02.txt,.pdf>
The I2RS Working Group (WG) has described a set of use cases that the
I2RS systems could fulfil. This document summarizes these use cases.
It is designed to provide requirements that will aid the design of
the I2RS architecture, Information Models, Data Models, Security, and
protocols.
"Interface to the Routing System (I2RS) Traceability: Framework and
Information Model", Joe Clarke, Gonzalo Salgueiro, Carlos Pignataro,
2016-05-02, <draft-ietf-i2rs-traceability-09.txt>
This document describes a framework for traceability in the Interface
to the Routing System (I2RS) and information model for that
framework. It specifies the motivation, requirements, use cases, and
defines an information model for recording interactions between
elements implementing the I2RS protocol. This framework provides a
consistent tracing interface for components implementing the I2RS
architecture to record what was done, by which component, and when.
It aims to improve the management of I2RS implementations, and can be
used for troubleshooting, auditing, forensics, and accounting
purposes.
"Requirements for Subscription to YANG Datastores", Eric Voit, Alex

Clemm, Alberto Prieto, 2016-05-04,

<draft-ietf-i2rs-pub-sub-requirements-07.txt>
This document provides requirements for a service that allows client
applications to subscribe to updates of a YANG datastore. Based on
criteria negotiated as part of a subscription, updates will be pushed
to targeted recipients. Such a capability eliminates the need for
periodic polling of YANG datastores by applications and fills a
functional gap in existing YANG transports (i.e. Netconf and
Restconf). Such a service can be summarized as a "pub/sub" service
for YANG datastore updates. Beyond a set of basic requirements for
the service, various refinements are addressed. These refinements
include: periodicity of object updates, filtering out of objects
underneath a requested a subtree, and delivery QoS guarantees.
"Filter-Based RIB Information Model", Sriganesh Kini, Susan Hares, Linda
Dunbar, Anoop Ghanwani, Ram (Ramki) Krishnan, Dean Bogdanovic, Russ
White, 2016-02-07, <draft-kini-i2rs-fb-rib-info-model-03.txt,.pdf>
This document defines an information model associated with the I2RS
ephemeral state for filter-based routing of IP packets via a Filterbased Routing Information Base (FB-RIB). FB-RIBs (ephemeral and nonephemeral) are associated with specific interfaces interfaces on a
routing device, and process packets received on these interfaces
according a filtering policy. A filtering policy is a a minimalistic
event-match_condition-action (ECA) policy with only one event - the
reception of a frame/packet of data on an interface. The match
conditions in the filter policy are n-tuple matches based on the
content of the frame/packet or the time of its arrival. Filter-based
policy allows actions which modifying the frame/packet, forward the
frame or packet, or drop the frame/packet. Filter-Based Policy in
FB-RIBs engages before any destination based routing so the FB-RIBs
provide a destination-based default RIB that will be used if none of
the filters are matched.
"A YANG Data Model for Routing Information Base (RIB)", Lixing Wang,
Hariharan Ananthakrishnan, Mach Chen, amit.dass@ericsson.com, Sriganesh
Kini, Nitin Bahadur, 2016-03-17, <draft-ietf-i2rs-rib-data-model-05.txt>
This document defines a YANG data model for Routing Information Base
(RIB) that aligns with the I2RS RIB information model.
"A Data Model for Network Topologies", Alex Clemm, Jan Medved, Robert
Varga, Tony Tkacik, Nitin Bahadur, Hariharan Ananthakrishnan,
2015-12-08, <draft-ietf-i2rs-yang-network-topo-02.txt>
This document defines an abstract (generic) YANG data model for
network/service topologies and inventories. The model serves as a
base model which is augmented with technology-specific details in
other, more specific topology and inventory models.
"A YANG Data Model for Layer-2 Network Topologies", Jie Dong, Xiugang
Wei, 2015-12-22, <draft-ietf-i2rs-yang-l2-network-topology-02.txt>
This document defines a YANG data model for Layer 2 network
topologies.
"A YANG Data Model for Layer 3 Topologies", Alex Clemm, Jan Medved,
Robert Varga, Tony Tkacik, Xufeng Liu, Igor Bryskin, Aihua Guo,
Hariharan Ananthakrishnan, Nitin Bahadur, Vishnu Pavan Beeram,

2015-12-11, <draft-ietf-i2rs-yang-l3-topology-01.txt>
This document defines a YANG data model for layer 3 network
topologies.
"I2RS Ephemeral State Requirements", Jeffrey Haas, Susan Hares,
2016-05-05, <draft-ietf-i2rs-ephemeral-state-06.txt,.pdf>
This document covers requests to the netmod and netconf Working
Groups for functionality to support the ephemeral state requirements
to implement the I2RS architecture.
"I2RS Security Related Requirements", Susan Hares, Daniel Migault, Joel
Halpern, 2016-05-05,
<draft-ietf-i2rs-protocol-security-requirements-04.txt,.pdf>
This presents security-related requirements for the I2RS protocol for
mutual authentication, transport protocols, data transfer and
transactions.
"I2RS Environment Security Requirements", Daniel Migault, Joel Halpern,
Susan Hares, 2016-04-04,
<draft-ietf-i2rs-security-environment-reqs-01.txt>
This document provides environment security requirements for the I2RS
architecture. Environment security requirements are independent of
the protocol used for I2RS. As a result, the requirements provided
in this document are intended to provide good security practise so
I2RS can be securely deployed and operated.
These security requirements are designated as environment security
requirements as opposed to the protocol security requirements. The
reason to have separate document is that protocol security
requirements are intended to help the design of the I2RS protocol
whether the environment requirements are rather intended for
deployment or implementations.
"Filter-Based RIB Data Model", Susan Hares, Sriganesh Kini, Linda
Dunbar, Ram (Ramki) Krishnan, Dean Bogdanovic, Russ White, 2016-03-21,
<draft-hares-i2rs-fb-rib-data-model-03.txt,.pdf>
This document defines a data model to support the Filter-based
Routing Information Base (RIB) Yang data models for I2RS. A routing
system uses the Filter-based RIB to program FIB entries that process
incoming packets by matching on multiple fields within the packet and
then performing a specified action on it. The FB-RIB can also
specify an action to forward the packet according to the FIB entries
programmed using the RIBs of its routing instance.
"Filter-Based Packet Forwarding ECA Policy", Susan Hares, Qin Wu, Russ
White, 2016-02-09, <draft-hares-i2rs-pkt-eca-data-model-02.txt>
This document describes the yang data model for packet forwarding
policy that filters received packets and forwards (or drops) the
packets. Prior to forwarding the packets out other interfaces, some
of the fields in the packets may be modified. If one considers the
packet reception an event, this packet policy is a minimalistic
Event-Match Condition-Action policy. This policy controls forwarding
of packets received by a routing device on one or more interfaces on
which this policy is enabled. The policy is composed of an ordered

list of policy rules. Each policy policy rule contains a set of

match conditions that filters for packets plus a set of actions to
modify the packet and forward packets. The match conditions can
match tuples in multiple layers (L1-L4, application), interface
received on, and and other conditions regarding the packet (size of
packet, time of day). The modify packet actions allow for setting
things within the packet plus decapsulation and encapsulation packet.
The forwarding actions include forwarding via interfaces, tunnels, or
nexthops and dropping the packet. The policy model can be used with
the session ephemeral (BGP Flow Specifications), reboot ephemeral
state (I2RS ephemeral), and non-ephemeral routing/forwarding state
(e.g. configuration state ).
Internet Architecture Board (iab)
--------------------------------"Confidentiality in the Face of Pervasive Surveillance", Ted Hardie,
2016-03-20, <draft-iab-privsec-confidentiality-mitigations-06.txt>
The IAB has published [RFC7624] in response to several revelations of
pervasive attack on Internet communications. In this document we
survey the mitigations to those threats which are currently available
or which might plausibly be deployed. We discuss these primarily in
the context of Internet protocol design, focusing on robustness to
pervasive monitoring and avoidance of unwanted cross-mitigation
impacts.
"Out With the Old and In With the New: Planning for Protocol
Transitions", Dave Thaler, 2016-03-21,
<draft-iab-protocol-transitions-01.txt>
Over the many years since the introduction of the Internet Protocol,
we have seen a number of transitions, throughout the protocol stack,
from one protocol or technology to another. Many protocols and
technologies were not designed to enable smooth transition to
alternatives or to easily deploy extensions, and thus some
transitions, such as the introduction of IPv6, have been difficult.
This document attempts to summarize some basic principles to enable
future transitions, and also summarizes what makes for a good
transition plan.
"On RFC Streams, Headers, and Boilerplates", Joel Halpern, Leslie
Daigle, Olaf Kolkman, IAB, 2016-02-02, <draft-iab-rfc5741bis-02.txt>
RFC documents contain a number of fixed elements such as the title
page header, standard boilerplates and copyright/IPR statements.
This document describes them and introduces some updates to reflect
current usage and requirements of RFC publication. In particular,
this updated structure is intended to communicate clearly the source
of RFC creation and review. This document obsoletes RFC 5741, moving
detailed content to an IAB web page and preparing for more flexible
output formats.
"Problems with the Public Key Infrastructure (PKI) for the World Wide
Web", Russ Housley, Karen O'Donoghue, 2016-02-21,
<draft-iab-web-pki-problems-01.txt>
This document describes some of the challenges facing the current
Public Key Infrastructure (PKI) used for the World Wide Web (Web PKI)
and considers promising improvements to address these challenges.

Technical, process, and policy improvements to the WebPKI are

considered. In addition, some technical considerations beyond WebPKI
itself are considered. Hopefully the content of this document will
help drive the Internet community toward wide spread adoption of some
of the highlighted recommendations.
"The "xml2rfc" version 3 Vocabulary", Paul Hoffman, 2016-02-10,
<draft-iab-xml2rfc-03.txt>
This document defines the "xml2rfc" version 3 vocabulary: an XMLbased language used for writing RFCs and Internet-Drafts. It is
heavily derived from the version 2 vocabulary that is also under
discussion. This document obsoletes the v2 grammar described in RFC
2629 and its followup, RFC 7749.
Editorial Note (To be removed by RFC Editor)
Discussion of this draft takes place on the rfc-interest mailing list
(rfc-interest@rfc-editor.org), which has its home page at
<https://www.rfc-editor.org/mailman/listinfo/rfc-interest>.
"RFC Format Framework", Heather Flanagan, 2016-02-05,
<draft-iab-rfc-framework-04.txt>
The canonical format for the RFC Series has been plain-text, ASCIIencoded for several decades. After extensive community discussion
and debate, the RFC Editor will be transitioning to XML as the
canonical format using the XML2RFC version 3 vocabulary. Different
publication formats will be rendered from that base document. These
changes are intended to increase the usability of the RFC Series by
offering documents that match the needs of a wider variety of
stakeholders. With these changes, however, comes an increase in
complexity for authors, consumers, and the publisher of RFCs. This
document serves as the framework that describes the problems being
solved and summarizes the many documents that capture the specific
requirements for each aspect of the change in format.
"CSS Requirements for RFCs", Heather Flanagan, 2016-01-05,
<draft-iab-rfc-css-00.txt>
The HTML format for RFCs, described in [I-D.hildebrand-html-rfc]
assigns style guidance to an RFC Editor-defined Cascading Style Sheet
(CSS). The embedded, default CSS as included by the RFC Editor is
expected to take into account accessibility needs and be built along
a responsive design model. This document describes the requirements
for the default CSS used by the RFC Editor. The class names are
based on the classes defined in draft-hildebrand-html-rfc.
Discussion of this draft takes place on the rfc-interest mailing list
(rfc-interest@rfc-editor.org), which has its home page at
https://www.rfc-editor.org/mailman/listinfo/rfc-interest.
"SVG Drawings for RFCs: SVG 1.2 RFC", Nevil Brownlee, IAB, 2016-02-25,
<draft-iab-svg-rfc-02.txt>
. Maybe the text in section This document specifies SVG 1.2 RFC - an
SVG profile for use in diagrams that may appear in RFCs - and
considers some of the issues concerning the creation and use of such
diagrams.

"RFC v3 Prep Tool Description", Paul Hoffman, Joe Hildebrand,

2016-02-10, <draft-iab-rfcv3-preptool-01.txt>
This document describes some aspects of the "prep tool" that is
expected to be created when the new RFC v3 specification is deployed.
"HyperText Markup Language Request For Comments Format", Joe Hildebrand,
Paul Hoffman, 2016-02-02, <draft-iab-html-rfc-02.txt>
In order to meet the evolving needs of the Internet community, the
format for RFCs is changing from a plain-text, ASCII-only format to a
canonical XML format that will in turn be rendered into several
publication formats. This document defines the HTML format that will
be rendered for an RFC or Internet-Draft.
"Requirements for Plain-Text RFCs", Heather Flanagan, 2016-02-10,
<draft-iab-rfc-plaintext-02.txt>
In 2013, after a great deal of community discussion, the decision was
made to shift from the plain-text, ASCII-only canonical format for
RFCs to XML as the canonical format with more human-readable formats
rendered from that XML. The high-level requirements that informed
this change were defined in RFC6949, "RFC Series Format Requirements
and Future Development." Plain text remains an important format for
many in the IETF community, and will be one of the publication
formats rendered from the XML. This draft documents the rendering
requirements for the plain-text RFC publication format. These
requirements do not apply to plain-text RFCs published before the
format transition.
"PDF for an RFC Series Output Document Format", Tony Hansen, Larry
Masinter, Matthew Hardy, 2016-01-27, <draft-iab-rfc-use-of-pdf-01.txt>
This document discusses options and requirements for the PDF
rendering of RFCs in the RFC Series, as outlined in RFC 6949. It
also discusses the use of PDF for Internet-Drafts, and available or
needed software tools for producing and working with PDF.
"IETF ISOC Board of Trustee Appointment Procedures", Joe Hildebrand,
Leslie Daigle, 2016-02-10, <draft-iab-rfc3677bis-00.txt>
This memo, which obsoletes RFC3677, outlines the process by which the
IETF makes a selection of an Internet Society (ISOC) Board of
Trustees appointment.
Planning for the IANA/NTIA Transition (ianaplan)
-----------------------------------------------"Draft Response to the Internet Coordination Group Request for Proposals
on the IANA protocol parameters registries", Eliot Lear, Russ Housley,
2015-01-06, <draft-ietf-ianaplan-icg-response-09.txt>
The U.S. NTIA has solicited a request from ICANN to propose how the
NTIA should end its oversight of the IANA functions. After broad
consultations, ICANN has in turn created the IANA Stewardship
Transition Coordination Group. That group solicited proposals for
thre three major IANA functions: names, numbers, and protocol
parameters. This document contains the IETF response to that
solicitation for protocol parameters. It is meant to be included in
an aggregate response to the NTIA alongside those for names and

numbering resources that are being developed by their respective

operational communities.
Interactive Connectivity Establishment (ice)
-------------------------------------------"ICE Multihomed and IPv4/IPv6 Dual Stack Fairness", Paal-Erik Martinsen,
Tirumaleswar Reddy, Prashanth Patil, 2016-04-07,
<draft-ietf-ice-dualstack-fairness-02.txt>
This document provides guidelines on how to make Interactive
Connectivity Establishment (ICE) conclude faster in multihomed and
IPv4/IPv6 dual-stack scenarios where broken paths exist. The
provided guidelines are backwards compatible with the original ICE
specification.
"Interactive Connectivity Establishment (ICE): A Protocol for Network
Address Translator (NAT) Traversal", Ari Keranen, Jonathan Rosenberg,
2015-12-21, <draft-ietf-ice-rfc5245bis-01.txt>
This document describes a protocol for Network Address Translator
(NAT) traversal for UDP-based multimedia. This protocol is called
Interactive Connectivity Establishment (ICE). ICE makes use of the
Session Traversal Utilities for NAT (STUN) protocol and its
extension, Traversal Using Relay NAT (TURN).
This document obsoletes RFC 5245.
"Trickle ICE: Incremental Provisioning of Candidates for the Interactive
Connectivity Establishment (ICE) Protocol", Emil Ivov, Eric Rescorla,
Justin Uberti, Peter Saint-Andre, 2015-12-10,
<draft-ietf-ice-trickle-01.txt>
This document describes an extension to the Interactive Connectivity
Establishment (ICE) protocol that enables ICE agents to send and
receive candidates incrementally rather than exchanging complete
lists. With such incremental provisioning, ICE agents can begin
connectivity checks while they are still gathering candidates and
considerably shorten the time necessary for ICE processing to
complete. This mechanism is called "trickle ICE".
Information-Centric Networking (icnrg)
-------------------------------------"Information-centric Networking: Evaluation and Security
Considerations", Kostas Pentikousis, Borje Ohlman, Elwyn Davies, Spiros
Spirou, Gennaro Boggia, 2016-04-12,
<draft-irtf-icnrg-evaluation-methodology-05.txt>
This document presents a number of considerations regarding
evaluating Information-centric Networking (ICN) and sheds some light
on the impact of ICN on network security. It also surveys the
evaluation tools currently available to researchers in the ICN area
and provides suggestions regarding methodology and metrics.
"Adaptive Video Streaming over ICN", cedric.westphal@huawei.com, Stefan
Lederer, Christopher Mueller, Andrea Detti, Daniel Corujo, Jianping
Wang, Marie-Jose Montpetit, Niall Murray, Christian Timmerer, Daniel
Posch, aytav.azgin, Shucheng LIU, 2016-04-28,
<draft-irtf-icnrg-videostreaming-08.txt>

This document considers the consequences of moving the underlying

network architecture from the current Internet to an InformationCentric Network (ICN) architecture on video distribution. As most of
the traffic in future networks is expected to be video, we consider
how to modify the existing video streaming mechanisms. Several
important topics related to video distribution over ICN are
presented, covering a wide range of scenarios: we look at how to
evolve DASH to work over ICN, and leverage the recent ISO/IEC Moving
Picture Experts Group (MPEG) Dynamic Adaptive Streaming over HTTP
(DASH) standard; we consider layered encoding over ICN; Peer-to-Peer
(P2P) mechanisms introduce distinct requirements for video and we
look at how to adapt PPSP for ICN; Internet Protocol Television
(IPTV) adds delay constraints, and this will create more stringent
requirements over ICN as well. As part of the discussion on video,
we discuss Digital Rights Management (DRM) in ICN. Finally, in
addition to considering how existing mechanisms would be impacted by
ICN, this document lists some research issues to design ICN specific
video streaming mechanisms.
"ICN Research Challenges", Dirk Kutscher, Suyong Eum, Kostas
Pentikousis, Ioannis Psaras, Daniel Corujo, Damien Saucez, Thomas
Schmidt, Matthias Waehlisch, 2016-03-19,
<draft-irtf-icnrg-challenges-06.txt>
This memo describes research challenges for Information-Centric
Networking (ICN), an approach to evolve the Internet infrastructure
to directly support information distribution by introducing uniquely
named data as a core Internet principle. Data becomes independent
from location, application, storage, and means of transportation,
enabling or enhancing a number of desirable features, such as
security, user-mobility, multicast and in-network caching.
Mechanisms for realizing these benefits is subject of on-going
research in the IRTF and elsewhere. This document describes current
research challenges in ICN, including naming, security, routing,
system scalability, mobility management, wireless networking,
transport services, in-network caching, and network management.
This document is a product of the IRTF Information-Centric Networking
Research Group (ICNRG).
"CCNx Semantics", marc.mosko@parc.com, Ignacio Solis, Christopher Wood,
2016-04-04, <draft-irtf-icnrg-ccnxsemantics-02.txt>
This document describes the core concepts of the CCNx architecture
and presents a minimum network protocol based on two messages:
Interest and Content Object. It specifies the set of mandatory and
optional fields within those messages and describes their behavior
and interpretation. This architecture and protocol specification is
independent of a specific wire encoding.
The protocol also uses a Control message called an InterestReturn,
whereby one system can return an Interest message to the previous hop
due to an error condition. It indicates to the previous hop that the
current system will not respond to the Interest.
"CCNx Messages in TLV Format", marc.mosko@parc.com, 2016-04-04,
<draft-irtf-icnrg-ccnxmessages-02.txt>
This document specifies the encoding of CCNx messages using a TLV

Packet specification. CCNx messages follow the CCNx Semantics

specification. This document defines the TLV types used by each
message element and the encoding of each value.
"Using ICN in disaster scenarios", Jan Seedorf, Mayutan Arumaithurai,
Atsushi Tagami, K. Ramakrishnan, Nicola Blefari-Melazzi, 2016-02-18,
<draft-irtf-icnrg-disaster-00.txt>
Information Centric Networking (ICN) is a new paradigm where the
network provides users with named content, instead of communication
channels between hosts. This document outlines some research
directions for Information Centric Networking with respect to
applying ICN approaches for coping with natural or human-generated,
large-scale disasters.
Inter-Domain Routing (idr)
-------------------------"Advertisement of Multiple Paths in BGP", Daniel Walton, Alvaro Retana,
Enke Chen, John Scudder, 2016-04-30, <draft-ietf-idr-add-paths-14.txt>
This document defines a BGP extension that allows the advertisement
of multiple paths for the same address prefix without the new paths
implicitly replacing any previous ones. The essence of the extension
is that each path is identified by a path identifier in addition to
the address prefix.
"Extended Optional Parameters Length for BGP OPEN Message", Enke Chen,
John Scudder, 2016-03-14, <draft-ietf-idr-ext-opt-param-04.txt>
The Optional Parameters in the BGP OPEN message as defined in the
base BGP specification are limited to 255 octets due to a one-octet
length field. BGP Capabilities are carried in this field and may
foreseeably exceed 255 octets in the future, leading to concern about
this limitation.
In this document we extend the BGP OPEN length field in a backwardcompatible manner. The Parameter Length field of individual Optional
Parameters is similarly extended.
"Best Practices for Advertisement of Multiple Paths in IBGP", Jim
Uttaro, P. Francois, Keyur Patel, Jeffrey Haas, Adam Simpson, Roberto
Fragassi, 2016-04-25, <draft-ietf-idr-add-paths-guidelines-08.txt>
Add-Paths is a BGP enhancement that allows a BGP router to advertise
multiple distinct paths for the same prefix/NLRI. This provides a
number of potential benefits, including reduced routing churn, faster
convergence and better loadsharing.
This document provides recommendations to implementers of Add-Paths
so that network operators have the tools needed to address their
specific applications and to manage the scalability impact of AddPaths. A router implementing Add-Paths may learn many paths for a
prefix and must decide which of these to advertise to peers. This
document analyses different algorithms for making this selection and
provides recommendations based on the target application.
"Dissemination of Flow Specification Rules for IPv6", Danny McPherson,
Robert Raszuk, Burjiz Pithawala, Andy, Susan Hares, 2016-03-19,
<draft-ietf-idr-flow-spec-v6-07.txt,.pdf>

Dissemination of Flow Specification Rules [RFC5575] provides a

protocol extension for propagation of traffic flow information for
the purpose of rate limiting or filtering. The [RFC5575] specifies
those extensions for IPv4 protocol data packets.
This specification extends the current [RFC5575] and defines changes
to the original document in order to make it also usable and
applicable to IPv6 data packets.
"BGP Optimal Route Reflection (BGP-ORR)", Robert Raszuk, Christian
Cassar, Erik Aman, Bruno Decraene, Stephane Litkowski, Kevin Wang,
2016-01-08, <draft-ietf-idr-bgp-optimal-route-reflection-11.txt>
This document proposes a solution for BGP route reflectors to allow
them to choose the best path their clients would have chosen under
the same conditions, without requiring further state or any new
features to be placed on the clients. This facilitates, for example,
best exit point policy (hot potato routing). This solution is
primarily applicable in deployments using centralized route
reflectors.
The solution relies upon all route reflectors learning all paths
which are eligible for consideration. Best path selection is
performed in each route reflector based on a configured virtual
location in the IGP. The location can be the same for all clients or
different per peer/update group or per peer. Best path selection can
also be performed based on user configured policies in each route
reflector.
"IPv6 Extensions for Route Target Distribution", Keyur Patel, Robert
Raszuk, Martine Djernaes, Jie Dong, Mach Chen, 2015-11-25,
<draft-ietf-idr-bgp-ipv6-rt-constrain-08.txt>
The current route target distribution specification as described in
[RFC 4684] defines Route Target NLRIs of maximum length of 12 bytes.
The IPv6 specific Route Target extended community is defined in [RFC
5701] as length of 20 bytes. Since the current specification only
supports prefixes of maximum length of 12 bytes, the lack of an IPv6
specific Route Target reachability information may be a problem when
an operator wants to use this application in a pure IPv6 environment.
This document defines an extension that allows BGP to exchange longer
length IPv6 Route Target prefixes.
"Internet Exchange BGP Route Server", Elisa Jasinska, Nick Hilliard,
Robert Raszuk, Niels Bakker, 2016-04-29,
<draft-ietf-idr-ix-bgp-route-server-10.txt>
This document outlines a specification for multilateral
interconnections at Internet exchange points (IXPs). Multilateral
interconnection is a method of exchanging routing information between
three or more external BGP speakers using a single intermediate
broker system, referred to as a route server. Route servers are
typically used on shared access media networks, such as Internet
exchange points (IXPs), to facilitate simplified interconnection
between multiple Internet routers.
"Revised Validation Procedure for BGP Flow Specifications", Jim Uttaro,
Clarence Filsfils, David Smith, Juan Alcaide, Pradosh Mohapatra,
2016-03-21, <draft-ietf-idr-bgp-flowspec-oid-03.txt>

This document describes a modification to the validation procedure

defined in RFC 5575 for the dissemination of BGP flow specifications.
RFC 5575 requires that the originator of the flow specification
matches the originator of the best-match unicast route for the
destination prefix embedded in the flow specification. This allows
only BGP speakers within the data forwarding path (such as autonomous
system border routers) to originate BGP flow specifications. Though
it is possible to disseminate such flow specifications directly from
border routers, it may be operationally cumbersome in an autonomous
system with a large number of border routers having complex BGP
policies. The modification proposed herein enables flow
specifications to be originated from a centralized BGP route
controller.
"Inter-domain SLA Exchange Attribute", Shitanshu Shah, Keyur Patel,
Sandeep Bajaj, Luis Tomotaki, Mohamed Boucadair, 2016-02-05,
<draft-ietf-idr-sla-exchange-08.txt>
Network administrators typically enforce Quality of Service (QoS)
policies according to Service Level Agreement (SLA) with their
providers. The enforcement of such policies often relies upon
vendor-specific configuration language. Both learning of SLA, either
thru SLA documents or via some other out-of-band method, and
translating them to vendor specific configuration language is a
complex, often manual, process and prone to errors.
This document specifies an optional transitive attribute to signal
SLA parameters in-band, across administrative boundaries (considered
as Autonomous Systems (AS)), thus simplifying and facilitating some
of the complex provisioning tasks in situations where BGP is
available as a routing protocol.
"Distribution of MPLS Traffic Engineering (TE) LSP State using BGP", Jie
Dong, Mach Chen, Hannes Gredler, Stefano Previdi, Jeff Tantsura,
2015-12-03, <draft-ietf-idr-te-lsp-distribution-04.txt>
This document describes a mechanism to collect the Traffic
Engineering (TE) LSP information using BGP. Such information can be
used by external components for path reoptimization, service
placement, and network visualization.
"Applying BGP flowspec rules on a specific interface set", Stephane
Litkowski, Adam Simpson, Keyur Patel, Jeffrey Haas, 2015-12-08,
<draft-litkowski-idr-flowspec-interfaceset-03.txt>
BGP Flow-spec is an extension to BGP that allows for the
dissemination of traffic flow specification rules. The primary
application of this extension is DDoS mitigation where the flowspec
rules are applied in most cases to all peering routers of the
network.
This document will present another use case of BGP Flow-spec where
flow specifications are used to maintain some access control lists at
network boundary. BGP Flowspec is a very efficient distributing
machinery that can help in saving OPEX while deploying/updating ACLs.
This new application requires flow specification rules to be applied
only on a specific subset of interfaces and in a specific direction.
The current specification of BGP Flow-spec does not detail where the

flow specification rules need to be applied.

This document presents a new interface-set flowspec action that will
be used in complement of other actions (marking, rate-limiting ...).
The purpose of this extension is to inform remote routers on where to
apply the flow specification.
This extension can also be used in a DDoS mitigation context where a
provider wants to apply the filtering only on specific peers.
"BGP Extensions for Service-Oriented MPLS Path Programming (MPP)",
Zhenbin Li, Shunwan Zhuang, Sujian Lu, 2016-05-05,
<draft-li-idr-mpls-path-programming-03.txt>
Service-oriented MPLS programming (SoMPP) is to provide customized
service process based on flexible label combinations. BGP will play
an important role for MPLS path programming to download programmed
MPLS path and map the service path to the transport path. This
document defines BGP extensions to support service-oriented MPLS path
programming.
"Route Target Constrained Distribution of Routes with no Route Targets",
Eric Rosen, Keyur Patel, Jeffrey Haas, Robert Raszuk, 2015-11-13,
<draft-ietf-idr-rtc-no-rt-04.txt>
There are a variety of BGP-enabled services in which the originator
of a BGP route may attach one or more "Route Targets" to the route.
By means of a procedure known as "RT Constrained Distribution" (RTC),
a given BGP speaker (call it "B") can announce the set of RTs in
which it has interest. The implication is that if a particular route
(call it "R") carries any RTs at all, BGP speaker B wants to receive
route R if and only if B has announced interest in one of the RTs
carried by R. However, if route R does not carry any RTs at all,
prior specifications do not make it clear whether B's use of RTC
implies that it does not want to receive route R. This has caused
interoperability problems in the field, as some implementations of
RTC do not allow B to receive R, but some services presuppose that B
will receive R. This document updates RFC 4684 by clarifying the
effect of the RTC mechanism on routes that do not have any RTs.
"BGP Persistent Route Oscillation Solutions", Daniel Walton, Alvaro
Retana, Enke Chen, John Scudder, 2016-04-30,
<draft-ietf-idr-route-oscillation-stop-03.txt>
This document presents two sets of paths for an address prefix that
can be advertised by a BGP route reflector or confederation ASBR to
eliminate the MED-induced route oscillations in a network. The first
set involves all the available paths, and would achieve the same
routing consistency as the full IBGP mesh. The second set, which is
a subset of the first one, involves the neighbor-AS based Group Best
Paths, and would be sufficient to eliminate the MED-induced route
oscillations.
"Advertising Per-node Admin Tags in BGP Link-State Advertisements",
Hannes Gredler, Stephane Litkowski, 2015-11-10,
<draft-psarkar-idr-bgp-ls-node-admin-tag-extension-03.txt,.pdf>
This document describes the protocol extensions to collect per-node
administrative tags adevertised in IGP Link State advertisements and
disseminate the same in BGP Link-State advertisement protocol, to

facilitate inter-AS TE applications that may need the same per-node

administrative tags to associate a subset of network devices spanning
across more than one AS with a specific functionality.
"Dissemination of Flow Specification Rules for L2 VPN", Hao Weiguo, LQD,
Stephane Litkowski, Shunwan Zhuang, 2015-11-15,
<draft-ietf-idr-flowspec-l2vpn-03.txt>
This document defines BGP flow-spec extension for Ethernet traffic
filtering in L2 VPN network. SAFI=134 in [RFC5575] is redefined for
dissemination traffic filtering information in an L2VPN environment.
A new subset of component types and extended community also are
defined.
"Distribution of MPLS-TE Extended admin Group Using BGP", Zitao Wang,
Qin Wu, Jeff Tantsura, 2015-12-07,
<draft-ietf-idr-eag-distribution-01.txt>
As MPLS-TE network grows, administrative Groups advertised as a
fixed-length 32-bit Bitmask is quite constraining. "Extended
Administrative Group" IGP TE extensions sub-TLV defined in [RFC7308]
is introduced to provide for additional administrative groups (link
colors) beyond the current limit of 32. This document describes
extensions to BGP protocol, that can be used to distribute extended
administrative groups in MPLS-TE.
"Segment Routing BGP Peer Engineering BGP-LS Extensions", Stefano
Previdi, Clarence Filsfils, Saikat Ray, Keyur Patel, Jie Dong, Mach
Chen, 2016-03-21, <draft-ietf-idr-bgpls-segment-routing-epe-03.txt>
Segment Routing (SR) leverages source routing. A node steers a
packet through a controlled set of instructions, called segments, by
prepending the packet with an SR header. A segment can represent any
instruction, topological or service-based. SR allows to enforce a
flow through any topological path and service chain while maintaining
per-flow state only at the ingress node of the SR domain.
The Segment Routing architecture can be directly applied to the MPLS
dataplane with no change on the forwarding plane. It requires minor
extension to the existing link-state routing protocols.
This document outline a BGP-LS extension for exporting BGP peering
node topology information (including its peers, interfaces and
peering ASs) in a way that is exploitable in order to compute
efficient BGP Peering Engineering policies and strategies.
"Wide BGP Communities Attribute", Robert Raszuk, Jeffrey Haas, Andrew
Lange, Shane Amante, Bruno Decraene, Paul Jakma, Richard Steenbergen,
2015-11-22, <draft-ietf-idr-wide-bgp-communities-01.txt>
Route tagging plays an important role in external BGP [RFC4271]
relations, in communicating various routing policies between peers.
It is also a very common best practice among operators to propagate
various additional information about routes intra-domain. The most
common tool used today to attach various information about routes is
through the use of BGP communities [RFC1997].
Such information is important to allow BGP speakers to perform some
mutually agreed actions without the need to maintain a separate
offline database for each tuple of prefix and associated set of

action entries.
This document defines a new encoding which will enhance and simplify
what can be accomplished today with the use of BGP communities. The
most important addition this specification makes over currently
defined BGP communities is the ability to specify, carry as well as
use for execution an operator's defined set of parameters. It also
provides an extensible platform for any new community encoding needs
in the future.
"Registered Wide BGP Community Values", Robert Raszuk, Jeffrey Haas,
2015-11-22, <draft-ietf-idr-registered-wide-bgp-communities-01.txt>
Communicating various routing policies via route tagging plays an
important role in external BGP peering relations. The most common
tool used today to attach various information about routes is
realized with the use of BGP communities. Such information is
important for the peering AS to perform some mutually agreed actions
without the need to maintain a separate offline database for each
pair of prefix and an associated with it requested set of action
entries.
This document proposes to establish a new IANA maintained registry of
most commonly used Wide BGP Communities by network operators. Such
public registry will allow for easy refernece and clear
interpretation of the actions associated with received community
values.
"Carrying Label Information for BGP FlowSpec", LQD, Susan Hares, Jianjie
You, Robert Raszuk, danma@cisco.com, 2016-03-21,
<draft-liang-idr-bgp-flowspec-label-02.txt>
This document specifies a method in which the label mapping
information for a particular FlowSpec rule is piggybacked in the same
Border Gateway Protocol (BGP) Update message that is used to
distribute the FlowSpec rule. Based on the proposed method, the
Label Switching Routers (LSRs) (except the ingress LSR) on the Label
Switched Path (LSP) can use label to indentify the traffic matching a
particular FlowSpec rule; this facilitates monitoring and traffic
statistics for FlowSpec rules.
"Dissemination of Flow Specification Rules for NVO3", Hao Weiguo,
Shunwan Zhuang, Zhenbin Li, Rong Gu, 2015-12-17,
<draft-hao-idr-flowspec-nvo3-03.txt>
This draft proposes a new subset of component types to support the
NVO3 flow-spec application.
"BGP Model for Service Provider Networks", Anees Shaikh, Rob Shakir,
Keyur Patel, Susan Hares, Kevin D'Souza, Deepak Bansal, Alex Clemm,
Alex, Mahesh Jethanandani, Xufeng Liu, 2016-01-07,
<draft-ietf-idr-bgp-model-01.txt>
This document defines a YANG data model for configuring and managing
BGP, including protocol, policy, and operational aspects based on
data center, carrier and content provider operational requirements.
"Methods for Detection and Mitigation of BGP Route Leaks", Kotikalapudi
Sriram, Doug Montgomery, Brian Dickson, Keyur Patel, Andrei Robachevsky,
2016-03-14, <draft-ietf-idr-route-leak-detection-mitigation-02.txt>

In [I-D.ietf-grow-route-leak-problem-definition], the authors have

provided a definition of the route leak problem, and also enumerated
several types of route leaks. In this document, we first examine
which of those route-leak types are detected and mitigated by the
existing origin validation (OV) [RFC 6811]. It is recognized that OV
offers a limited detection and mitigation capability against route
leaks. This document proposes an enhancement that significantly
extends the route-leak detection and mitigation capabilities of BGP.
The solution involves carrying a per-hop route-leak protection (RLP)
field in BGP updates. The RLP field is proposed be carried in an
optional transitive path attribute. The solution is meant to be
initially implemented as an enhancement of BGP without requiring
BGPsec [I-D.ietf-sidr-bgpsec-protocol]. However, when BGPsec is
deployed in the future, the solution can be incorporated in BGPsec,
enabling cryptographic protection for the RLP field. That would be
one way of implementing the proposed solution in a secure way. It is
not claimed that the solution detects all possible types of route
leaks but it detects several types, especially considering some
significant route-leak occurrences that have been observed in recent
years. The document also includes a stopgap method for detection and
mitigation of route leaks for an intermediate phase when OV is
deployed but BGP protocol on the wire is unchanged.
"Inter-domain SLA Exchange Implementation Report-01", Shitanshu Shah,
Keyur Patel, 2016-02-15, <draft-ietf-idr-sla-exchange-impl-01.txt>
This document is a report of implementations based on [IDR-SLA].
[IDR-SLA] introduces a new BGP attribute to exchange QoS SLA
parameters between BGP peers. Current status of the implementation
report covers Cisco implementation on 2 different OS, ExaBGP
implementation and inter-operability results between them.
"The BGP Tunnel Encapsulation Attribute", Eric Rosen, Keyur Patel,
Gunter Van de Velde, 2015-12-21, <draft-ietf-idr-tunnel-encaps-01.txt>
RFC 5512 defines a BGP Path Attribute known as the "Tunnel
Encapsulation Attribute". This attribute allows one to specify a set
of tunnels. For each such tunnel, the attribute can provide the
information needed to create the tunnel and the corresponding
encapsulation header. The attribute can also provide information
that aids in choosing whether a particular packet is to be sent
through a particular tunnel. RFC 5512 states that the attribute is
only carried in BGP UPDATEs that have the "Encapsulation Subsequent
Address Family (Encapsulation SAFI)". This document deprecates the
Encapsulation SAFI (which has never been used), and specifies
semantics for the attribute when it is carried in UPDATEs of certain
other SAFIs. This document adds support for additional tunnel types,
and allows a remote tunnel endpoint address to be specified for each
tunnel. This document also provides support for specifying fields of
any inner or outer encapsulations that may be used by a particular
tunnel.
This document obsoletes RFC 5512.
"Segment Routing Prefix SID extensions for BGP", Stefano Previdi,
Clarence Filsfils, Acee Lindem, Keyur Patel, Arjun Sreekantiah, Saikat
Ray, Hannes Gredler, 2015-12-21, <draft-ietf-idr-bgp-prefix-sid-02.txt>
Segment Routing (SR) architecture allows a node to steer a packet

flow through any topological path and service chain by leveraging

source routing. The ingress node prepends a SR header to a packet
containing a set of "segments". Each segment represents a
topological or a service-based instruction. Per-flow state is
maintained only at the ingress node of the SR domain.
This document describes the BGP extension for announcing BGP Prefix
Segment Identifier (BGP Prefix SID) information.
"Distribution of TRILL Link-State using BGP", Hao Weiguo, Donald
Eastlake, Susan Hares, Sujay Gupta, Muhammad Durrani, Li Yizhou,
2016-03-20, <draft-ietf-idr-ls-trill-01.txt,.pdf>
This draft describes a TRILL link state and MAC address reachability
information distribution mechanism using a BGP LS extension.
External components such as an SDN Controller can use the information
for topology visibility, troubleshooting, network automation, etc.
"Flowspec Indirection-id Redirect", Gunter Van de Velde, Wim Henderickx,
Keyur Patel, Arjun Sreekantiah, 2016-03-17,
<draft-vandevelde-idr-flowspec-path-redirect-02.txt>
Flow-spec is an extension to BGP that allows for the dissemination of
traffic flow specification rules. This has many possible
applications but the primary one for many network operators is the
distribution of traffic filtering actions for DDoS mitigation. The
flow-spec standard RFC5575 [2] defines a redirect-to-VRF action for
policy-based forwarding but this mechanism is not always sufficient,
particular if the redirected traffic needs to be steered into an
engineered path or into a service plane.
This document defines a new redirect-to-INDIRECTION_ID (32-bit or
128-bit) flow-spec action to provide advanced redirection
capabilities. When activated, the flowspec Indirection-id is used to
identify the next-hop redirect information within a router locallized
Indirection-id table. This allows a flowspec controller to signal
redirection towards a next-hop IP address, a shortest path tunnel, a
traffic engineered tunnel or a next-next-hop engineered tunnel
interface.
"BGP Flow-Spec Redirect to Tunnel Action", Hao Weiguo, Zhenbin Li, Lucy
Yong, 2016-03-18, <draft-hao-idr-flowspec-redirect-tunnel-01.txt>
This draft defines a new flow-spec action, Redirect-to-Tunnel, and a
new sub-TLV for Redirect-to-Tunnel extended community. A BGP UPDATE
for a flow-spec NLRI can contain the extended community. When
activated, the corresponding flow packets will be encapsulated and
carried via a tunnel. The redirect tunnel information is encoded in
BGP Path Attribute or extended community [TUNNELENCAPS][MPP] that is
carried in the BGP flow-spec UPDATE. The draft expends the tunnel
encapsulation attribute [TUNNELENCAPS] to apply to flow-spec SAFI,
i.e., 133 and 134.
"BGP Flow Specification Packet-Rate Action", Wesley Eddy, Justin Dailey,
Gilbert Clark, 2015-11-22, <draft-eddy-idr-flowspec-packet-rate-00.txt>
This document defines a new type of traffic filtering action for the
BGP flow specification. The new packet-rate action allows specifying
a rate-limit in number of packets per second.

"An Information Model for Basic Network Policy and Filter Rules", Susan
Hares, 2016-03-05, <draft-hares-idr-flowspec-combo-01.txt,.pdf>
BGP flow specification (RFC5575) describes the distribution policy
that contains filters and actions that apply when packets are
received on a router with the flow specification function turned on.
The popularity of these flow specification filters in deployment for
DoS and SDN/NFV has led to the requirement for more BGP flow
specification match filters in the NLRI and more BGP flow
specification actions. Two solutions exist for adding new filters:
1) expanding the BGP Flow Specification version 1 (NLRI match filters
and extended communities actions) to included limited number of
filters and actions, and 2) creating a BGP Flow Specification version
2 that allows for ordering filters and actions (using new NLRI and
wide-communities for actions). The two solutions can exist in
parallel.
This document contains an overview existing proposals for expansion
of BGP flow specification policy, proposals for BGP Flow
Specification v1 and a new BGP Flow specification version 2 that
supports order of filters and actions plus allowing more actions.
This document also provides rules for the interaction of IDR Flow
Specification policy (session ephemeral policy) with policy found in
I2RS (reboot ephemeral policy), and policy found in ACLs and Policy
routing (configuration policy). This document does not contain the
individual definitions of policy rule conditions or actions.
"BGP Flow Specification Filter for MPLS Label", Lucy Yong, Susan Hares,
LQD, Jianjie You, 2016-03-21,
<draft-yong-idr-flowspec-mpls-match-00.txt,.pdf>
This draft proposes BGP flow specification rules that are used to
filter MPLS labeled packets.
"BGP FlowSpec Redirect to Generalized Segment ID Action", Zhenbin Li,
Shunwan Zhuang, Nan Wu, 2016-03-21,
<draft-li-idr-flowspec-redirect-generalized-sid-00.txt>
This document defines a new type of the redirect extended community,
called as Redirect to Generalized Segment ID Extended Community.
When activated, the Redirect to Generalized Segment ID Extended
Community is used by BGP FlowSpec Controller to signal the specific
redirecting action to BGP Flowspec Client, and then the BGP Flowspec
Client will use the Generalized Segment ID and the Segment Type to
find a local forwarding entity in a local mapping table.
IMAP APPEND Extensions (imapapnd)
--------------------------------"The IMAP APPENDLIMIT Extension", Jay, Narendra Bisht, 2016-01-08,
<draft-ietf-imapapnd-appendlimit-extension-10.txt>
This document defines an extension to the IMAP service whereby a
server can inform the client about maximum message upload sizes,
allowing the client to avoid sending APPEND commands that will fail
because the messages are too large.
"IMAP4 non-synchronizing literals", Alexey Melnikov, 2016-03-06,
<draft-ietf-imapapnd-rfc2088bis-04.txt>

The Internet Message Access Protocol (RFC 3501) contains the

"literal" syntactic construct for communicating strings. When
sending a literal from client to server, IMAP requires the client to
wait for the server to send a command continuation request between
sending the octet count and the string data. This document specifies
an alternate form of literal that does not require this network round
trip.
This document specifies 2 IMAP extensions: LITERAL+ and LITERAL-.
LITERAL+ allows the alternate form of literals in all IMAP commands.
LITERAL- is the same as LITERAL+, but disallows the alternate form of
literals unless they are 4096 bytes or less.
This document obsoletes RFC 2088.
INtermediary-safe SIP session ID (insipid)
-----------------------------------------"End-to-End Session Identification in IP-Based Multimedia Communication
Networks", Paul Jones, Gonzalo Salgueiro, Chris Pearce, Paul Giralt,
2016-04-29, <draft-ietf-insipid-session-id-22.txt>
This document describes an end-to-end Session Identifier for use in
IP-based multimedia communication systems that enables endpoints,
intermediary devices, and management systems to identify a session
end-to-end, associate multiple endpoints with a given multipoint
conference, track communication sessions when they are redirected,
and associate one or more media flows with a given communication
session.
This document also describes a backwards compatibility mechanism for
an existing session identifier implementation (RFC 7329) that is
sufficiently different from the procedures defined in this document.
This document obsoletes RFC 7329.
"Requirements for Marking SIP Messages to be Logged", Peter Dawes,
Chidambaram Arunachalam, 2016-01-11,
<draft-ietf-insipid-logme-reqs-06.txt>
SIP networks use signalling monitoring tools to debug customer
reported problems and for regression testing if network or client
software is upgraded. As networks grow and become interconnected,
including connection via transit networks, it becomes impractical to
predict the path that SIP signalling will take between clients, and
therefore impractical to monitor SIP signalling end-to-end.
This draft describes requirements for adding an indicator to the SIP
protocol data unit (PDU, or a SIP message) that marks the PDU as a
candidate for logging. Such marking will typically be applied as
part of network testing controlled by the network operator and not
used in regular client signalling. However, such marking can be
carried end-to-end including the SIP terminals, even if a session
originates and terminates in different networks.
"Marking SIP Messages to be Logged", Peter Dawes, 2016-02-22,
<draft-ietf-insipid-logme-marking-04.txt>
SIP networks use signalling monitoring tools to diagnose user
reported problems and for regression testing if network or user agent

software is upgraded. As networks grow and become interconnected,

including connection via transit networks, it becomes impractical to
predict the path that SIP signalling will take between user agents,
and therefore impractical to monitor SIP signalling end-to-end.
This document describes an indicator for the SIP protocol which can
be used to mark signalling as of interest to logging. Such marking
will typically be applied as part of network testing controlled by
the network operator and not used in regular user agent signalling.
However, such marking can be carried end-to-end including the SIP
user agents, even if a session originates and terminates in different
networks.
Internet Area Working Group (intarea)
------------------------------------"IP Tunnels in the Internet Architecture", Joseph Touch, W. Townsley,
2016-01-25, <draft-ietf-intarea-tunnels-02.txt>
This document discusses the role of IP tunnels in the Internet
architecture. It explains their relationship to existing protocol
layers and the challenges in supporting IP tunneling based on the
equivalence of tunnels to links.
"IP over Intentionally Partially Partitioned Links", Erik Nordmark,
2016-03-21, <draft-nordmark-intarea-ippl-03.txt>
IP makes certain assumptions about the L2 forwarding behavior of a
multi-access IP link. However, there are several forms of
intentional partitioning of links ranging from split-horizon to
Private VLANs that violate some of those assumptions. This document
specifies that link behavior and how IP handles links with those
properties.
"Current Hostname Practice Considered Harmful", Christian Huitema, Dave
Thaler, 2016-04-15, <draft-ietf-intarea-hostname-practice-01.txt>
Giving a hostname to your computer and publishing it
one network to another is the Internet equivalent of
with a name tag affixed to your lapel. This current
significantly compromise your privacy, and something
order to mitigate these privacy threads.

as you roam from

walking around
practice can
should change in

There are several possible remedies, such as fixing a variety of

protocols or avoiding disclosing a hostname at all. This document
describes some of the protocols that reveal hostnames today and
sketches another possible remedy, which is to replace static
hostnames by frequently changing randomized values.
"Multi-hop Ad Hoc Wireless Communication", Emmanuel Baccelli, Charles
Perkins, 2016-01-29, <draft-ietf-intarea-adhoc-wireless-com-01.txt>
This document
interfaces in
engineers and
solutions for

describes characteristics of communication between

a multi-hop ad hoc wireless network, that protocol
system analysts should be aware of when designing
ad hoc networks at the IP layer.

IP Performance Metrics (ippm)

-----------------------------

"Registry for Performance Metrics", Marcelo Bagnulo, Benoit Claise,

Philip Eardley, Al Morton, Aamer Akhter, 2016-03-21,
<draft-ietf-ippm-metric-registry-06.txt>
This document defines the format for the Performance Metrics registry
and defines the IANA Registry for Performance Metrics. This document
also gives a set of guidelines for Registered Performance Metric
requesters and reviewers.
"IPv6 Performance and Diagnostic Metrics (PDM) Destination Option",
Nalini Elkins, Rob, mackermann@bcbsm.com, 2016-04-11,
<draft-ietf-ippm-6man-pdm-option-02.txt>
To assess performance problems, measurements based on optional
sequence numbers and timing may be embedded in each packet. Such
measurements may be interpreted in real-time or after the fact. An
implementation of the existing IPv6 Destination Options extension
header, the Performance and Diagnostic Metrics (PDM) Destination
Options extension header as well as the field limits, calculations,
and usage of the PDM in measurement are included in this document.
"Active and Passive Metrics and Methods (and everything in-between, or
Hybrid)", Al Morton, 2016-01-23, <draft-ietf-ippm-active-passive-06.txt>
This memo provides clear definitions for Active and Passive
performance assessment. The construction of Metrics and Methods can
be described as Active or Passive. Some methods may use a subset of
both active and passive attributes, and we refer to these as Hybrid
Methods. This memo also describes multiple dimensions to help
evaluate new methods as they emerge.
"Initial Performance Metric Registry Entries", Al Morton, Marcelo
Bagnulo, Philip Eardley, Kevin D'Souza, 2016-02-21,
<draft-morton-ippm-initial-registry-04.txt>
This memo defines the Initial Entries for the Performance Metrics
Registry.
Version 04 * All section 4 parameters reference YANG types for
alternate data formats. * Discussion has concluded that usecase(s)
for machine parse-able registry columns are not needed.
Still need: * suggestion of standard naming format for parameters. *
revisions that follow section 4 changes in other proposed metrics.
"Initial Performance Metric Registry Entries", Al Morton, Marcelo
Bagnulo, Philip Eardley, Kevin D'Souza, 2016-03-12,
<draft-ietf-ippm-initial-registry-00.txt>
This memo defines the Initial Entries for the Performance Metrics
Registry.
WG 00 is the same as Individual 04, which was updated 3 times since
IETF-94.
Version 04 * All section 4 parameters reference YANG types for
alternate data formats. * Discussion has concluded that usecase(s)
for machine parse-able registry columns are not needed.
Still need: * suggestion of standard naming format for parameters. *

revisions that follow section 4 changes in other proposed metrics.

"Two-Way Active Measurement Protocol (TWAMP) Data Model", Ruth Civil, Al
Morton, Lianshu Zheng, Reshad Rahman, Mahesh Jethanandani, Kostas
Pentikousis, 2016-03-21, <draft-ietf-ippm-twamp-yang-00.txt>
This document specifies a data model for client and server
implementations of the Two-Way Active Measurement Protocol (TWAMP).
We define the TWAMP data model through Unified Modeling Language
(UML) class diagrams and formally specify it using YANG.
IP Security Maintenance and Extensions (ipsecme)
-----------------------------------------------"Protecting Internet Key Exchange Protocol version 2 (IKEv2)
Implementations from Distributed Denial of Service Attacks", Yoav Nir,
Valery Smyslov, 2016-04-15, <draft-ietf-ipsecme-ddos-protection-06.txt>
This document recommends implementation and configuration best
practices for Internet Key Exchange Protocol version 2 (IKEv2)
Responders, to allow them to resist Denial of Service and Distributed
Denial of Service attacks. Additionally, the document introduces a
new mechanism called "Client Puzzles" that help accomplish this task.
"Curve25519 and Curve448 for IKEv2 Key Agreement", Yoav Nir, Simon
Josefsson, 2016-02-01, <draft-ietf-ipsecme-safecurves-01.txt>
This document describes the use of Curve25519 and Curve448 for
ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol.
"Algorithm Implementation Requirements and Usage Guidance for IKEv2",
Yoav Nir, Tero Kivinen, Paul Wouters, Daniel Migault, 2016-04-07,
<draft-ietf-ipsecme-rfc4307bis-07.txt>
The IPsec series of protocols makes use of various cryptographic
algorithms in order to provide security services. The Internet Key
Exchange (IKE) protocol is used to negotiate the IPsec Security
Association (IPsec SA) parameters, such as which algorithms should be
used. To ensure interoperability between different implementations,
it is necessary to specify a set of algorithm implementation
requirements and usage guidance to ensure that there is at least one
algorithm that all implementations support. This document defines
the current algorithm implementation requirements and usage guidance
for IKEv2. This document does not update the algorithms used for
packet encryption using IPsec Encapsulated Security Payload (ESP).
IS-IS for IP Internets (isis)
----------------------------"IS-IS Traffic Engineering (TE) Metric Extensions", Stefano Previdi,
Spencer Giacalone, David Ward, John Drake, Wenson Wu, 2016-02-12,
<draft-ietf-isis-te-metric-extensions-11.txt>
In certain networks, such as, but not limited to, financial
information networks (e.g. stock market data providers), network
performance criteria (e.g. latency) are becoming as critical to data
path selection as other metrics.
This document describes extensions to IS-IS Traffic Engineering
Extensions (RFC5305) such that network performance information can be

distributed and collected in a scalable fashion. The information

distributed using IS-IS TE Metric Extensions can then be used to make
path selection decisions based on network performance.
Note that this document only covers the mechanisms with which network
performance information is distributed. The mechanisms for measuring
network performance or acting on that information, once distributed,
are outside the scope of this document.
"IS-IS Extensions for Segment Routing", Stefano Previdi, Clarence
Filsfils, Ahmed Bashandy, Hannes Gredler, Stephane Litkowski, Bruno
Decraene, Jeff Tantsura, 2015-12-14,
<draft-ietf-isis-segment-routing-extensions-06.txt>
Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS and OSPF).
This draft describes the necessary IS-IS extensions that need to be
introduced for Segment Routing.
"IS-IS Extensions for Flow Specification", Jianjie You, LQD, Keyur
Patel, Peng Fan, Zhenqiang Li, 2016-02-14,
<draft-you-isis-flowspec-extensions-04.txt>
Dissemination of the Traffic flow information was first introduced in
the BGP protocol [RFC5575]. FlowSpec rules are used to distribute
traffic filtering rules that are used to filter Denial-of-Service
(DoS) attacks. For the networks that only deploy IS-IS or IS-IS
variant, it is required that IS-IS is extended to distribute Flow
Specification or FlowSpec rules.
This document discusses the use cases for distributing flow
specification (FlowSpec) routes using IS-IS. Furthermore, this
document defines a new IS-IS FlowSpec Reachability TLV encoding
format that can be used to distribute FlowSpec rules, its validation
procedures for imposing the filtering information on the routers, and
a capability to indicate the support of FlowSpec functionality.
"Advertising S-BFD Discriminators in IS-IS", Les Ginsberg, Nobo Akiya,
Mach Chen, 2015-03-01, <draft-ietf-isis-sbfd-discriminator-02.txt>
This document defines a means of advertising one or more S-BFD
Discriminators using the IS-IS Router Capability TLV.
"YANG Data Model for IS-IS protocol", Stephane Litkowski, Derek Yeung,
Acee Lindem, Jeffrey Zhang, Ladislav Lhotka, 2016-03-21,
<draft-ietf-isis-yang-isis-cfg-08.txt>
This document defines a YANG data model that can be used to configure
and manage IS-IS protocol on network elements. It also defined an
extension module for segment routing configuration and operation.
"Advertising Node Administrative Tags in IS-IS", P. Sarkar, Hannes
Gredler, Shraddha Hegde, Stephane Litkowski, Bruno Decraene, 2016-05-02,
<draft-ietf-isis-node-admin-tag-10.txt,.pdf>
This document describes an extension to the IS-IS routing protocol to
add an optional capability that allows tagging and grouping of the

nodes in an IS-IS domain. This allows simple management and easy

control over route and path selection, based on local configured
policies. This document describes an extension to the IS-IS protocol
to advertise node administrative tags. The node administrative tags
can be used to express and apply locally defined network policies
which is a very useful operational capability. Node administrative
tags may be used either by IS-IS itself or by other applications
consuming information propagated via IS-IS.
This document describes the protocol extensions to disseminate node
administrative tags in IS-IS protocols.
"IS-IS Path Computation and Reservation", Janos Farkas, Nigel Bragg,
Paul Unbehagen, Glenn Parsons, Peter Ashwood-Smith, Chris Bowers,
2016-02-11, <draft-ietf-isis-pcr-05.txt,.pdf>
IEEE 802.1Qca Path Control and Reservation (PCR) specifies explicit
path control via IS-IS in Layer 2 networks in order to move beyond
the shortest path capabilities provided by IEEE 802.1aq Shortest Path
Bridging (SPB). IS-IS PCR provides capabilities for the
establishment and control of explicit forwarding trees in a Layer 2
network domain. This document specifies the sub-TLVs for IS-IS PCR.
"Signaling Entropy Label Capability Using IS-IS", Xiaohu Xu, Sriganesh
Kini, Siva Sivabalan, Clarence Filsfils, Stephane Litkowski, 2015-11-10,
<draft-ietf-isis-mpls-elc-01.txt>
Multi Protocol Label Switching (MPLS) has defined a mechanism to load
balance traffic flows using Entropy Labels (EL). An ingress LSR
cannot insert ELs for packets going into a given tunnel unless an
egress LSR has indicated that it can process ELs for that tunnel.
This draft defines a mechanism to signal that capability using IS-IS.
This mechanism is useful when the label advertisement is also done
via IS-IS.
"ISIS Auto-Configuration", Bing Liu, Bruno Decraene, Ian Farrer, Mikael
Abrahamsson, Les Ginsberg, 2015-11-29,
<draft-ietf-isis-auto-conf-00.txt>
This document specifies an IS-IS auto-configuration technology. The
key mechanisms of this technology are IS-IS System ID selfgeneration, duplication detection and duplication resolution. This
technology fits the environment where plug-and-play is expected.
"IS-IS Multi-Instance", Les Ginsberg, Stefano Previdi, Wim Henderickx,
2016-04-20, <draft-ginsberg-isis-mi-bis-01.txt>
This draft describes a mechanism that allows a single router to share
one or more circuits among multiple Intermediate System To
Intermediate System (IS-IS) routing protocol instances.
Multiple instances allow the isolation of resources associated with
each instance. Routers will form instance specific adjacencies.
Each instance can support multiple topologies. Each topology has a
unique Link State Database (LSDB). Each Protocol Data Unit (PDU)
will contain a new Type Length Value (TLV) identifying the instance
and the topology(ies) to which the PDU belongs.
"IS-IS Minimum Remaining Lifetime", Les Ginsberg, Paul Wells, Stefano
Previdi, Bruno Decraene, A. Przygienda, Hannes Gredler, 2016-04-30,

<draft-ietf-isis-remaining-lifetime-01.txt>
Corruption of the Remainining Lifetime Field in a Link State PDU can
go undetected. In certain scenarios this may cause or exacerbate
flooding storms. It is also a possible denial of service attack
vector. This document defines a backwards compatible solution to
this problem.
"IS-IS Extensions for Advertising Router Info", Les Ginsberg, Stefano
Previdi, Mach Chen, 2016-04-13, <draft-ietf-isis-rfc4971bis-01.txt>
This document defines a new optional Intermediate System to
Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple
sub-TLVs, which allows a router to announce its capabilities within
an IS-IS level or the entire routing domain.
"Advertising L2 Bundle Member Link Attributes in IS-IS", Les Ginsberg,
Jerome Marcon, Clarence Filsfils, Stefano Previdi, Mohan Nanduri, exa,
2016-02-22, <draft-ietf-isis-l2bundles-01.txt>
There are deployments where the Layer 3 interface on which IS-IS
operates is a Layer 2 interface bundle. Existing IS-IS
advertisements only support advertising link attributes of the Layer
3 interface. If entities external to IS-IS wish to control traffic
flows on the individual physical links which comprise the Layer 2
interface bundle link attribute information about the bundle members
is required.
This document introduces the ability for IS-IS to advertise the link
attributes of layer 2 (L2) bundle members.
Javascript Object Signing and Encryption (jose)
----------------------------------------------"CFRG ECDH and signatures in JOSE", Ilari Liusvaara, 2016-03-21,
<draft-ietf-jose-cfrg-curves-01.txt>
This document defines how to use Diffie-Hellman algorithms "X25519"
and "X448" as well as signature algorithms "Ed25519" and "Ed448" from
IRTF CFRG elliptic curves work in JOSE.
Font Top Level Media Type (justfont)
-----------------------------------"The font Top Level Type", Chris Lilley, 2016-05-03,
<draft-ietf-justfont-toplevel-02.txt>
This memo serves to register and document the "font" Top Level Type,
under which the Internet Media subtypes for representation formats
for fonts may be registered. This document also serves as a
registration application for a set of intended subtypes, which are
representative of some existing subtypes already in use, and
currently registered under the "application" tree by their separate
registrations.
Common Authentication Technology Next Generation (kitten)
--------------------------------------------------------"AES Encryption with HMAC-SHA2 for Kerberos 5", Michael Jenkins, Michael
Peck, Kelley Burgin, 2016-01-26,

<draft-ietf-kitten-aes-cts-hmac-sha2-09.txt>
This document specifies two encryption types and two corresponding
checksum types for Kerberos 5. The new types use AES in CTS mode
(CBC mode with ciphertext stealing) for confidentiality and HMAC with
a SHA-2 hash for integrity.
"Generic Security Service API Version 2: Java Bindings Update", Mayank
Upadhyay, Seema Malkani, Wang Weijun, 2016-04-06,
<draft-ietf-kitten-rfc5653bis-03.txt>
The Generic Security Services Application Program Interface (GSS-API)
offers application programmers uniform access to security services
atop a variety of underlying cryptographic mechanisms. This document
updates the Java bindings for the GSS-API that are specified in
"Generic Security Service API Version 2 : Java Bindings Update" (RFC
5653). This document obsoletes RFC 5653 by adding a new output token
field to the GSSException class so that when the initSecContext or
acceptSecContext methods of the GSSContext class fails it has a
chance to emit an error token which can be sent to the peer for
debugging or informational purpose. The stream-based GSSContext
methods are also removed in this version.
The GSS-API is described at a language-independent conceptual level
in "Generic Security Service Application Program Interface Version 2,
Update 1" (RFC 2743). The GSS-API allows a caller application to
authenticate a principal identity, to delegate rights to a peer, and
to apply security services such as confidentiality and integrity on a
per-message basis. Examples of security mechanisms defined for GSSAPI are "The Simple Public-Key GSS-API Mechanism" (RFC 2025) and "The
Kerberos Version 5 Generic Security Service Application Program
Interface (GSS-API) Mechanism: Version 2" (RFC 4121).
"Public Key Cryptography for Initial Authentication in Kerberos (PKINIT)
Freshness Extension", Michiko Short, Seth Moore, Paul Miller,
2016-04-08, <draft-ietf-kitten-pkinit-freshness-06.txt,.pdf>
This document describes how to further extend the Public Key
Cryptography for Initial Authentication in Kerberos (PKINIT)
extension [RFC4556] to exchange an opaque data blob that a KDC can
validate to ensure that the client is currently in possession of the
private key during a PKINIT AS exchange.
Layer Two Tunneling Protocol Extensions (l2tpext)
------------------------------------------------"Keyed IPv6 Tunnel", Maciek Konstantynowicz, Giles Heron, Rainer
Schatzmayr, Wim Henderickx, 2016-03-21,
<draft-ietf-l2tpext-keyed-ipv6-tunnel-06.txt>
This document describes a simple L2 Ethernet over IPv6 tunnel
encapsulation with mandatory 64-bit cookie for connecting L2 Ethernet
attachment circuits identified by IPv6 addresses. The encapsulation
is based on L2TPv3 over IP.
"Advertising Seamless Bidirectional Forwarding Detection (S-BFD)
Discriminators in Layer Two Tunneling Protocol, Version 3 (L2TPv3)",
Vengada Govindan, Carlos Pignataro, 2016-04-15,
<draft-ietf-l2tpext-sbfd-discriminator-05.txt>

This document defines a new Attribute Value Pair (AVP) that allows
L2TP Control Connection Endpoints (LCCEs) to advertise one or more
Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator
values using the Layer Two Tunneling Protocol, Version 3 (L2TPv3).
"A YANG Data Model for Keyed IPv6 Tunnels", Qi Sun, Ian Farrer, Bing
Liu, Giles Heron, 2016-03-21,
<draft-ietf-l2tpext-keyed-v6-tunnel-yang-01.txt>
This document
management of
configuration
IPv6 tunnels,

defines a YANG data model for the configuration and

Keyed IPv6 tunnels. The data model includes both
and state data. Due to the stateless nature of keyed
a model for NETCONF notifications is not necessary.

L3VPN Service Model (l3sm)

--------------------------"YANG Data Model for L3VPN service delivery", Stephane Litkowski, Rob
Shakir, Luis Tomotaki, Kenichi Ogaki, Kevin D'Souza, 2016-05-02,
<draft-ietf-l3sm-l3vpn-service-model-06.txt>
This document defines a YANG data model that can be used to deliver a
Layer 3 Provider Provisioned VPN service. The document is limited to
the BGP PE-based VPNs as described in RFC4110 and RFC4364. This
model is intended to be instantiated at management system to deliver
the overall service. This model is not a configuration model to be
used directly on network elements. This model provides an abstracted
view of the Layer 3 IPVPN service configuration components. It will
be up to a management system to take this as an input and use
specific configurations models to configure the different network
elements to deliver the service. How configuration of network
elements is done is out of scope of the document.
Label Generation Rules (lager)
-----------------------------"Representing Label Generation Rulesets using XML", Kim Davies, Asmus
Freytag, 2016-03-20, <draft-ietf-lager-specification-11.txt>
This document describes a method of representing rules for validating
identifier labels and alternate representations of those labels using
Extensible Markup Language (XML). These policies, known as "Label
Generation Rulesets" (LGRs), are used for the implementation of
Internationalized Domain Names (IDNs), for example. The rulesets are
used to implement and share that aspect of policy defining which
labels and Unicode code points are permitted for registrations, which
alternative code points are considered variants, and what actions may
be performed on labels containing those variants.
Layer Independent OAM Management in the Multi-Layer Environment (lime)
---------------------------------------------------------------------"Generic YANG Data Model for Connection Oriented Operations,
Administration, and Maintenance(OAM) protocols", Tissa Senevirathne,
Norman Finn, Deepak Kumar, Samer Salam, Qin Wu, Zitao Wang, 2016-04-22,
<draft-ietf-lime-yang-oam-model-04.txt>
This document presents a base YANG Data model for connection oriented
OAM protocols. It provides a technology-independent abstraction of
key OAM constructs for connection oriented protocols. Based model

presented here can be extended to include technology specific

details. This is leading to uniformity between OAM protocols and
support nested OAM workflows (i.e., performing OAM functions at
different levels through a unified interface).
"Generic YANG Data Model for Connection Less Operations, Administration,
and Maintenance(OAM) protocols", Deepak Kumar, Zitao Wang, Qin Wu,
Reshad Rahman, 2016-04-06,
<draft-kumar-lime-yang-connectionless-oam-02.txt>
This document presents a base YANG Data model for connectionless OAM
protocols. It provides a technology-independent abstraction of key
OAM constructs for connectionless protocols. Based model presented
here can be extended to include technology specific details. This is
leading to uniformity between OAM protocols and support nested OAM
workflows (i.e., performing OAM functions at different or same levels
through a unified interface).
Locator/ID Separation Protocol (lisp)
------------------------------------"LISP EID Block", Luigi Iannone, Darrel Lewis, David Meyer, Vince
Fuller, 2016-02-26, <draft-ietf-lisp-eid-block-13.txt>
This is a direction to IANA to allocate
with the Locator/ID Separation Protocol
used for local intra-domain routing and
identification, by sites deploying LISP
addressing space.

a /32 IPv6 prefix for use

(LISP). The prefix will be
global endpoint
as EID (Endpoint IDentifier)

"LISP-Security (LISP-SEC)", Fabio Maino, Vina Ermagan, Albert

Cabellos-Aparicio, Damien Saucez, 2016-04-13,
<draft-ietf-lisp-sec-10.txt>
This memo specifies LISP-SEC, a set of security mechanisms that
provides origin authentication, integrity and anti-replay protection
to LISP's EID-to-RLOC mapping data conveyed via mapping lookup
process. LISP-SEC also enables verification of authorization on EIDprefix claims in Map-Reply messages.
"LISP Canonical Address Format (LCAF)", Dino Farinacci, David Meyer, Job
Snijders, 2016-05-03, <draft-ietf-lisp-lcaf-13.txt>
This draft defines a canonical address format encoding used in LISP
control messages and in the encoding of lookup keys for the LISP
Mapping Database System.
"LISP Delegated Database Tree", Vince Fuller, Darrel Lewis, Vina
Ermagan, Amit Jain, Anton Smirnov, 2016-04-26,
<draft-ietf-lisp-ddt-06.txt>
This draft describes the LISP Delegated Database Tree (LISP-DDT), a
hierarchical, distributed database which embodies the delegation of
authority to provide mappings from LISP Endpoint Identifiers (EIDs)
to Routing Locators (RLOCs). It is a statically-defined distribution
of the EID namespace among a set of LISP-speaking servers, called DDT
nodes. Each DDT node is configured as "authoritative" for one or
more EID-prefixes, along with the set of RLOCs for Map Servers or
"child" DDT nodes to which more-specific EID-prefixes are delegated.

"An Architectural Introduction to the Locator/ID Separation Protocol

(LISP)", Albert Cabellos-Aparicio, Damien Saucez, 2015-04-02,
<draft-ietf-lisp-introduction-13.txt>
This document describes the architecture of the Locator/ID Separation
Protocol (LISP), making it easier to read the rest of the LISP
specifications and providing a basis for discussion about the details
of the LISP protocols. This document is used for introductory
purposes, more details can be found in RFC6830, the protocol
specification.
"LISP EID Block Management Guidelines", Luigi Iannone, Roger Jorgensen,
David Conrad, Geoff Huston, 2016-04-06,
<draft-ietf-lisp-eid-block-mgmnt-07.txt>
This document proposes a framework for the management of the LISP EID
Address Block. The framework described relies on hierarchical
distribution of the address space, granting temporary usage of
prefixes of such space to requesting organizations.
"LISP Data-Plane Confidentiality", Dino Farinacci, Brian Weis,
2015-12-04, <draft-ietf-lisp-crypto-03.txt>
This document describes a mechanism for encrypting LISP encapsulated
traffic. The design describes how key exchange is achieved using
existing LISP control-plane mechanisms as well as how to secure the
LISP data-plane from third-party surveillance attacks.
"LISP Configuration YANG Model", Vina Ermagan, Alberto Rodriguez-Natal,
Florin Coras, Carl Moberg, Albert Cabellos-Aparicio, Fabio Maino,
2015-12-17, <draft-ietf-lisp-yang-01.txt>
This document describes a YANG data model to use with the Locator/ID
Separation Protocol (LISP).
"Signal-Free LISP Multicast", Victor Moreno, Dino Farinacci, 2016-04-21,
<draft-ietf-lisp-signal-free-multicast-01.txt>
When multicast sources and receivers are active at LISP sites, the
core network is required to use native multicast so packets can be
delivered from sources to group members. When multicast is not
available to connect the multicast sites together, a signal-free
mechanism can be used to allow traffic to flow between sites. The
mechanism within here uses unicast replication and encapsulation over
the core network for the data-plane and uses the LISP mapping
database system so encapsulators at the source LISP multicast site
can find de-capsulators at the receiver LISP multicast sites.
Large-Scale Measurement of Broadband Performance (lmap)
------------------------------------------------------"Information Model for Large-Scale Measurement Platforms (LMAP)", Trevor
Burbridge, Philip Eardley, Marcelo Bagnulo, Jrgen Schnwlder,
2016-03-21, <draft-ietf-lmap-information-model-09.txt>
This Information Model applies to the Measurement Agent within a
Large-Scale Measurement Platform. As such it outlines the
information that is (pre-)configured on the Measurement Agent or
exists in communications with a Controller or Collector within an
LMAP framework. The purpose of such an Information Model is to

provide a protocol and device independent view of the Measurement

Agent that can be implemented via one or more Control and Report
protocols.
"A YANG Data Model for LMAP Measurement Agents", Jrgen Schnwlder,
Vaibhav Bajpai, 2016-03-21, <draft-ietf-lmap-yang-04.txt>
This document defines a data model for Large-Scale Measurement
Platforms (LMAP). The data model is defined using the YANG data
modeling language.
"Using RESTCONF with LMAP Measurement Agents", Jrgen Schnwlder,
Vaibhav Bajpai, 2016-03-21, <draft-ietf-lmap-restconf-02.txt>
This document describes how RESTCONF can be used with a YANG data
model for Large-Scale Measurement Platforms (LMAP).
Light-Weight Implementation Guidance (lwig)
------------------------------------------"Building Power-Efficient CoAP Devices for Cellular Networks", Jari
Arkko, Anders Eriksson, Ari Keranen, 2016-01-04,
<draft-ietf-lwig-cellular-06.txt>
This memo discusses the use of the Constrained Application Protocol
(CoAP) protocol in building sensors and other devices that employ
cellular networks as a communications medium. Building communicating
devices that employ these networks is obviously well known, but this
memo focuses specifically on techniques necessary to minimize power
consumption.
"Energy-Efficient Features of Internet of Things Protocols", Carles
Gomez, Matthias Kovatsch, Hui Tian, Zhen Cao, 2016-02-25,
<draft-ietf-lwig-energy-efficient-04.txt>
This document describes the problems and current practices of energy
efficient protocol operation on constrained devices. It summarizes
the main link layer techniques for energy efficient networking, and
it highlights the impact of such techniques on the upper layer
protocols, so that they can coordinately achieve an energy efficient
behavior. The document also provides an overview of energy efficient
mechanisms available at each layer of the constrained node network
IETF protocol suite.
Mobile Ad-hoc Networks (manet)
-----------------------------"Dynamic Link Exchange Protocol (DLEP)", Stan Ratliff, Jerome Marcon,
Shawn Jury, Darryl Satterwhite, Rick Taylor, 2016-04-07,
<draft-ietf-manet-dlep-22.txt>
When routing devices rely on modems to effect communications over
wireless links, they need timely and accurate knowledge of the
characteristics of the link (speed, state, etc.) in order to make
routing decisions. In mobile or other environments where these
characteristics change frequently, manual configurations or the
inference of state through routing or transport protocols does not
allow the router to make the best decisions. A bidirectional, eventdriven communication channel between the router and the modem is
necessary.

"Ad Hoc On-demand Distance Vector Version 2 (AODVv2) Routing", Charles

Perkins, Stan Ratliff, John Dowdell, Lotte Steenbrink, Victoria
Mercieca, 2016-05-04, <draft-ietf-manet-aodvv2-16.txt>
The Ad Hoc On-demand Distance Vector Version 2 (AODVv2) routing
protocol is intended for use by mobile routers in wireless, multihop
networks. AODVv2 determines unicast routes among AODVv2 routers
within the network in an on-demand fashion.
"Identity-Based Signatures for MANET Routing Protocols", Christopher
Dearlove, 2016-03-21, <draft-ietf-manet-ibs-05.txt>
This document extends RFC7182, which specifies a framework for, and
specific examples of, integrity check values (ICVs) for packets and
messages using the generalized packet/message format specified in
RFC5444. It does so by defining an additional cryptographic function
that allows the creation of an ICV that is an identity-based
signature, defined according to the ECCSI (Elliptic Curve-Based
Certificateless Signatures for Identity-Based Encryption) algorithm
specified in RFC6507.
"Definition of Managed Objects for the Neighborhood Discovery Protocol",
Ulrich Herberg, Robert Cole, Ian Chakeres, Thomas Clausen, 2016-04-08,
<draft-ietf-manet-rfc6779bis-05.txt>
This document revises, extends, and replaces RFC 6779. It defines a
portion of the Management Information Base (MIB) for use with network
management protocols in the Internet community. In particular, it
describes objects for configuring parameters of the Neighborhood
Discovery Protocol (NHDP) process on a router. The MIB module
defined in this document, denoted NHDP-MIB, also reports state,
performance information, and notifications about NHDP. This
additional state and performance information is useful to
troubleshoot problems and performance issues during neighbor
discovery.
"Security Threats for Simplified Multicast Forwarding (SMF)", Jiazi Yi,
Thomas Clausen, Ulrich Herberg, 2016-03-08,
<draft-ietf-manet-smf-sec-threats-05.txt>
This document analyzes security threats of the Simplified Multicast
Forwarding (SMF), including the vulnerabilities of duplicate packet
detection and relay set selection mechanisms. This document is not
intended to propose solutions to the threats described.
"Multi-path Extension for the Optimized Link State Routing Protocol
version 2 (OLSRv2)", Jiazi Yi, Benoit Parrein, 2016-04-27,
<draft-ietf-manet-olsrv2-multipath-08.txt>
This document specifies a multi-path extension for the Optimized Link
State Routing Protocol version 2 (OLSRv2) to discover multiple
disjoint paths, so as to improve reliability of the OLSRv2 protocol.
The interoperability with OLSRv2 is retained.
"Security Threats for the Optimized Link State Routing Protocol version
2 (OLSRv2)", Thomas Clausen, Ulrich Herberg, Jiazi Yi, 2015-11-06,
<draft-ietf-manet-olsrv2-sec-threats-01.txt>
This document analyzes common security threats of the Optimized Link

State Routing Protocol version 2 (OLSRv2) and describes their

potential impacts on Mobile Ad Hoc Network (MANET) operations. It
then analyzes which of these security vulnerabilities can be
mitigated when using the mandatory-to-implement security mechanisms
for OLSRv2, and how the vulnerabilities are mitigated.
"Rules For Designing Protocols Using the RFC 5444 Generalized Packet/
Message Format", Thomas Clausen, Christopher Dearlove, Ulrich Herberg,
Henning Rogge, 2016-05-04, <draft-ietf-manet-rfc5444-usage-04.txt>
RFC 5444 specifies a generalized MANET packet/message format and
describes an intended use to multiplex MANET routing protocol
messages that is mandated for use by RFC 5498. This document updates
RFC 5444 by providing rules and recommendations for how the
multiplexer operates and how protocols can use the packet/message
format. In particular, the mandatory rules prohibit a number of uses
of RFC 5444 that have been suggested in various proposals, and which
would have led to interoperability problems, to the impediment of
protocol extension development, and to an inability to use optional
generic RFC 5444 parsers.
"Credit Windowing extension for DLEP", Stan Ratliff, 2016-04-10,
<draft-ietf-manet-credit-window-04.txt>
This draft describes an extension to the DLEP protocol to provide a
credit-windowing scheme analogous to that in RFC5578 for destinationspecific flow control.
MBONE Deployment (mboned)
------------------------"Address Acquisition For Multicast Content When Source and Receiver
Support Differing IP Versions", Tina Tsou, Axel Clauberg, Mohamed
Boucadair, Stig Venaas, Qiong, 2015-12-09,
<draft-ietf-mboned-multrans-addr-acquisition-07.txt>
Each IPTV operator has their own arrangements for pre-provisioning
program information including addresses of the multicast groups
corresponding to broadcast programs on the subscriber receiver.
During the transition from IPv4 to IPv6, scenarios can occur where
the IP version supported by the receiver differs from that supported
by the source. This memo examines what has to be done to allow the
receiver to acquire multicast address information in the version it
supports in such scenarios.
"Use of Multicast Across Inter-Domain Peering Points", Percy Tarapore,
Robert Sayko, Greg Shepherd, Toerless Eckert, Ram (Ramki) Krishnan,
2016-03-21, <draft-ietf-mboned-interdomain-peering-bcp-02.txt>
This document examines the use of multicast across inter-domain
peering points. The objective is to describe the setup process for
multicast-based delivery across administrative domains and document
supporting functionality to enable this process.
Multiple Interfaces (mif)
------------------------"Happy Eyeballs Extension for Multiple Interfaces", Gang Chen, Carl
Williams, Dan Wing, Andrew Yourtchenko, 2016-02-21,
<draft-ietf-mif-happy-eyeballs-extension-09.txt>

This memo proposes extensions to the Happy Eyeball(HE) defined in

RFC6555 and fit into a multiple provisioning domain architecture.
Happy Eyeballs in MIF would make the selection process smoother by
using connectivity tests over pre-filtered interfaces according to
defined policy. This would choose the most fast interface with an
automatic fallback mechnism.
"Support for multiple provisioning domains in IPv6 Neighbor Discovery
Protocol", Jouni Korhonen, Suresh Krishnan, Sri Gundavelli, 2016-02-25,
<draft-ietf-mif-mpvd-ndp-support-03.txt>
The MIF working group is producing a solution to solve the issues
that are associated with nodes that can be attached to multiple
networks. One part of the solution requires associating
configuration information with provisioning domains. This document
details how configuration information provided through IPv6 Neighbor
Discovery Protocol can be associated with provisioning domains.
Managed Incident Lightweight Exchange (mile)
-------------------------------------------"IODEF Usage Guidance", Mio Suzuki, Panos Kampanakis, 2016-04-04,
<draft-ietf-mile-iodef-guidance-05.txt,.pdf>
The Incident Object Description Exchange Format [RFC5070] defines a
data representation that provides a framework for sharing information
commonly exchanged by Computer Security Incident Response Teams
(CSIRTs) about computer security incidents. Since the IODEF model
includes a wealth of available options that can be used to describe a
security incident or issue, it can be challenging for implementers to
develop tools that can Leverage IODEF for incident sharing. This
document provides guidelines for IODEF implementers. It will also
address how common security indicators can be represented in IODEF
and use-cases of how IODEF is being used so far. The goal of this
document is to make IODEF's adoption by vendors easier and encourage
faster and wider adoption of the model by Computer Security Incident
Response Teams (CSIRTs) around the world.
"The Incident Object Description Exchange Format v2", Roman Danyliw,
2016-04-21, <draft-ietf-mile-rfc5070-bis-19.txt>
The Incident Object Description Exchange Format (IODEF) defines a
data representation for security incident reports and cyber
indicators commonly exchanged by operational security teams for
mitigation and watch and warning. This document describes an updated
information model for the IODEF and provides an associated data model
specified with XML Schema. This new information and data model
obsoletes [RFC5070].
"Resource-Oriented Lightweight Indicator Exchange", John Field,
2015-12-02, <draft-ietf-mile-rolie-01.txt>
This document defines a resource-oriented approach to cyber security
information sharing. Using this approach, a CSIRT or other
stakeholder may share and exchange representations of cyber security
incidents, indicators, and other related information as Webaddressable resources. The transport protocol binding is specified
as HTTP(S) with a MIME media type of Atom+XML. An appropriate set of
link relation types specific to cyber security information sharing is

defined. The resource representations leverage the existing IODEF

[RFC5070] and RID [RFC6545] specifications as appropriate.
Coexistence with deployments that conform to existing specifications
including RID [RFC6545] and Transport of Real-time Inter-network
Defense (RID) Messages over HTTP/TLS [RFC6546] is supported via
appropriate use of HTTP status codes.
"XMPP Protocol Extensions for Use with IODEF", Nancy Cam-Winget, Syam
Appala, Scott Pope, 2016-04-19, <draft-ietf-mile-xmpp-grid-00.txt>
This document describes the extensions made to Extensible Messaging
and Presence Protocol (XMPP) [RFC6120]that enables the use of XMPP as
a transport protocol for collecting and distributing any security
telemetry information between and among network platforms, endpoints,
and most any network connected device. Specifically, this document
will focus on how these extensions can be used to transport the
Incident Object Description Exchange Format (IODEF) information.
Multiparty Multimedia Session Control (mmusic)
---------------------------------------------"Real Time Streaming Protocol 2.0 (RTSP)", Henning Schulzrinne, Anup
Rao, Rob Lanphier, Magnus Westerlund, Martin Stiemerling, 2014-02-10,
<draft-ietf-mmusic-rfc2326bis-40.txt>
This memorandum defines RTSP version 2.0 which obsoletes RTSP version
1.0 defined in RFC 2326.
The Real Time Streaming Protocol, or RTSP, is an application-layer
protocol for setup and control of the delivery of data with real-time
properties. RTSP provides an extensible framework to enable
controlled, on-demand delivery of real-time data, such as audio and
video. Sources of data can include both live data feeds and stored
clips. This protocol is intended to control multiple data delivery
sessions, provide a means for choosing delivery channels such as UDP,
multicast UDP and TCP, and provide a means for choosing delivery
mechanisms based upon RTP (RFC 3550).
"A Network Address Translator (NAT) Traversal Mechanism for Media
Controlled by Real-Time Streaming Protocol (RTSP)", Jeff Goldberg,
Magnus Westerlund, Thomas Zeng, 2014-07-10,
<draft-ietf-mmusic-rtsp-nat-22.txt>
This document defines a solution for Network Address Translation
(NAT) traversal for datagram based media streams set up and
controlled with Real-time Streaming Protocol version 2 (RTSP 2.0).
It uses Interactive Connectivity Establishment (ICE) adapted to use
RTSP as a signaling channel, defining the necessary RTSP extensions
and procedures.
"Stream Control Transmission Protocol (SCTP)-Based Media Transport in
the Session Description Protocol (SDP)", Christer Holmberg, Salvatore
Loreto, Gonzalo Camarillo, 2016-02-29,
<draft-ietf-mmusic-sctp-sdp-16.txt>
The Stream Control Transmission Protocol (SCTP) is a transport
protocol used to establish associations between two endpoints.
This specification describes how to describe SCTP associations using
the Session Description Protocol (SDP), and defines the following new

SDP Media Description protocol identifiers (proto values):'SCTP',

'SCTP/DTLS', 'UDP/DTLS/SCTP' and 'TCP/DTLS/SCTP'.
The specification also describes how to use the new proto values
together with the SDP Offer/Answer mechanism in order to negotiate
and establish SCTP associations, and how to indicate the SCTP
application usage.
"Negotiating Media Multiplexing Using the Session Description Protocol
(SDP)", Christer Holmberg, Harald Alvestrand, Cullen Jennings,
2016-04-15, <draft-ietf-mmusic-sdp-bundle-negotiation-29.txt>
This specification defines a new Session Description Protocol (SDP)
Grouping Framework extension, 'BUNDLE'. The extension can be used
with the SDP Offer/Answer mechanism to negotiate the usage of a
single address:port combination (BUNDLE address) for receiving media,
referred to as bundled media, specified by multiple SDP media
descriptions ("m=" lines).
To assist endpoints in negotiating the use of bundle this
specification defines a new SDP attribute, 'bundle-only', which can
be used to request that specific media is only used if bundled.
There are multiple ways to correlate the bundled RTP packets with the
appropriate media descriptions. This specification defines a new
Real-time Transport Protocol (RTP) source description (SDES) item and
a new RTP header extension that provides an additional way to do this
correlation by using them to carry a value that associates the RTP/
RTCP packets with a specific media description.
"WebRTC MediaStream Identification in the Session Description Protocol",
Harald Alvestrand, 2016-04-05, <draft-ietf-mmusic-msid-13.txt>
This document specifies a Session Description Protocol (SDP) Grouping
mechanism for RTP media streams that can be used to specify relations
between media streams.
This mechanism is used to signal the association between the SDP
concept of "media description" and the WebRTC concept of
"MediaStream" / "MediaStreamTrack" using SDP signaling.
This document is a work item of the MMUSIC WG, whose discussion list
is mmusic@ietf.org.
"Using Interactive Connectivity Establishment (ICE) with Session
Description Protocol (SDP) offer/answer and Session Initiation Protocol
(SIP)", Marc Petit-Huguenin, Ari Keranen, Suhas Nandakumar, 2016-03-18,
<draft-ietf-mmusic-ice-sip-sdp-08.txt>
This document describes how Interactive Connectivity Establishment
(ICE) is used with Session Description Protocol (SDP) offer/answer
and Session Initiation Protocol (SIP).
"A Framework for SDP Attributes when Multiplexing", Suhas Nandakumar,
2016-01-14, <draft-ietf-mmusic-sdp-mux-attributes-12.txt>
The Session Description Protocol (SDP) provides mechanisms to
describe attributes of multimedia sessions and of individual media
streams (e.g., Real-time Transport Protocol (RTP) sessions) within a
multimedia session. Typically media associated with individual media

descriptions ("m=" lines) represent RTP sessions and are thus carried
over individual underlying transport layer flows. For scenarios
where SDP is used to negotiate the usage of single 5-tuple for
sending and receiving media associated with multiple media
descriptions, it is required to understand the semantic implications
of the SDP attributes associated with the RTP Media Streams
multiplexed over a single underlying transport layer flow.
The purpose of this specification is to provide a framework for
analyzing the multiplexing characteristics of SDP attributes. This
specification also categorizes the existing SDP attributes based on
the framework described herein.
"Using Simulcast in SDP and RTP Sessions", Bo Burman, Magnus Westerlund,
Suhas Nandakumar, Mo Zanaty, 2016-02-03,
<draft-ietf-mmusic-sdp-simulcast-04.txt>
In some application scenarios it may be desirable to send multiple
differently encoded versions of the same media source in different
RTP streams. This is called simulcast. This document describes how
to accomplish simulcast in RTP and how to signal it in SDP. The
described solution uses an RTP/RTCP identification method to identify
RTP streams belonging to the same media source, and makes an
extension to SDP to relate those RTP streams as being different
simulcast formats of that media source. The SDP extension consists
of a new media level SDP attribute that expresses capability to send
and/or receive simulcast RTP streams.
"SDP-based Data Channel Negotiation", Keith Drage, Maridi Makaraju,
Juergen Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2016-02-17,
<draft-ietf-mmusic-data-channel-sdpneg-08.txt>
The Real-Time Communication in WEB-browsers (RTCWeb) working group is
charged to provide protocols to support direct interactive rich
communications using audio, video, and data between two peers' webbrowsers. For the support of data communication, the RTCWeb working
group has in particular defined the concept of bi-directional data
channels over SCTP (Stream Control Transmission Protocol), where each
data channel might be used to transport other protocols, called
subprotocols. Data channel setup can be done using either the inband Data Channel Establishment Protocol (DCEP) or using some out-ofband non-DCEP protocol. This document specifies how the SDP (Session
Description Protocol) offer/answer exchange can be used to achieve
such an out-of-band non-DCEP negotiation. Even though data channels
are designed for RTCWeb use initially, they may be used by other
protocols like, but not limited to, the CLUE protocol (which is
defined by the IETF "ControLling mUltiple streams for tElepresence"
working group). This document is intended to be used wherever data
channels are used.
"MSRP over Data Channels", Keith Drage, Maridi Makaraju, Juergen
Stoetzer-Bradler, Richard Ejzak, Jerome Marcon, 2016-02-12,
<draft-ietf-mmusic-msrp-usage-data-channel-04.txt>
This document specifies how the Message Session Relay Protocol (MSRP)
can be instantiated as a data channel sub-protocol, using the SDP
offer/answer exchange-based generic data channel negotiation
framework. Two network configurations are documented: a WebRTC endto-end configuration (connecting two MSRP over data channel
endpoints), and a gateway configuration (connecting an MSRP over data

channel endpoint with an MSRP over TCP endpoint).

"Using the SDP Offer/Answer Mechanism for DTLS", Christer Holmberg,
Roman Shpount, 2016-03-21, <draft-ietf-mmusic-dtls-sdp-11.txt>
This draft defines the SDP offer/answer procedures for negotiating
and establishing a DTLS association. The draft also defines the
criteria for when a new DTLS association must be established.
This draft defines a new SDP media-level attribute, 'dtlsassociation-id'.
"RTP Payload Format Constraints", Peter Thatcher, Mo Zanaty, Suhas
Nandakumar, Bo Burman, Adam Roach, Byron Campen, 2016-03-28,
<draft-ietf-mmusic-rid-05.txt>
In this specification, we define a framework for identifying RTP
Streams with the constraints on its payload format in the Session
Description Protocol. This framework defines a new "rid" SDP
attribute to: a) effectively identify the RID RTP Streams within a
RTP Session, b) constrain their payload format parameters in a codecagnostic way beyond what is provided with the regular Payload Types
and c) enable unambiguous mapping between the RID RTP Streams to
their media format specification in the SDP.
This specification updates RFC4855 to give additional guidance on
choice of Format Parameter (fmtp) names, and on their relation to the
constraints defined by this document.
"Indicating Exclusive Support of RTP/RTCP Multiplexing using SDP",
Christer Holmberg, 2016-04-15, <draft-ietf-mmusic-mux-exclusive-04.txt>
This document defines a new SDP media-level attribute, 'rtcp-muxonly', that can be used by an endpoint to indicate exclusive support
of RTP/RTCP multiplexing. The document also updates RFC 5761, by
clarifying that an offerer can use a mechanism to indicate that it is
not able to send and receive RTCP on separate ports.
"Updates to RFC 4572", Christer Holmberg, 2016-05-05,
<draft-ietf-mmusic-4572-update-01.txt>
This document updates RFC 4572 by clarifying the usage of multiple
SDP 'fingerprint' attributes with a single TLS connection. The
document also updates the preferred cipher suite to be used, and
removes the requirement to use the same hash function for calculating
the certificate fingerprint that is used to calculate the certificate
signature.
Managing, Ordering, Distributing, Exposing, & Registering telephone Numbers (mod
ern)
----------------------------------------------------------------------------------"Modern Problem Statement, Use Cases, and Framework", Jon Peterson, Tom
McGarry, 2016-04-21, <draft-ietf-modern-problem-framework-00.txt>
The functions of the public switched telephone network (PSTN) are
rapidly migrating to the Internet. This is generating new
requirements for many traditional elements of the PSTN, including
telephone numbers (TNs). TNs no longer serve simply as telephone

routing addresses, they are now identifiers which may be used by

Internet-based services for a variety of purposes including session
establishment, identity verification, and service enablement. This
problem statement examines how the existing tools for allocating and
managing telephone numbers do not align with the use cases of the
Internet environment, and proposes a framework for Internet-based
services relying on TNs.
Multiprotocol Label Switching (mpls)
-----------------------------------"Enhanced path segment monitoring", Alessandro D'Alessandro, Loa
Andersson, Manuel Paul, Satoshi Ueno, Kaoru Arai, Yoshinori Koike,
2015-12-18, <draft-ietf-mpls-tp-temporal-hitless-psm-09.txt>
The MPLS transport profile (MPLS-TP) has been standardized to enable
carrier-grade packet transport and to complement converged packet
network deployments. The most attractive features of MPLS-TP are the
OAM functions. These functions enable maintenance tools that may be
exploited by network operators and service providers for fault
location, survivability, performance monitoring, in-service and outof-service measurements.
One of the most important mechanisms that is common for transport
network operation is fault localisation. A segment monitoring
function of a transport path is effective in terms of extension of
the maintenance work and indispensable, particularly when the OAM
function is activated only between end points. However, the current
approach defined for MPLS-TP of segment monitoring has some
drawbacks. This document elaborates on the problem statement for the
Sub-path Maintenance Elements (SPMEs) which provide monitoring of a
segment of a set of transport paths (LSPs or MS-PWs). Based on the
identified problems, this document provides considerations for the
specification of new requirements to consider a new improved
mechanism for hitless transport path segment monitoring to be named
Enhanced Path Segment Monitoring (EPSM).
"MPLS Transport Profile Linear Protection MIB", Kingston Smiler,
Venkatesan Mahalingam, Vishwas Manral, Daniel King, Sam Aldrin,
Jeong-dong Ryoo, 2016-03-18,
<draft-ietf-mpls-tp-linear-protection-mib-07.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular it defines
objects for managing MPLS Transport Profile (MPLS-TP) Linear
Protection.
"Label Switched Path (LSP) Ping/Trace for Segment Routing Networks Using
MPLS Dataplane", Nagendra Kumar, George Swallow, Carlos Pignataro, Nobo
Akiya, Sriganesh Kini, Hannes Gredler, Mach Chen, 2016-03-21,
<draft-kumarkini-mpls-spring-lsp-ping-06.txt>
Segment Routing architecture leverages the source routing and
tunneling paradigms and can be directly applied to MPLS data plane.
A node steers a packet through a controlled set of instructions
called segments, by prepending the packet with a Segment Routing
header.
The segment assignment and forwarding semantic nature of Segment
Routing raises additional consideration for connectivity verification

and fault isolation in LSP with Segment Routing architecture. This

document illustrates the problem and describe a mechanism to perform
LSP Ping and Traceroute on Segment Routing network over MPLS data
plane.
"Label Distribution Using ARP", Kireeti Kompella, Balaji Rajagopalan,
George Swallow, 2016-03-10, <draft-kompella-mpls-larp-05.txt>
This document describes extensions to the Address Resolution Protocol
to distribute MPLS labels for IPv4 and IPv6 host addresses.
Distribution of labels via ARP enables simple plug-and-play operation
of MPLS.
"RFC6374 UDP Return Path", Stewart Bryant, Siva Sivabalan, Sagar Soni,
2016-04-07, <draft-ietf-mpls-rfc6374-udp-return-path-05.txt>
RFC6374 defines a protocol for Packet Loss and Delay Measurement for
MPLS networks (MPLS-PLDM). This document specifies the procedures to
be used when sending and processing out-of-band MPLS performance
management responses over an IP/UDP return path.
"Label Switched Path (LSP) and Pseudowire (PW) Ping/Trace over MPLS
Network using Entropy Labels (EL)", Nobo Akiya, George Swallow, Carlos
Pignataro, Andrew Malis, Sam Aldrin, 2016-01-04,
<draft-ietf-mpls-entropy-lsp-ping-02.txt>
The Multiprotocol Label Switching (MPLS) Label Switched Path (LSP)
Ping and Traceroute are used to exercise specific paths of Equal-Cost
Multipath (ECMP). When LSP is signaled to use Entropy Label (EL)
described in RFC 6790, the ability for LSP Ping and Traceroute
operation to discover and exercise ECMP paths has been lost in
scenarios which LSRs apply deviating load balance techniques. One
such scenario is when some LSRs apply EL based load balancing while
other LSRs apply non-EL based load balancing (ex: IP). Another
scenario is when EL based LSP is stitched with another LSP which can
be EL based or non-EL based.
This document extends the MPLS LSP Ping and Traceroute mechanisms to
restore the ability of exercising specific paths of ECMP over LSP
which make use of the Entropy Label. This document updates RFC 4379,
RFC 6424, and RFC 6790.
"Application-aware Targeted LDP", Santosh Esale, Raveendra Torvi, Luay
Jalil, Uma Chunduri, Kamran Raza, 2016-05-06,
<draft-ietf-mpls-app-aware-tldp-04.txt>
Recent targeted LDP (tLDP) applications such as remote loop-free
alternate (LFA) and BGP auto discovered pseudowire may automatically
establish a tLDP session to any LSR in a network. The initiating LSR
has information about the targeted applications to administratively
control initiation of the session. However, the responding LSR has no
such information to control acceptance of this session. This document
defines a mechanism to advertise and negotiate Targeted Applications
Capability (TAC) during LDP session initialization. As the
responding LSR becomes aware of targeted applications, it may
establish a limited number of tLDP sessions for certain applications.
In addition, each targeted application is mapped to LDP Forwarding
Equivalence Class (FEC) Elements to advertise only necessary LDP FEClabel bindings over the session.

"Entropy labels for source routed tunnels with label stacks", Sriganesh
Kini, Kireeti Kompella, Siva Sivabalan, Stephane Litkowski, Rob Shakir,
jefftant@gmail.com, 2016-04-07,
<draft-ietf-mpls-spring-entropy-label-03.txt>
Source routed tunnels with label stacking is a technique that can be
leveraged to provide a method to steer a packet through a controlled
set of segments. This can be applied to the Multi Protocol Label
Switching (MPLS) data plane. Entropy label (EL) is a technique used
in MPLS to improve load balancing. This document examines and
describes how ELs are to be applied to source routed tunnels with
label stacks.
"Opportunistic Security in MPLS Networks", Adrian Farrel, Stephen
Farrell, 2016-03-15, <draft-ietf-mpls-opportunistic-encrypt-01.txt>
This document describes a way to apply opportunistic security between
adjacent nodes on an MPLS Label Switched Path (LSP) or between end
points of an LSP. It explains how keys may be agreed to enable
encryption, and how key identifiers are exchanged in encrypted MPLS
packets. Finally, this document describes the applicability of this
approach to opportunistic security in MPLS networks with an
indication of the level of improved security as well as the continued
vulnerabilities.
This document does not describe security for MPLS control plane
protocols.
"Residence Time Measurement in MPLS network", Greg Mirsky, Stefano
Ruffini, Eric Gray, John Drake, Stewart Bryant, Sasha, 2016-04-28,
<draft-ietf-mpls-residence-time-09.txt>
This document specifies G-ACh based Residence Time Measurement and
how it can be used by time synchronization protocols being
transported over MPLS domain.
Residence time is the variable part of propagation delay of timing
and synchronization messages and knowing what this delay is for each
message allows for a more accurate determination of the delay to be
taken into account in applying the value included in a PTP event
message.
"Bidirectional Forwarding Detection (BFD) Directed Return Path", Greg
Mirsky, Jeff Tantsura, Ilya Varlashkin, Mach Chen, 2016-03-02,
<draft-ietf-mpls-bfd-directed-02.txt>
Bidirectional Forwarding Detection (BFD) is expected to monitor bidirectional paths. When a BFD session monitors an explicit routed
path there is a need to be able to direct egress BFD peer to use
specific path for the reverse direction of the BFD session.
"MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology",
Weiqiang Cheng, Lei Wang, Han Li, Huub van Helvoort, Kai Liu, Jie Dong,
He Jia, Fang Li, Yang Jian, Junfang Wang, 2016-03-21,
<draft-ietf-mpls-tp-shared-ring-protection-01.txt>
This document describes requirements, architecture and solutions for
MPLS-TP Shared Ring Protection (MSRP) in the ring topology for pointto-point (P2P) services. The mechanism of MSRP is illustrated and
how it satisfies the requirements for optimized ring protection in

RFC 5654 is analyzed. This document also defines the Ring Protection
Switch (RPS) Protocol which is used to coordinate the protection
behavior of the nodes on MPLS ring.
"A YANG Data Model for MPLS Base and Static LSPs", Kamran Raza, Rakesh
Gandhi, Xufeng Liu, Vishnu Pavan Beeram, Tarek Saad, Xia Chen, Raqib
Jones, Bin Wen, 2016-03-21, <draft-saad-mpls-static-yang-02.txt>
This document contains a specification of two YANG modules, the MPLS
base, and Static LSP YANG modules. The MPLS base YANG module serves
as a base framework for configuring and managing an MPLS switching
subsystem. The MPLS Static LSP module augments the MPLS base YANG
module with specific data to configure and manage MPLS Static LSP(s).
It is expected that other MPLS YANG modules for MPLS technology YANG
modules (e.g. MPLS LDP or MPLS RSVP-TE) will also augment the MPLS
YANG base model.
"Resilient MPLS Rings", Kireeti Kompella, Luis Contreras, 2016-03-21,
<draft-ietf-mpls-rmr-01.txt>
This document describes the use of the MPLS control and data planes
on ring topologies. It describes the special nature of rings, and
proceeds to show how MPLS can be effectively used in such topologies.
It describes how MPLS rings are configured, auto-discovered and
signaled, as well as how the data plane works. Companion documents
describe the details of discovery and signaling for specific
protocols.
"MPLS Flow Identification Considerations", Stewart Bryant, Carlos
Pignataro, Mach Chen, Zhenbin Li, Greg Mirsky, 2015-12-18,
<draft-ietf-mpls-flow-ident-00.txt>
This memo discusses the desired capabilities for MPLS flow
identification. The key application that needs this is in-band
performance monitoring of user data packets.
"Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures",
Kireeti Kompella, Carlos Pignataro, Nagendra Kumar, Sam Aldrin, Mach
Chen, 2016-04-30, <draft-ietf-mpls-rfc4379bis-04.txt>
This document describes a simple and efficient mechanism that can be
used to detect data plane failures in Multi-Protocol Label Switching
(MPLS) Label Switched Paths (LSPs). There are two parts to this
document: information carried in an MPLS "echo request" and "echo
reply" for the purposes of fault detection and isolation, and
mechanisms for reliably sending the echo reply.
This document obsoletes RFCs 4379 and 6829.
"Definitions of Managed Objects for the LDP Point-to-Multipoint and
Multipoint-to-Multipoint Label Switched Paths", Kishore Tiruveedhula,
Uwe Joorde, Arvind Venkateswaran, 2016-01-08,
<draft-ietf-mpls-mldp-mib-00.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular it defines
objects for managing multicast LDP point-to-multipoint (P2MP) and
multipoint-to-multipoint (MP2MP) Label Switched Paths. The MIB
module defined in this document is extension of LDP MIB defined in
RFC3815 which supports only for LDP point-to-point LSPs.

"Use Cases and Requirements for MPLS-TP multi-failure protection",

Zhenlong Cui, Rolf Winter, Himanshu Shah, Sam Aldrin, Masahiro Daikoku,
2016-02-01, <draft-ietf-mpls-tp-mfp-use-case-and-requirements-00.txt>
For the Multiprotocol Label Switching Transport Profile (MPLS-TP)
linear protection capable of 1+1 and 1:1 protection has already been
defined. That linear protection mechanism has not been designed for
handling multiple, simultaneously occuring failures, i.e. multiple
failures that affect the working and the protection entity during the
same time period. In these situations currently defined protection
mechanisms would fail.
This document introduces use cases and requirements for mechanisms
that are capable of protecting against such failures. It does not
specify a multi-failure protection mechanism itself.
"Using BGP to Bind MPLS Labels to Address Prefixes", Eric Rosen,
2016-02-11, <draft-rosen-mpls-rfc3107bis-00.txt>
This document specifies the protocols and procedures for using BGP to
advertise that a specified router has bound a specified MPLS label
(or a specified sequence of MPLS labels, organized as a contiguous
part of a label stack) to a specified address prefix. This is done
by sending a BGP UPDATE message whose Network Layer Reachability
Information field contains both the prefix and the MPLS label(s), and
whose Next Hop field identifies the node at which said prefix is
bound to said label(s). This document obsoletes RFC 3107.
"LDP Specification", Xia Chen, Loa Andersson, Nicolai Leymann, Ina
Minei, Kamran Raza, 2016-04-07, <draft-ijln-mpls-rfc5036bis-02.txt>
The architecture for Multiprotocol Label Switching (MPLS) is
described in RFC 3031. A fundamental concept in MPLS is that two
Label Switching Routers (LSRs) must agree on the meaning of the
labels used to forward traffic between and through them. This common
understanding is achieved by using a set of procedures, called a
label distribution protocol, by which one LSR informs another of
label bindings it has made. This document defines a set of such
procedures called LDP (for Label Distribution Protocol) by which LSRs
distribute labels to support MPLS forwarding along normally routed
paths.
"Updates to MPLS Transport Profile (MPLS-TP) Linear Protection in
Automatic Protection Switching (APS) Mode", Jeong-dong Ryoo, Tae-sik
Cheung, Huub van Helvoort, Italo Busi, Guangjuan Weng, 2016-03-19,
<draft-ietf-mpls-tp-aps-updates-00.txt>
This document contains updates to MPLS Transport Profile (MPLS-TP)
linear protection in Automatic Protection Switching (APS) mode
defined in RFC 7271. The updates provide rules related to the
initialization of the Protection State Coordination (PSC) Control
Logic, in which the state machine resides, when operating in APS
mode.
Multipath TCP (mptcp)
--------------------"TCP Extensions for Multipath Operation with Multiple Addresses", Alan
Ford, Costin Raiciu, Mark Handley, Olivier Bonaventure, Christoph

Paasch, 2016-01-12, <draft-ietf-mptcp-rfc6824bis-05.txt>

TCP/IP communication is currently restricted to a single path per
connection, yet multiple paths often exist between peers. The
simultaneous use of these multiple paths for a TCP/IP session would
improve resource usage within the network and, thus, improve user
experience through higher throughput and improved resilience to
network failure.
Multipath TCP provides the ability to simultaneously use multiple
paths between peers. This document presents a set of extensions to
traditional TCP to support multipath operation. The protocol offers
the same type of service to applications as TCP (i.e., reliable
bytestream), and it provides the components necessary to establish
and use multiple TCP flows across potentially disjoint paths.
This document specifies v1 of Multipath TCP, obsoleting v0 as
specified in RFC6824 [5] through clarifications and modifications
primarily driven by deployment experience.
"Use Cases and Operational Experience with Multipath TCP", Olivier
Bonaventure, Christoph Paasch, Gregory Detal, 2016-04-04,
<draft-ietf-mptcp-experience-04.txt,.ps,.pdf>
This document discusses both use cases and operational experience
with Multipath TCP in real world networks. It lists several
prominent use cases for which Multipath TCP has been considered and
is being used. It also gives insight to some heuristics and
decisions that have helped to realize these use cases.
Network Configuration (netconf)
------------------------------"RESTCONF Protocol", Andy Bierman, Martin Bjorklund, Kent Watsen,
2016-04-27, <draft-ietf-netconf-restconf-13.txt>
This document describes an HTTP-based protocol that provides a
programmatic interface for accessing data defined in YANG, using the
datastores defined in NETCONF.
"YANG Patch Media Type", Andy Bierman, Martin Bjorklund, Kent Watsen,
2016-03-16, <draft-ietf-netconf-yang-patch-08.txt>
This document describes a method for applying patches to
configuration datastores using data defined with the YANG data
modeling language.
"NETCONF Server and RESTCONF Server Configuration Models", Kent Watsen,
Jrgen Schnwlder, 2016-03-16, <draft-ietf-netconf-server-model-09.txt>
This draft defines a NETCONF server configuration data model and a
RESTCONF server configuration data model. These data models enable
configuration of the NETCONF and RESTCONF services themselves,
including which transports are supported, what ports the servers
listen on, call-home parameters, client authentication, and related
parameters.
Editorial Note (To be removed by RFC Editor)
This draft contains many placeholder values that need to be replaced

with finalized values at the time of publication. This note

summarizes all of the substitutions that are needed. Please note
that no other RFC Editor instructions are specified anywhere else in
this document.
This document contains references to other drafts in progress, both
in the Normative References section, as well as in body text
throughout. Please update the following references to reflect their
final RFC assignments:
o draft-ietf-netconf-restconf
o draft-ietf-netconf-call-home
o draft-ietf-rtgwg-yang-key-chain
Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements:
o "VVVV" --> the assigned RFC value for this draft
o "XXXX" --> the assigned RFC value for draft-ietf-netconf-restconf
o "YYYY" --> the assigned RFC value for draft-ietf-netconf-call-home
Artwork in this document contains placeholder values for ports
pending IANA assignment from "draft-ietf-netconf-call-home". Please
apply the following replacements:
o "7777" --> the assigned port value for "netconf-ch-ssh"
o "8888" --> the assigned port value for "netconf-ch-tls"
o "9999" --> the assigned port value for "restconf-ch-tls"
Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement:
o "2016-03-16" --> the publication date of this draft
The following two Appendix sections are to be removed prior to
publication:
o Appendix A. Change Log
o Appendix B. Open Issues
Artwork in the document contains a temporary YANG containers that
need to be removed.
o The "listening-ssh-server" container listed at the end of the
artwork in Section 4.2.3 needs to be removed. Please remove the
ten lines starting with "container listening-ssh-server {" and
ending with "}".
o The "listening-tls-server" container listed at the end of the
artwork in Section 4.3.3 needs to be removed. Please remove the
ten lines starting with "container listening-tls-server {" and
ending with "}".
"Zero Touch Provisioning for NETCONF or RESTCONF based Management", Kent

Watsen, Mikael Abrahamsson, 2016-04-06,

<draft-ietf-netconf-zerotouch-08.txt>
This draft presents a secure technique for establishing a NETCONF or
RESTCONF connection between a newly deployed device, configured with
just its factory default settings, and its deployment specific
network management system (NMS).
"NETCONF Call Home and RESTCONF Call Home", Kent Watsen, 2015-12-22,
<draft-ietf-netconf-call-home-17.txt>
This RFC presents NETCONF Call Home and RESTCONF Call Home, which
enable a NETCONF or RESTCONF server to initiate a secure connection
to a NETCONF or RESTCONF client respectively.
"YANG Module Library", Andy Bierman, Martin Bjorklund, Kent Watsen,
2016-04-27, <draft-ietf-netconf-yang-library-06.txt>
This document describes a YANG library, which provides information
about all the YANG modules used by a network management server (e.g.,
a Network Configuration Protocol (NETCONF) server). Simple caching
mechanisms are provided to allow clients to minimize retrieval of
this information.
"Subscribing to YANG datastore push updates", Alex Clemm, Alberto
Prieto, Eric Voit, Ambika Tripathy, Einar, 2016-03-21,
<draft-ietf-netconf-yang-push-02.txt>
This document defines a subscription and push mechanism for YANG
datastores. This mechanism allows client applications to request
updates from a YANG datastore, which are then pushed by the server to
a receiver per a subscription policy, without requiring additional
client requests.
Network-Based Mobility Extensions (netext)
-----------------------------------------"Logical-interface Support for Multi-access enabled IP Hosts", Telemaco
Melia, Sri Gundavelli, 2016-03-13,
<draft-ietf-netext-logical-interface-support-14.txt>
A Logical-interface is a software semantic internal to the host
operating system. This semantic is available in all popular
operating systems and is used in various protocol implementations.
The Logical-interface support is required on the mobile node attached
to a Proxy Mobile IPv6 domain, for leveraging various network-based
mobility management features such as inter-technology handoffs,
multihoming and flow mobility support. This document explains the
operational details of Logical-interface construct and the specifics
on how the link-layer implementations hide the physical interfaces
from the IP stack and from the network nodes on the attached access
networks. Furthermore, this document identifies the applicability of
this approach to various link-layer technologies and analyzes the
issues around it when used in conjunction with various mobility
management features.
"Proxy Mobile IPv6 Extensions to Support Flow Mobility", Carlos
Bernardos, 2016-03-18, <draft-ietf-netext-pmipv6-flowmob-18.txt>
Proxy Mobile IPv6 allows a mobile node to connect to the same Proxy

Mobile IPv6 domain through different interfaces. This document

describes extensions to the Proxy Mobile IPv6 protocol that are
required to support network based flow mobility over multiple
physical interfaces.
This document updates RFC 5213. The extensions described in this
document consist of the operations performed by the local mobility
anchor and the mobile access gateway to manage the prefixes assigned
to the different interfaces of the mobile node, as well as how the
forwarding policies are handled by the network to ensure consistent
flow mobility management.
NETCONF Data Modeling Language (netmod)
--------------------------------------"A YANG Data Model for Routing Management", Ladislav Lhotka, Acee
Lindem, 2016-03-17, <draft-ietf-netmod-routing-cfg-21.txt>
This document contains a specification of three YANG modules and one
submodule. Together they form the core routing data model which
serves as a framework for configuring and managing a routing
subsystem. It is expected that these modules will be augmented by
additional YANG modules defining data models for routing protocols,
route filters and other functions. The core routing data model
provides common building blocks for such extensions - routes, routing
information bases (RIB), and routing protocols.
"JSON Encoding of Data Modeled with YANG", Ladislav Lhotka, 2016-03-28,
<draft-ietf-netmod-yang-json-10.txt>
This document defines encoding rules for representing configuration
data, state data, parameters of RPC operations or actions, and
notifications defined using YANG as JavaScript Object Notation (JSON)
text.
"Guidelines for Authors and Reviewers of YANG Data Model Documents",
Andy Bierman, 2016-03-20, <draft-ietf-netmod-rfc6087bis-06.txt>
This memo provides guidelines for authors and reviewers of Standards
Track specifications containing YANG data model modules. Applicable
portions may be used as a basis for reviews of other YANG data model
documents. Recommendations and procedures are defined, which are
intended to increase interoperability and usability of Network
Configuration Protocol (NETCONF) implementations that utilize YANG
data model modules.
"The YANG 1.1 Data Modeling Language", Martin Bjorklund, 2016-04-28,
<draft-ietf-netmod-rfc6020bis-12.txt>
YANG is a data modeling language used to model configuration data,
state data, remote procedure calls, and notifications for network
management protocols. This document also specifies the YANG mappings
to the Network Configuration Protocol (NETCONF).
"SYSLOG YANG Model", Clyde Wildes, Kiran Koushik, 2016-03-20,
<draft-ietf-netmod-syslog-model-07.txt>
This document describes a data model for the Syslog protocol which is
used to convey event notification messages.

"Network Access Control List (ACL) YANG Data Model", Dean Bogdanovic,
Kiran Koushik, Lisa Huang, Dana Blair, 2016-03-11,
<draft-ietf-netmod-acl-model-07.txt>
This document describes a data model of Access Control List (ACL)
basic building blocks.
"Defining and Using Metadata with YANG", Ladislav Lhotka, 2016-03-21,
<draft-ietf-netmod-yang-metadata-07.txt>
This document defines a YANG extension statement that allows for
defining metadata annotations in YANG modules. The document also
specifies XML and JSON encoding of annotations and other rules for
annotating instances of YANG data nodes.
"Terminology and Requirements for Enhanced Handling of Operational
State", Kent Watsen, Tom Nadeau, 2016-01-22,
<draft-ietf-netmod-opstate-reqs-04.txt>
This document primarily regards the difference between the intended
configuration and the applied configuration of a device and how
intended and applied configuration relate to the operational state of
a device. This document defines requirements for the applied
configuration's data model and its values, as well as for enabling a
client to know when a configuration has been fully applied or not,
how to access operational state, and how to relate intended
configuration nodes to applied configuration and derived state nodes.
"YANG Model Classification", Dean Bogdanovic, Benoit Claise, Carl
Moberg, 2016-04-04, <draft-ietf-netmod-yang-model-classification-01.txt>
The YANG [RFC6020] data modeling language is currently being
considered for a wide variety of applications throughout the
networking industry at large. Many standards-defining organizations
(SDOs), open source software projects, vendors and users are using
YANG to develop and publish models of configuration, state data and
operations for a wide variety of applications. At the same time,
there is currently no well-known terminology to categorize various
types of YANG models.
A consistent terminology would help with the categorization of
models, assist in the analysis the YANG data modeling efforts in the
IETF and other organizations, and bring clarity to the YANG-related
discussions between the different groups.
This document describes a set of concepts and associated terms to
support consistent classification of YANG models.
"YANG Schema Mount", Martin Bjorklund, Ladislav Lhotka, 2016-04-05,
<draft-ietf-netmod-schema-mount-01.txt>
This document defines a mechanism to combine YANG modules into the
schema defined in other YANG modules.
"Common Interface Extension YANG Data Models", Robert Wilton, David
Ball, Tapraj Singh, Selvakumar Sivaraj, 2016-04-21,
<draft-ietf-netmod-intf-ext-yang-00.txt>
This document defines two YANG modules that augment the Interfaces
data model defined in the "YANG Data Model for Interface Management"

with additional configuration and operational data nodes to support

common lower layer interface properties, such as interface MTU.
These properties are common to many types of interfaces on network
routers and switches and are implemented by multiple network
equipment vendors with similar semantics, even though some of the
features are not formally defined in any published standard.
Internet Video Codec (netvc)
---------------------------"<Video Codec Requirements and Evaluation Methodology>", Alexey
Filippov, 2016-04-01, <draft-ietf-netvc-requirements-01.txt,.pdf>
This document provides requirements for a video codec designed
mainly for use over the Internet. In addition, an evaluation
methodology needed for measuring the parameters (compression
efficiency, computational complexity, etc.) to ensure whether the
stated requirements are fulfilled or not.
"Video Codec Testing and Quality Measurement", Thomas Daede, Andrey
Norkin, 2016-03-15, <draft-ietf-netvc-testing-02.txt>
This document describes guidelines and procedures for evaluating a
video codec specified at the IETF. This covers subjective and
objective tests, test conditions, and materials used for the test.
Network File System Version 4 (nfsv4)
------------------------------------"NFSv4 Minor Version 2 Protocol External Data Representation Standard
(XDR) Description", Tom Haynes, 2016-01-28,
<draft-ietf-nfsv4-minorversion2-dot-x-41.txt>
This Internet-Draft provides the XDR description for NFSv4 minor
version two.
"NFS Version 4 Minor Version 2", Tom Haynes, 2016-01-28,
<draft-ietf-nfsv4-minorversion2-41.txt>
This Internet-Draft describes NFS version 4 minor version two,
describing the protocol extensions made from NFS version 4 minor
version 1. Major extensions introduced in NFS version 4 minor
version two include: Server Side Copy, Application Input/Output (I/O)
Advise, Space Reservations, Sparse Files, Application Data Blocks,
and Labeled NFS.
"Remote Procedure Call (RPC) Security Version 3", Andy Adamson, Nicolas
Williams, 2016-01-28, <draft-ietf-nfsv4-rpcsec-gssv3-17.txt>
This document specifies version 3 of the Remote Procedure Call (RPC)
security protocol (RPCSEC_GSS). This protocol provides support for
multi-principal authentication of client hosts and user principals to
a server (constructed by generic composition), security label
assertions for multi-level and type enforcement, structured privilege
assertions, and channel bindings.
"NFSv4 migration: Implementation experience and spec issues to resolve",
David Noveck, Piyush Shivam, Chuck Lever, Bill Baker, 2016-02-19,
<draft-ietf-nfsv4-migration-issues-09.txt>

The migration feature of NFSv4 provides for moving responsibility for

a single filesystem from one server to another, without disruption to
clients. Recent implementation experience has shown problems in the
existing specification for this feature. This document discusses the
issues which have arisen and explores the options available for
curing the issues. It also explains the choices made regarding
updating the NFSv4.0 specification and those to be made with regard
to the NFSv4.1 specification, in order to properly address migration.
"NFSv4.0 migration: Specification Update", David Noveck, Piyush Shivam,
Chuck Lever, Bill Baker, 2016-02-02,
<draft-ietf-nfsv4-rfc3530-migration-update-08.txt>
The migration feature of NFSv4 allows for responsibility for a single
file system to move from one server to another, without disruption to
clients. Recent implementation experience has shown problems in the
existing specification for this feature in NFSv4.0. This document
identifies the problem areas and provides revised specification text
which updates the NFSv4.0 specification in RFC7530.
"Requirements for pNFS Layout Types", Tom Haynes, 2016-01-28,
<draft-ietf-nfsv4-layout-types-04.txt>
This document provides help in distinguishing between the
requirements for Network File System (NFS) version 4.1's Parallel NFS
(pNFS) and those those specifically directed to the pNFS File Layout.
The lack of a clear separation between the two set of requirements
has been troublesome for those specifying and evaluating new Layout
Types. As this document clarifies RFC5661, it effectively updates
RFC5661.
"Parallel NFS (pNFS) Flexible File Layout", Benny Halevy, Tom Haynes,
2016-01-22, <draft-ietf-nfsv4-flex-files-07.txt>
The Parallel Network File System (pNFS) allows a separation between
the metadata (onto a metadata server) and data (onto a storage
device) for a file. The Flexible File Layout Type is defined in this
document as an extension to pNFS to allow the use of storage devices
in a fashion such that they require only a quite limited degree of
interaction with the metadata server, using already existing
protocols. Client side mirroring is also added to provide
replication of files.
"Multiple NFSv4 Domain Namespace Deployment Guidelines", Andy Adamson,
Nicolas Williams, 2016-05-06,
<draft-ietf-nfsv4-multi-domain-fs-reqs-07.txt>
This document discusses issues relevant to the deployment of the
NFSv4 protocols in situations allowing for the construction of an
NFSv4 file namespace supporting the use of multiple NFSv4 domains and
utilizing multi-domain capable file systems. Also described are
constraints on name resolution and security services appropriate to
the administration of such a system. Such a namespace is a suitable
way to enable a Federated File System supporting the use of multiple
NFSv4 domains.
"NFSv4 Version Management", David Noveck, 2016-01-15,
<draft-ietf-nfsv4-versioning-03.txt,.pdf>
This document describes the management of versioning within the NFSv4

family of protocols. It covers the creation of minor versions, the

addition of optional features to existing minor versions, and the
correction of flaws in features already published as Proposed
Standards. The rules relating to the construction of minor versions
and the interaction of minor version implementations that appear in
this document supersede the minor versioning rules in RFC5661.
"Parallel NFS (pNFS) SCSI Layout", Christoph Hellwig, 2015-12-05,
<draft-ietf-nfsv4-scsi-layout-05.txt>
The Parallel Network File System (pNFS) allows a separation between
the metadata (onto a metadata server) and data (onto a storage
device) for a file. The SCSI Layout Type is defined in this document
as an extension to pNFS to allow the use SCSI based block storage
devices.
"Bi-directional Remote Procedure Call On RPC-over-RDMA Transports",
Chuck Lever, 2016-05-02,
<draft-ietf-nfsv4-rpcrdma-bidirection-03.txt,.ps,.pdf>
Recent minor versions of NFSv4 work best when ONC RPC transports can
send Remote Procedure Call transactions in both directions on the
same connection. This document describes how RPC-over-RDMA transport
endpoints convey RPCs in both directions on a single connection.
"File System Extended Attributes in NFSv4", Manoj Naik, Marc Eshel,
2016-03-08, <draft-ietf-nfsv4-xattrs-02.txt>
This document proposes extensions to the NFSv4 protocol which allow
file extended attributes (hereinafter also referred to as xattrs) to
be manipulated using NFSv4. An xattr is a file system feature that
allows opaque metadata, not interpreted by the file system, to be
associated with files and directories. Such support is present in
many modern local file systems. New file attributes are proposed to
allow clients to query the server for xattr support, and new
operations to get and set xattrs on file system objects are provided.
"RPC-over-RDMA Version One Implementation Experience", Chuck Lever,
2016-04-08,
<draft-ietf-nfsv4-rfc5666-implementation-experience-02.txt,.ps,.pdf>
This document details experiences and challenges implementing the
RPC-over-RDMA Version One protocol. Specification changes are
recommended to address avoidable interoperability failures.
"Remote Direct Memory Access Transport for Remote Procedure Call,
Version One", Chuck Lever, William Simpson, Tom Talpey, 2016-04-08,
<draft-ietf-nfsv4-rfc5666bis-05.txt,.ps,.pdf>
This document specifies a protocol for conveying Remote Procedure
Call (RPC) messages on physical transports capable of Remote Direct
Memory Access (RDMA). It requires no revision to application RPC
protocols or the RPC protocol itself. This document obsoletes RFC
5666.
"Allowing inheritable NFSv4 ACLs to override the umask", J. Fields,
Andreas Gruenbacher, 2016-04-10, <draft-ietf-nfsv4-umask-00.txt>
In some environments, inheritable NFSv4 ACLs can be rendered
ineffective by the application of the per-process umask. This is

easily worked around by transmitting the umask and create mode

separately to allow servers to make more intelligent decisions about
the new mode of a file.
Network Function Virtualization (nfvrg)
--------------------------------------"Resource Management in Service Chaining", Seungik Lee, Sangheon Pack,
Myung-Ki Shin, EunKyoung Paik, Rory Browne, 2016-03-21,
<draft-irtf-nfvrg-resource-management-service-chain-03.txt,.pdf>
This document specifies problem definition and use cases of NFV
resource management in service chaining for path optimization,
traffic optimization, failover, load balancing, etc. It further
describes design considerations and relevant framework for the
resource management capability that dynamically creates and updates
network forwarding paths (NFPs) considering resource constraints of
NFV infrastructure.
"Policy Architecture and Framework for NFV Infrastructures", Norival
Figueira, Ram (Ramki) Krishnan, Diego Lopez, Steven Wright, Dilip
Krishnaswamy, 2016-03-09, <draft-irtf-nfvrg-nfv-policy-arch-03.txt>
A policy architecture and framework is discussed to support NFV
environments, where policies are used to enforce business rules and
to specify resource constraints in a number of subsystems. This
document approaches the policy framework and architecture from the
perspective of overall orchestration requirements for services
involving multiple subsystems. The framework extends beyond common
orchestration constraints across compute, network, and storage
subsystems to include energy conservation. This document also
analyses policy scope, global versus local policies, static versus
dynamic versus autonomic policies, policy actions and translations,
policy conflict detection and resolution, interactions among policies
engines, and a hierarchical policy architecture/framework to address
the demanding and growing requirements of NFV environments. These
findings may also be applicable to cloud infrastructures in general.
"Verification of NFV Services : Problem Statement and Challenges",
Myung-Ki Shin, Ki-Hyuk Nam, Sangheon Pack, Seungik Lee, Ram (Ramki)
Krishnan, 2016-03-16, <draft-irtf-nfvrg-service-verification-01.txt>
NFV relocates network functions from dedicated hardware appliances to
generic servers, so they can run in software. However, incomplete or
inconsistent configuration of virtualized network functions (VNF) and
forwarding graph (FG, aka service chain) could cause break-down of
the supporting infrastructure. In this sense, verification is
critical for network operators to check their requirements and
network properties are correctly enforced in the supporting
infrastructures. Recognizing these problems, we discuss key
properties to be checked on NFV-enabled services. Also, we present
challenging issues related to verification in NFV environments.
"Gap Analysis on Network Virtualization Activities", Carlos Bernardos,
Akbar Rahman, JC Zuniga, Luis Contreras, Pedro Aranda, 2016-03-21,
<draft-irtf-nfvrg-gaps-network-virtualization-00.txt>
The main goal of this document is to serve as a survey of the
different efforts that have been taken and are currently taking place
at IETF and IRTF in regards to network virtualization, automation and

orchestration, putting them into context considering efforts by other

SDOs, and identifying current gaps and challenges that can be tackled
at IETF or researched at the IRTF.
"Recursive virtualization and programming for network and cloud
resources", Robert Szabo, Zu Qiang, Mario Kind, 2016-03-21,
<draft-irtf-nfvrg-unify-recursive-programming-00.txt>
The introduction of Network Function Virtualization (NFV) in carriergrade networks promises improved operations in terms of flexibility,
efficiency, and manageability. NFV is an approach to combine network
and compute virtualizations together. However, network and compute
resource domains expose different virtualizations and programmable
interfaces. In [I-D.unify-nfvrg-challenges] we argued for a joint
compute and network virtualization by looking into different compute
abstractions.
In this document we analyze different approaches to orchestrate a
service graph with transparent network functions relying on a public
telecommunication network and ending in a commodity data center. We
show that a recursive compute and network joint virtualization and
programming has clear advantages compared to other approaches with
separated control between compute and network resources. In
addition, the joint virtualization will have cost and performance
advantages by removing additional virtualization overhead. The
discussion of the problems and the proposed solution is generic for
any data center use case; however, we use NFV as an example.
"Policy-Based Resource Management", Robert Szabo, Norival Figueira,
2016-03-21, <draft-irtf-nfvrg-policy-based-resource-management-00.txt>
abstract to be defined
Network Management (nmrg)
------------------------"Extending IP Flow-Based Network Monitoring with Location Information",
Olivier Festor, Abdelkader Lahmadi, Rick Hofstede, Aiko Pras,
2016-03-18, <draft-irtf-nmrg-location-ipfix-06.txt>
IP Flow-based monitoring lacks a mechanism to associate measured IP
Flow information with the geographic location of the device where the
IP Flows have been observed. This document defines a set of
guidelines and best practices to extend IP Flow monitoring protocols
with location information of the device (both fixed and mobile) that
acts as an IP Flow metering process.
"Autonomic Networking Use Case for Distributed Detection of SLA
Violations", Jeff, Lisandro Granville, Alex Clemm, Alberto Prieto,
2016-04-06, <draft-irtf-nmrg-autonomic-sla-violation-detection-03.txt>
This document describes a use case for autonomic networking in
distributed detection of Service Level Agreement (SLA) violations.
It is one of a series of use cases intended to illustrate
requirements for autonomic networking.
Individual Submissions (none)
----------------------------"An IPv4 Flowlabel Option", Thomas Dreibholz, 2016-01-08,

<draft-dreibholz-ipv4-flowlabel-23.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.
"EAP Support in Smartcard", Pascal Urien, Guy Pujolle, 2015-12-21,
<draft-urien-eap-smartcard-30.txt>
This document describes the functional interface, based on the
ISO7816 standard, to EAP methods, fully and securely executed in
smart cards. This class of tamper resistant device may deliver
client or server services; it can compute Root Keys from an Extended
Master Session Key (EMSK).
"Prepaid Extensions to Remote Authentication Dial-In User Service
(RADIUS)", Avi Lior, Parviz Yegani, Kuntal Chowdhury, Hannes Tschofenig,
Andreas Pashalidis, 2013-02-25,
<draft-lior-radius-prepaid-extensions-22.txt>
This document specifies an extension to the Remote Authentication
Dial-In User Service (RADIUS) protocol that enables service providers
to charge for prepaid services. The supported charging models
supported are volume-based, duration-based, and based on one-time
events.
"Applicability of Reliable Server Pooling for Real-Time Distributed
Computing", Thomas Dreibholz, 2016-01-08,
<draft-dreibholz-rserpool-applic-distcomp-20.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.
"Secure SCTP", Carsten Hohendorf, Esbold Unurkhaan, Thomas Dreibholz,
2016-01-08, <draft-hohendorf-secure-sctp-21.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.
"Applicability of Reliable Server Pooling for SCTP-Based Endpoint
Mobility", Thomas Dreibholz, Jobin Pulinthanath, 2016-01-08,
<draft-dreibholz-rserpool-applic-mobility-19.txt>
This document describes a novel mobility concept based on a
combination of SCTP with Dynamic Address Reconfiguration extension
and Reliable Server Pooling (RSerPool).
"Reliable Server Pooling (RSerPool) Bakeoff Scoring", Thomas Dreibholz,
Michael Tuexen, 2016-01-08, <draft-dreibholz-rserpool-score-18.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.
"Handle Resolution Option for ASAP", Thomas Dreibholz, 2016-01-08,
<draft-dreibholz-rserpool-asap-hropt-18.txt>

This document describes the Handle Resolution option for the ASAP
protocol.
"Definition of a Delay Measurement Infrastructure and Delay-Sensitive
Least-Used Policy for Reliable Server Pooling", Thomas Dreibholz, Xing
Zhou, 2016-01-08, <draft-dreibholz-rserpool-delay-17.txt>
This document contains the definition of a delay measurement
infrastructure and a delay-sensitive Least-Used policy for Reliable
Server Pooling.
"Extensions for Multi-MTU Subnets", Iljitsch van Beijnum, 2016-03-21,
<draft-van-beijnum-multi-mtu-05.txt>
In the early days of the internet, many different link types with
many different maximum packet sizes were in use. For point-to-point
or point-to-multipoint links, there are still some other link types
(PPP, ATM, Packet over SONET), but multipoint subnets are now almost
exclusively implemented as Ethernets. Even though the relevant
standards mandate a 1500 byte maximum packet size for Ethernet, more
and more Ethernet equipment is capable of handling packets bigger
than 1500 bytes. However, since this capability isn't standardized,
it is seldom used today, despite the potential performance benefits
of using larger packets. This document specifies mechanisms to
negotiate per-neighbor maximum packet sizes so that nodes on a
multipoint subnet may use the maximum mutually supported packet size
between them without being limited by nodes with smaller maximum
sizes on the same subnet.
"Saratoga: A Scalable Data Transfer Protocol", Lloyd Wood, Wesley Eddy,
Charles Smith, Will Ivancic, Chris Jackson, 2016-05-03,
<draft-wood-tsvwg-saratoga-19.txt>
This document specifies the Saratoga transfer protocol. Saratoga was
originally developed to transfer remote-sensing imagery efficiently
from a low-Earth-orbiting satellite constellation, but is useful in
many other scenarios, including ad-hoc peer-to-peer communications,
large-scale scientific sensing, and grid computing. Saratoga is a
simple, lightweight, content dissemination protocol that builds on
UDP, and optionally uses UDP-Lite. Saratoga is intended for use when
moving files or streaming data between peers which may have
permanent, sporadic or intermittent connectivity, and is capable of
transferring very large amounts of data reliably under adverse
conditions. The Saratoga protocol is designed to cope with highly
asymmetric link or path capacity between peers, and can support
fully-unidirectional data transfer if required. Saratoga can also
cope with very large files for exascale computing. In scenarios with
dedicated links, Saratoga focuses on high link utilization to make
the most of limited connectivity times, while standard congestion
control mechanisms can be implemented for operation over shared
links. Loss recovery is implemented via a simple negative-ack ARQ
mechanism. The protocol specified in this document is considered to
be appropriate for experimental use on private IP networks.
"The BagIt File Packaging Format (V0.97)", John Kunze, Justin Littman,
Liz Madden, Ed Summers, Andy Boyko, Brian Vargas, 2016-01-26,
<draft-kunze-bagit-13.txt>
This document specifies BagIt, a hierarchical file packaging format
for storage and transfer of arbitrary digital content. A "bag" has

just enough structure to enclose descriptive "tags" and a "payload"

but does not require knowledge of the payload's internal semantics.
This BagIt format should be suitable for disk-based or network-based
storage and transfer. BagIt is widely used in the practice of
digital preservation.
"BGP Extended Community for QoS Marking", Thomas Knoll, 2016-01-20,
<draft-knoll-idr-qos-attribute-17.txt>
This document specifies a simple signalling mechanism for interdomain QoS marking using several instances of a new BGP Extended
Community. Class based packet marking and forwarding is currently
performed independently within ASes. The new QoS marking community
makes the targeted Per Hop Behaviour within the IP prefix advertising
AS and the currently applied marking at the interconnection point
known to all access and transit ASes. This enables individual
(re-)marking and possibly forwarding treatment adaptation to the
original QoS class setup of the respective originating AS. The
extended community provides the means to signal QoS markings on
different layers, which are linked together in QoS Class Sets. It
provides inter-domain and cross-layer insight into the QoS class
mapping of the source AS with minimal signalling traffic.
"BGP Class of Service Interconnection", Thomas Knoll, 2015-11-14,
<draft-knoll-idr-cos-interconnect-15.txt>
This document focuses on Class of Service Interconnection at interdomain interconnection points. It specifies two new transitive
attributes, which enable adjacent peers to signal Class of Service
Capabilities and certain Class of Service admission control
Parameters. The new "CoS Capability" is deliberately kept simple and
denotes the general EF, AF Group BE and LE forwarding support across
the advertising AS. The second "CoS Parameter Attribute" is of
variable length and contains a more detailed description of available
forwarding behaviours using the PHB id Code encoding. Each PHB id
Code is associated with rate and size based traffic parameters, which
will be applied in the ingress AS Border Router for admission control
purposes to a given forwarding behaviour.
"Takeover Suggestion Flag for the ENRP Handle Update Message", Thomas
Dreibholz, Xing Zhou, 2016-01-08,
<draft-dreibholz-rserpool-enrp-takeover-15.txt>
This document describes the Takeover Suggestion Flag for the
ENRP_HANDLE_UPDATE message of the ENRP protocol.
"HTTP Live Streaming", Roger Pantos, William May, 2016-04-04,
<draft-pantos-http-live-streaming-19.txt>
This document describes a protocol for transferring unbounded streams
of multimedia data. It specifies the data format of the files and
the actions to be taken by the server (sender) and the clients
(receivers) of the streams. It describes version 7 of this protocol.
"The i;codepoint collation", Bjoern Hoehrmann, 2010-09-14,
<draft-hoehrmann-cp-collation-01.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.

"LISP Mobile Node", Dino Farinacci, Darrel Lewis, David Meyer, Chris
White, 2016-01-07, <draft-meyer-lisp-mn-14.txt>
This document describes how a lightweight version of LISP's ITR/ETR
functionality can be used to provide seamless mobility to a mobile
node. The LISP Mobile Node design described in this document uses
standard LISP functionality to provide scalable mobility for LISP
mobile nodes.
"Revised IAOC Membership", John Klensin, 2016-02-12,
<draft-klensin-iaoc-member-01.txt>
The original specification of the membership of the IAOC included the
IETF and IAB Chairs as voting members. While probably desirable
initially, this has turned out to have unfortunate side effects.
This document discusses those side effects and replaces those
specific individuals with liaisons from the IAB and IESG.
"A Uniform Resource Name (URN) Namespace for Sources of Law (LEX)",
PierLuigi Spinosa, Enrico Francesconi, Caterina Lupo, 2014-03-20,
<draft-spinosa-urn-lex-09.txt>
This document describes a Uniform Resource Name (URN) Namespace
Identification (NID) convention as prescribed by the World Wide Web
Consortium (W3C) for identifying, naming, assigning, and managing
persistent resources in the legal domain.
"Network News Transfer Protocol (NNTP) Extension for Compression",
Kenneth Murchison, 2015-11-12, <draft-murchison-nntp-compress-02.txt>
This memo defines an extension to the Network News Transport Protocol
(NNTP) to allow a connection to be effectively and efficiently
compressed.
"Management Information Base for the Group Domain of Interpretation",
Yogesh Sharma, Rohini Kamath, Amjad Inamdar, 2016-04-13,
<draft-kamarthy-gdoi-mib-01.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols. In particular this
document describes a high-level Management Information Base for Group
Domain of Interpretation (GDOI), which is used for secure group
communication in Ipsec-based networks. This draft describes managed
objects used for implementations of the GDOI protocol.
"HIP-based Virtual Private LAN Service (HIPLS)", Thomas Henderson,
Steven Venema, David Mattes, 2016-01-31,
<draft-henderson-hip-vpls-10.txt>
The Host Identity Protocol (HIP) and architecture adds a
cryptographic name space to name Internet hosts. This draft
describes a use case of the HIP architecture, which is to provide a
HIP-enabled virtual private LAN service (VPLS) over an untrusted
network. In this case, HIP is used to secure tunnels between the
provider edge (PE) equipment.
"Group Key Management using IKEv2", Brian Weis, Yoav Nir, Valery
Smyslov, 2016-03-21, <draft-yeung-g-ikev2-10.txt>

This document presents a new group key distribution protocol. The

protocol is in conformance with MSEC key management architecture it
contains two components: member registration and group rekeying, both
downloading group security associations from the Group Controller Key
Server to a member of the group. The new protocol is similar to
IKEv2 in message and payload formats as well as message semantics.
"Xon/Xoff State Control for Telnet Com Port Control Option", Grant
Edwards, 2010-03-23,
<draft-edwards-telnet-xon-xoff-state-control-00.txt,.pdf>
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.
"Load Sharing for the Stream Control Transmission Protocol (SCTP)", Paul
Amer, Martin Becke, Thomas Dreibholz, Nasif Ekiz, Jana Iyengar, Preethi
Natarajan, Randall Stewart, Michael Tuexen, 2015-11-30,
<draft-tuexen-tsvwg-sctp-multipath-11.txt>
The Stream Control Transmission Protocol (SCTP) supports multi-homing
for providing network fault tolerance. However, mainly one path is
used for data transmission. Only timer-based retransmissions are
carried over other paths as well.
This document describes how multiple paths can be used simultaneously
for transmitting user messages.
"Clarification of Proper Use of "@" (at sign) in URI-style Components",
Robert Simpson, 2010-07-30, <draft-accilent-at-sign-00.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.
"Hosts with Any Network Connectivity Using "Bump-in-the-API"(BIA)", Ala
Hamarsheh, 2011-01-19, <draft-hamarsheh-behave-biav2-05.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.
"Hypertext Transfer Protocol (HTTP) Digest Authentication Using GSM 2G

Authentication and Key Agreement (AKA)", Lionel Morand, 2014-04-14,

<draft-morand-http-digest-2g-aka-05.txt>
This document specifies a one-time password generation mechanism for
Hypertext Transfer Protocol (HTTP) Digest access authentication based
on Global System for Mobile Communications (GSM) authentication and
key generation functions A3 and A8, also known as GSM AKA or 2G AKA.
The HTTP Authentication Framework includes two authentication
schemes: Basic and Digest. Both schemes employ a shared secret based
mechanism for access authentication. The GSM AKA mechanism performs
user authentication and session key distribution in GSM and Universal
Mobile Telecommunications System (UMTS) networks. GSM AKA is a
challenge-response based mechanism that uses symmetric cryptography.
"DNSSEC Trust Anchor Publication for the Root Zone", Joe Abley, Jakob
Schlyter, G. Bailey, 2016-01-03,
<draft-jabley-dnssec-trust-anchor-13.txt>
The root zone of the Domain Name System (DNS) has been
cryptographically signed using DNS Security Extensions (DNSSEC).
In order to obtain secure answers from the root zone of the DNS using
DNSSEC, a client must configure a suitable trust anchor. This
document describes how such trust anchors are published.
"Extensions to Path Computation Element Communication Protocol (PCEP)
for Backup Ingress of a Traffic Engineering Label Switched Path", Huaimo
Chen, 2016-03-18, <draft-chen-pce-compute-backup-ingress-09.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.
"Extensions to the Path Computation Element Communication Protocol
(PCEP) for Backup Egress of a Traffic Engineering Label Switched Path",
Huaimo Chen, 2016-03-18, <draft-chen-pce-compute-backup-egress-09.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.
"SCTP Socket API Extensions for Concurrent Multipath Transfer", Thomas
Dreibholz, Martin Becke, Hakim Adhari, 2016-02-09,
<draft-dreibholz-tsvwg-sctpsocket-multipath-12.txt>
This document describes extensions to the SCTP sockets API for
configuring the CMT-SCTP and CMT/RP-SCTP extensions.
"Sender Queue Info Option for the SCTP Socket API", Thomas Dreibholz,
Robin Seggelmann, Martin Becke, 2016-02-09,
<draft-dreibholz-tsvwg-sctpsocket-sqinfo-12.txt>
This document describes an extension to the SCTP sockets API for
querying information about the sender queue.
"Definition of Managed Objects for SAVI Protocol", Changqing An, Jiahai

Yang, Jianping Wu, Jun Bi, 2015-12-15, <draft-an-savi-mib-10.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.
"Encoding the graphemes of the SignWriting Script with the x-ISWA-2010",
Stephen Slevinski, Valerie Sutton, 2011-01-03,
<draft-slevinski-iswa-2010-00.txt>
For concreteness, because the universal character set is not yet
universal, because an undocumented and unlabeled coded character set
hampers information interchange, a 12-bit coded character set has
been created that encodes the graphemes of the SignWriting script as
described in the open standard of the International SignWriting
Alphabet 2010. The x-ISWA-2010 coded character set is defined with
hexadecimal characters and described with Unicode characters, either
proposed characters on plane 1 or interchange characters on plane 15.
This memo defines a standard coded character set for the Internet
community. It is published for reference, examination,
implementation, and evaluation. Distribution of this memo is
unlimited.
"Retransmission Timeout Considerations", Mark Allman, 2015-11-23,
<draft-allman-tcpm-rto-consider-03.txt>
Each implementation of a retransmission timeout mechanism must
balance correctness and timeliness and therefore no implementation
is suits all situations. This document provides for high-level
guidance for retransmission timeout schemes appropriate for general
use in the Internet. Within the guidelines, implementations have
latitude to define particulars that best address each situation.
Terminology
"Multipath TCP Support for Single-homed End-systems", Rolf Winter,
Michael Faath, Andreas Ripke, 2016-03-21,
<draft-wr-mptcp-single-homed-07.txt>
Multipath TCP relies on the existence of multiple paths between endsystems. These are typically provided by using different IP
addresses obtained by different ISPs at the end-systems. While this
scenario is certainly becoming increasingly a reality (e.g. mobile
devices), currently most end-systems are single-homed (e.g. desktop
PCs in an enterprise). It seems also likely that a lot of network
sites will insist on having all traffic pass a single network element
(e.g. for security reasons) before traffic is split across multiple
paths. This memo therefore describes mechanisms to make multiple
paths available to multipath TCP-capable end-systems that are not
available directly at the end-systems but somewhere within the
network.
"A Forward-Search P2P TE LSP Inter-Domain Path Computation", Huaimo
Chen, Dhruv Dhody, 2016-03-18,
<draft-chen-pce-forward-search-p2p-path-computation-11.txt>
This document presents a forward search procedure for computing paths
for Point-to-Point (P2P) Traffic Engineering (TE) Label Switched

Paths (LSPs) crossing a number of domains using multiple Path

Computation Elements (PCEs). In addition, extensions to the Path
Computation Element Communication Protocol (PCEP) for supporting the
forward search procedure are described.
"Route Flap Damping Deployment Status Survey", Shishio Tsuchiya, Seiichi
Kawamura, Randy Bush, Cristel Pelsser, 2012-06-21,
<draft-shishio-grow-isp-rfd-implement-survey-05.txt>
BGP Route Flap Damping [RFC2439] is a mechanism that targets route
stability. It penalyzes routes that flap with the aim of reducing
CPU load on the routers.
But it has side-effects. Thus, in 2006, RIPE recommended not to use
Route Flap Damping (see [RIPE-378]).
Now, some researchers propose to turn RFD, with less aggressive
parameters, back on [draft-ymbk-rfd-usable].
This document describes results of a survey conducted among service
provider on their use of BGP Route Flap Damping.
"A Forward-Search P2MP TE LSP Inter-Domain Path Computation", Huaimo
Chen, Dhruv Dhody, 2016-03-18,
<draft-chen-pce-forward-search-p2mp-path-10.txt>
This document presents a forward search procedure for computing a
path for a Point-to-MultiPoint (P2MP) Traffic Engineering (TE) Label
Switched Path (LSP) crossing a number of domains through using
multiple Path Computation Elements (PCEs). In addition, extensions
to the Path Computation Element Communication Protocol (PCEP) for
supporting the forward search procedure are described.
"A SAVI Solution for WLAN", Jun Bi, Jianping Wu, You Wang, Tao Lin,
2016-02-01, <draft-bi-savi-wlan-09.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.
"A Taxonomy on Private Use Fields in Protocols", Chris Lonvick,
2016-04-10, <draft-lonvick-private-tax-10.txt>
This document attempts to provide some clarification for the way that
private use fields have been used in protocols developed in the IETF.
It is strictly a taxonomy of what has been published and offers a
minimal amount of advice about how to design or use private use
options.
"Supporting Explicit Inclusion or Exclusion of Abstract Nodes for a
Subset of P2MP Destinations in Path Computation Element Communication
Protocol (PCEP).", Dhruv Dhody, Udayasree Palle, Venugopal Kondreddy,
2016-02-24, <draft-dhody-pce-pcep-p2mp-per-destination-09.txt>

The ability to determine paths of point-to-multipoint (P2MP)

Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS)
Traffic Engineering Label Switched Paths (TE LSPs) is one the key
requirements for Path Computation Element (PCE). The RFC 6006 and
RFC 7334 describes these mechanisms for intra and inter domain path
computation via PCE(s).
This document describes the motivation and PCEP extension for
explicitly specifying abstract nodes for inclusion or exclusion for a
subset of destinations during P2MP path computation via PCE(s).
"RBridges: TRILL Link Data Optimizations", Radia Perlman, Donald
Eastlake, Li Yizhou, Anoop Ghanwani, 2016-04-04,
<draft-perlman-trill-rbridge-data-encoding-05.txt>
TRILL (TRansparent Interconnection of Lots of Links) Data frames can
be encoded so as to make more efficient use of communications links
under certain circumstances. This document specifies two such
optional optimizations. One, called Compact Format, improves the
compactness of encoding where a TRILL link is a point-to-point
Ethernet link. The other, called Specific Addressing, optionally
decreases the burden on multi-access TRILL links for multidestination TRILL Data frames. This document updates RFC 6325.
"Non-Normative Synonyms in RFCs", Tony Hansen, dcrocker, 2016-02-26,
<draft-hansen-nonkeywords-non2119-04.txt>
Specifications in RFCs contain normative keywords, as defined in RFC
2119, to signify requirements, permission or prohibitions. These
include MUST, SHOULD and MAY, which are commonly recorded in all
CAPITALS (but need not be). The RFC 2119 words are sometimes also
used with non-normative meaning; this non-normative usage can be
confusing and it is better to restrict the RFC 2119 words to be used
solely as normative directives.
Happily, natural languages permit variation in phrasing, so that
meaning can be retained without use of this otherwise-normative
vocabulary. For such situations, this document provides some
alternatives to the normative vocabulary of RFC 2119.
"User-Managed Access (UMA) Profile of OAuth 2.0", Thomas Hardjono, Eve
Maler, Maciej Machulak, Domenico Catalano, 2016-01-26,
<draft-hardjono-oauth-umacore-14.txt>
User-Managed Access (UMA) is a profile of OAuth 2.0. UMA defines how
resource owners can control protected-resource access by clients
operated by arbitrary requesting parties, where the resources reside
on any number of resource servers, and where a centralized
authorization server governs access based on resource owner policies.
"BGPSEC Design Choices and Summary of Supporting Discussions",
Kotikalapudi Sriram, 2016-01-02,
<draft-sriram-bgpsec-design-choices-09.txt>
This document has been written to capture the design rationale for
the individual draft-00 version of BGPSEC protocol specification (ID.lepinski-bgpsec-protocol-00). It lists the decisions that were
made in favor of or against each design choice, and presents brief
summaries of the arguments that aided the decision process. A

similar document can be published in the future as the BGPSEC design

discussions make further progress and additional design
considerations are discussed and finalized.
"TFRC-based Congestion Control for Saratoga", Wesley Eddy, Lloyd Wood,
Will Ivancic, 2016-05-03, <draft-eddy-tsvwg-saratoga-tfrc-09.txt>
This
with
that
they

document specifies the use of TCP-Friendly Rate Control (TFRC)

the Saratoga data transfer protocol. The necessary conventions
a Saratoga sender and receiver implementation must follow if
wish to enable the use of TFRC are described.

"Congestion control for the Saratoga protocol", Lloyd Wood, Wesley Eddy,
Will Ivancic, 2016-05-03,
<draft-wood-tsvwg-saratoga-congestion-control-09.txt>
Saratoga is a data transfer protocol designed to carry potentially
large volumes of data over difficult network paths, often including
only a single high-rate link and only one application flow. As the
requirements for use vary across deployment environments, the base
Saratoga specification only assumes that an implementation will be
able to clock packets out at a configurable rate, and beyond this
specifies no inherent or particular congestion-control behaviour.
The design of Saratoga deliberately supports the integration of
congestion-control algorithms without modification to the base
protocol. This document describes how congestion control can be
supported in the Saratoga transfer protocol. Saratoga is intended
for use in private networks, where its use is engineered as a single
flow to fill a link. However, as Saratoga is implemented over UDP,
it can be multiplexed, and can be run across the public Internet, in
which case congestion control in accordance with the UDP Guidelines
becomes necessary.
"Extended IPv6 Addressing for Encoding Port Range", Congxiao Bao, Xing
Li, 2016-01-03, <draft-bcx-behave-address-fmt-extension-09.txt>
This document discusses an extension of the algorithmic translation
between IPv4 and IPv4-translatable IPv6 addresses. The extended
address format contains transport-layer port set identification
(PSID) which allows several IPv6 nodes to share a single IPv4 address
with each node managing a different range of ports. This address
format extension can be used for IPv4/IPv6 translation, as well as
IPv4 over IPv6 tunneling.
"Cross Stratum Optimization Architecture for Optical as a Service", Hui
Yang, Yongli Zhao, Jie Zhang, Young Lee, Yi Lin, Fatai Zhang,
2015-11-16, <draft-yangh-cso-oaas-09.txt>
Data centers based applications provide a wide variety of services
such as cloud computing, video gaming, grid application and others.
Currently application decisions are made with little information
concerning underlying network used to deliver those services so that
such decisions cannot be the most optimal from both network and
application resource utilization and quality of service objectives.
This document presents a novel architecture of Cross Stratum
Optimization for application and network resource in dynamic optical
networks. Several global load balancing strategies are proposed and
demonstrated by experiments in Optical as a Service experimental
environment.

"The Lightweight On-demand Ad hoc Distance-vector Routing Protocol Next Generation (LOADng)", Thomas Clausen, Axel Verdiere, Jiazi Yi,
Afshin Niktash, Yuichi Igarashi, Hiroki Satoh, Ulrich Herberg, Cedric
Lavenu, Thierry Lys, Justin Dean, 2016-01-07,
<draft-clausen-lln-loadng-14.txt>
This document describes the Lightweight Ad hoc On-Demand - Next
Generation (LOADng) distance vector routing protocol, a reactive
routing protocol intended for use in Mobile Ad hoc NETworks (MANETs).
"A General Framework of Source Address Validation and Traceback for
IPv4/IPv6 Transition Scenarios", DENG Hui, Guangwu Hu, Jun Bi, Mingwei
Xu, Fan Shi, 2015-11-10, <draft-xu-savi-transition-08.txt>
SAVI (Source Address Validation Improvement) is an excellent
mechanism for anti-IP-spoofing, which was advocated by IETF but only
focused on single-stack or simple network scenarios right now. To the
best of our knowledge, existing studies have not paid attention to
the IPv4/IPv6 transition scenarios. However, since IPv4/IPv6
transition schemes are plenty and various, one solution cannot meet
all requirements of them. In this draft, we present a SAVI-based
general framework for IP source address validation and traceback in
the IPv4/IPv6 transition scenarios, which achieve this by extracting
out essential and mutual properties from these schemes, and forming
sub-solutions for each property. When one transition scheme is
composed from various properties, its IP source address validation
and traceback solution is directly comprised by the corresponding
sub-solutions. Thus, the most exciting advantage of this framework is
that it is a once-and-for-all solution no matter how transition
schemes change. Till now, this proposal was approved by China
Communications Standards Association (CCSA), and we will actively
promote it to apply real network scenarios.
"SAVI Requirements and Solutions for ISP IPv6 Access Network", Fan Shi,
DENG Hui, Liang Zhu, Guangwu Hu, Yang Bo, 2015-12-02,
<draft-shi-savi-access-08.txt>
Internet is always confronted with many security threats based on IP
address spoofing which can enable impersonation and malicious traffic
redirection. Unfortunately, the Internet architecture fails to
provide the defense mechanism. Source Address Validation Improvement
(SAVI) was developed to prevent IP source address spoofing.
Especially, the mechanism is essential for ISPs. However, due to the
diversity of address assignment methods, SAVI solution is also
different accordingly. This document describes five scenarios of
ISPs'IPv6 access network, and moreover, states its SAVI requirements
and tentative solutions accordingly.
"A PMIPv6-based solution for Distributed Mobility Management", Carlos
Bernardos, Antonio de la Oliva, Fabio Giust, 2016-03-14,
<draft-bernardos-dmm-pmip-06.txt>
The number of mobile users and their traffic demand is expected to be
ever-increasing in future years, and this growth can represent a
limitation for deploying current mobility management schemes that are
intrinsically centralized, e.g., Mobile IPv6 and Proxy Mobile IPv6.
For this reason it has been waved a need for distributed and dynamic
mobility management approaches, with the objective of reducing
operators' burdens, evolving to a cheaper and more efficient

architecture.
This draft describes multiple solutions for network-based distributed
mobility management inspired by the well known Proxy Mobile IPv6.
"Unified User-Agent String", Mateusz Karcz, 2014-11-10,
<draft-karcz-uuas-01.txt>
User-Agent is a HTTP request-header field. It contains information
about the user agent originating the request, which is often used by
servers to help identify the scope of reported interoperability
problems, to work around or tailor responses to avoid particular user
agent limitations, and for analytics regarding browser or operating
system use. Over the years contents of this field got complicated
and ambiguous. That was the reaction for sending altered version of
websites to web browsers other than popular ones. During the
development of the WWW, authors of the new web browsers used to
construct User-Agent strings similar to Netscape's one. Nowadays
contents of the User-Agent field are much longer than 15 years ago.
This Memo proposes the Uniform User-Agent String as a way to simplify
the User-Agent field contents, while maintaining the previous
possibility of their use.
"Problem Statement of SAVI Beyond the First Hop", Jun Bi, Bingyang Liu,
2015-11-10, <draft-bi-savi-problem-10.txt>
IETF Source Address Validation Improvements (SAVI) working group is
chartered for source address validation within the first hop from the
end hosts, i.e., preventing a node from spoofing the IP source
address of another node in the same IP link. However, since SAVI
requires the edge routers or switches to be upgraded, the deployment
of SAVI will need a long time. During this transition period, some
source address validation techniques beyond the first hop (SAVI-BF)
may be needed to complement SAVI and protect the networks from
spoofing based attacks. In this document, we first propose three
desired features of the SAVI-BF techniques. Then we analyze the
problems of the current SAVI-BF technique, ingress filtering.
Finally, we discuss the directions that we can explore to improve
SAVI-BF.
"Tunneling Compressing and Multiplexing (TCM) Traffic Flows. Reference
Model", Jose Saldana, Dan Wing, Julian Navajas, Muthu Perumal, Fernando
Blanco, 2015-12-14, <draft-saldana-tsvwg-tcmtf-10.txt,.pdf>
Tunneling, Compressing and Multiplexing (TCM) is a method for
improving the bandwidth utilization of network segments that carry
multiple small-packet flows in parallel sharing a common path. The
method combines different protocols for header compression,
multiplexing, and tunneling over a network path for the purpose of
reducing the bandwidth consumption. The amount of packets per second
can be reduced at the same time.
This document describes the TCM framework and the different options
which can be used for each of the three layers (header compression,
multiplexing and tunneling).
"SNMPD to use cache and shared database based on MIB Classification",
Haresh Khandelwal, 2012-03-29,
<draft-haresh-sushrut-mib-classification-01.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.
"IPv6 Prefix Properties", Jouni Korhonen, Sri Gundavelli, Pierrick
Seite, Dapeng Liu, 2016-02-25,
<draft-korhonen-dmm-prefix-properties-05.txt>
This specification defines an extension to the IPv6 stateless address
autoconfiguration procedure. New options with meta data are defined
that describe the properties and other prefix class meta data
associated with the prefix. The stateless address autoconfiguration
procedure and end hosts can make use of the additional properties and
class information when selecting source address prefixes for a
particular uses and use cases. This specification updates RFC4862.
"A Stateless Transport Tunneling Protocol for Network Virtualization
(STT)", Bruce Davie, Jesse Gross, 2016-04-28, <draft-davie-stt-08.txt>
Network Virtualization places unique requirements on tunneling
protocols. This draft describes STT (Stateless Transport Tunneling),
a tunnel encapsulation that enables overlay networks to be built in
virtualized networks. STT is particularly useful when some tunnel
endpoints are in end-systems, as it utilizes the capabilities of the
network interface card to improve performance. This draft documents
the protocol and the rationale for its design, and highlights issues
that may arise in deployments.
"Analysis of Algorithms For Deriving Port Sets", Tina Tsou, Tetsuya
Murakami, Simon Perreault, 2013-05-17,
<draft-tsou-softwire-port-set-algorithms-analysis-04.txt>
This memo analyzes some port set definition algorithms used for
stateless IPv4 to IPv6 transition technologies. The transition
technologies using port set algorithms can be divided into two
categories: fully stateless approach and binding approach. Some
algorithms can work for both approaches.
"PMIPv6-based distributed anchoring", Carlos Bernardos, JC Zuniga,
2016-03-14, <draft-bernardos-dmm-distributed-anchoring-07.txt>
Distributed Mobility Management solutions allow for setting up
networks so that traffic is distributed in an optimal way and does
not rely on centralized deployed anchors to provide IP mobility
support.
There are many different approaches to address Distributed Mobility
Management, as for example extending network-based mobility protocols
(like Proxy Mobile IPv6), or client-based mobility protocols (as
Mobile IPv6), among others. This document follows the former
approach, and proposes a solution based on Proxy Mobile IPv6 in which
mobility sessions are anchored at the last IP hop router (called
distributed gateway). The distributed gateway is an enhanced access
router which is also able to operate as local mobility anchor or
mobility access gateway, on a per prefix basis. The draft focuses on
the required extensions to effectively support simultaneously
anchoring several flows at different distributed gateways.

This draft introduces the concept of distributed logical interface

(at the distributed gateway), which is a software construct that
allows to easily hide the change of anchor from the mobile node.
Additionally, the draft describes how to provide session continuity
in inter-domain scenarios in which dynamic tunneling or signaling
between distributed gateways from different operators is not allowed.
"The Applicability of the PCE to Computing Protection and Recovery Paths
for Single Domain and Multi-Domain Networks.", Huaimo Chen, Dhruv Dhody,
2016-03-18, <draft-chen-pce-protection-applicability-08.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.
"Diameter AVP Level Security: Keyed Message Digests, Digital Signatures,
and Encryption", Jouni Korhonen, Hannes Tschofenig, 2016-02-29,
<draft-korhonen-dime-e2e-security-03.txt>
This document defines an extension for end to end authentication,
integrity and confidentiality protection of Diameter Attribute Value
Pairs. The solutions focuses on protecting Diameter Attribute Value
Pairs and leaves the key distribution solution to a separate
specification. The integrity protection can be introduced in a
backward compatible manner to existing application. The
confidentiality protection requires an explicit support from an
application, thus is applicable only for newly defined applications.
Terminology
"NAT traversal for LISP", Vina Ermagan, Dino Farinacci, Darrel Lewis,
Jesper Skriver, Fabio Maino, Chris White, 2016-02-25,
<draft-ermagan-lisp-nat-traversal-10.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.
"LISP-DDT Referral Internet Groper (RIG)", Dino Farinacci, Amit Jain,
Isidor Kouvelas, Darrel Lewis, 2014-12-16,
<draft-farinacci-lisp-rig-05.txt>

A simple tool called the LISP-DDT Referral Internet Groper or 'rig'

can be used to query the LISP-DDT hierarchy. This draft describes
how the 'rig' tool works.
"LISP Traffic Engineering Use-Cases", Dino Farinacci, Michael Kowal,
Parantap Lahiri, 2016-03-14, <draft-farinacci-lisp-te-10.txt>
This document describes how LISP reencapsulating tunnels can be used
for Traffic Engineering purposes. The mechanisms described in this
document require no LISP protocol changes but do introduce a new
locator (RLOC) encoding. The Traffic Engineering features provided
by these LISP mechanisms can span intra-domain, inter-domain, or
combination of both.
"DNS Multiple QTYPEs", Ray Bellis, 2016-04-14,
<draft-bellis-dnsext-multi-qtypes-02.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.
"DNS Extension for Autonomous Internet(AIP)", Diao Yuping, Diao
Yongping, Ming Liao, 2016-01-03, <draft-diao-aip-dns-08.txt>
With the reality of Internet, Autonomous Internet technology
in this article constructs independent autonomous extensible domain
name architecture and domain name hierarchy through current domain
name architecture, provides independent root DNS server, inner/outer
DNS resolution mechanism for each autonomous internet network system,
and provides reformation and transition solution from current
Internet to realize autonomy even in unilateral technical action.
"An FTP Application Layer Gateway (ALG) for IPv4-to-IPv6 Translation",
Tina Tsou, Simon Perreault, Jing Huang, 2013-09-16,
<draft-tsou-behave-ftp46-01.txt>
An FTP ALG for NAT64 was defined in RFC 6384. Its scope was limited
to an IPv6 client connecting to an IPv4 server. This memo supports
the case of an IPv4 client connecting to an IPv6 server.
"Intra-CDN Provider CDNi Experiment", Ge Chen, Mian Li, Hongfei Xia,
Bhumip Khasnabish, Jie Liang, 2016-01-31,
<draft-chen-cdni-intra-cdn-provider-cdni-experiment-04.txt>
In [RFC6770], the Inter-Affiliates CDN Interconnection use case is
described. In this scenario, a large CDN Provider may have several
autonomous or semi-autonomous subsidiaries that each operates on
their own CDN. The CDN Provider needs to make these down-stream CDNs
interoperate to provide a consistent service to its customers on the
whole collective footprint.
This document illustrates in details the CDNi experiment that has
been carried out by China Telecom, and the lessons and experiences to
CDNi standardization work.
"Deprecation of AS_SET and AS_CONFED_SET in BGP", Warren Kumari,
Kotikalapudi Sriram, 2016-01-01,
<draft-kumari-deprecate-as-set-confed-set-07.txt>
RFC 6472 (i.e., BCP 172) recommends not using AS_SET and

AS_CONFED_SET in BGP. This document updates RFC 4271 and proscribes

the use of the AS_SET and AS_CONFED_SET types of the AS_PATH in
BGPv4. This is done to simplify the design and implementation of BGP
and to make the semantics of the originator of a route more clear.
This will also simplify the design, implementation, and deployment of
ongoing work in the Secure Inter-Domain Routing Working Group.
"<Green Usage Monitoring Information Base>", Takuo Suganuma, Naoki
Nakamura, Satoru Izumi, Hiroshi Tsunoda, Masahiro Matsuda, Kohei Ohta,
2016-01-25, <draft-suganuma-greenmib-07.txt>
This memo defines a portion of the Management Information Base (MIB),
the GreenUsage-MIB, for use with network management protocols
in the Internet community. In particular, the GreenUsage-MIB
can be used to monitor the power-on/power-off status of electrical
devices.
"MAP Interoperability Testing Results", Xing Li, Congxiao Bao, Guoliang
Han, Wojciech Dec, 2016-01-03, <draft-xli-softwire-map-testing-07.txt>
This document presents the testing results of a unified code
accommodating encapsulation and translation modes of Mapping of
Address and Port (MAP). Experiments show that the unified MAP CE is
not only supporting MAP-E and MAP-T modes, but also backward
compatible with AFTR of dual-stack lite and stateless/stateful NAT64.
"Filtering of Overlapping Routes", Russ White, Alvaro Retana, Susan
Hares, 2016-04-04, <draft-white-grow-overlapping-routes-04.txt>
This document proposes an optional mechanism to remove a prefix when
it overlaps with a functionally equivalent shorter prefix. The
proposed mechanism does not require any changes to the BGP protocol.
"Transparent SDH/SONET over Packet", Gert Manhoudt, Stephan Roullot, Kin
Wong, 2016-01-18, <draft-manhoudt-pwe3-tsop-08.txt>
This document describes the Transparent SDH/SONET over Packet (TSoP)
mechanism to encapsulate Synchronous Digital Hierarchy (SDH) or
Synchronous Optical NETwork (SONET) bit-streams in a packet format,
suitable for Pseudowire (PW) transport over a packet switched network
(PSN). The key property of the TSoP method is that it transports
the SDH/SONET client signal in its entirety through the PW, i.e., no
use is made of any specific characteristic of the SONET/SDH signal
format, other than its bit rate. The TSoP transparency includes
transporting the timing properties of the SDH/SONET client signal.
This ensures a maximum of transparency and a minimum of complexity,
both in implementation and during operation.
"Guidelines for Writing an IANA Considerations Section in RFCs",
Michelle Cotton, Barry Leiba, Thomas Narten, 2016-04-05,
<draft-leiba-cotton-iana-5226bis-12.txt>
Many protocols make use of points of extensibility that use constants
to identify various protocol parameters. To ensure that the values
used in these fields do not have conflicting uses, and to promote
interoperability, their allocation is often coordinated by a central
record keeper. For IETF protocols, that role is filled by the
Internet Assigned Numbers Authority (IANA).
To make assignments in a given registry prudently, IANA needs

guidance describing the conditions under which new values should be

assigned, as well as when and how modifications to existing values
can be made. This document defines a framework for the documentation
of these guidelines by specification authors, in order to assure that
the guidance given to IANA is clear and addresses the various issues
that are likely in the operation of a registry.
This is the third edition of this document; it obsoletes RFC 5226.
"Web Cache Communication Protocol V2, Revision 1", Douglas McLaggan,
2012-08-02, <draft-mclaggan-wccp-v2rev1-00.txt>
This document describes version 2 of the Web Cache Communication
Protocol (WCCP). The WCCP V2 protocol specifies interactions between
one or more routers and one or more web-caches. The interaction may
take place within an IPv4 or IPv6 network. The purpose of the
interaction is to establish and maintain the transparent redirection
of selected types of traffic flowing through a group of routers (or
similar devices). The selected traffic is redirected to a group of
web-caches (or other traffic optimisation devices) with the aim of
optimising resource usage and lowering response times.
The protocol does not specify any interaction between the web-caches
within a group or between a web-cache and a web-server.
"CDNI Footprint & Capabilities Advertisement Interface", Kevin Ma, Jan
Seedorf, 2016-04-23, <draft-ma-cdni-capabilities-09.txt>
Content Distribution Network Interconnection (CDNI) is predicated on
the ability of downstream CDNs (dCDNs) to handle end-user requests in
a functionally equivalent manner to the upstream CDN (uCDN). The
uCDN must be able to assess the ability of the dCDN to handle
individual requests. The CDNI Footprint & Capabilities Advertisement
interface (FCI) is provided for the advertisement of capabilities and
the footprints to which they apply by the dCDN to the uCDN. This
document describes an approach to implementing the CDNI FCI.
"LLCPS", Pascal Urien, 2016-01-18, <draft-urien-tls-llcp-07.txt>
This document describes the support of the TLS protocol over the NFC
(Near Field Communication) LLCP (Logical Link Control Protocol)
layer, which is referred as LLCPS. The NFC peer to peer (P2P)
protocol may be used by any application that needs communication
between two devices at very small distances (a few centimeters).
LLCPS enforces a strong security in NFC P2P exchanges, and may be
deployed for many services, in the Internet of Things (IoT)
ecosystem, such as payments, access control or ticketing operations.
Applications secured by LLCPS are identified by the service name
"urn:nfc:sn:tls:service".
"HIP Diet EXchange (DEX)", Robert Moskowitz, Rene Hummen, 2016-01-20,
<draft-moskowitz-hip-dex-05.txt>
This document specifies the Host Identity Protocol Diet EXchange (HIP
DEX), a variant of the Host Identity Protocol Version 2 (HIPv2). The
HIP DEX protocol design aims at reducing the overhead of the employed
cryptographic primitives by omitting public-key signatures and hash
functions. In doing so, the main goal is to still deliver similar
security properties to HIPv2.

The HIP DEX protocol is primarily designed for computation or memoryconstrained sensor/actuator devices. Like HIPv2, it is expected to
be used together with a suitable security protocol such as the
Encapsulated Security Payload (ESP) for the protection of upper layer
protocol data. In addition, HIP DEX can also be used as a keying
mechanism for security primitives at the MAC layer, e.g., for IEEE
802.15.4 networks.
"The scrypt Password-Based Key Derivation Function", Colin Percival,
Simon Josefsson, 2015-11-20, <draft-josefsson-scrypt-kdf-04.txt>
This document specifies the password-based key derivation function
scrypt. The function derives one or more secret keys from a secret
string. It is based on memory-hard functions which offer added
protection against attacks using custom hardware. The document also
provides an ASN.1 schema.
"A Language for Rules Describing JSON Content", Andrew Newton, Pete
Cordell, 2016-03-21, <draft-newton-json-content-rules-06.txt>
This document describes a language for specifying and testing the
expected content of JSON structures found in JSON-using protocols,
software, and processes.
"Design Discussion and Comparison of Protection Mechanisms for Replay
Attack and Withdrawal Suppression in BGPsec", Kotikalapudi Sriram, Doug
Montgomery, 2016-04-18,
<draft-sriram-replay-protection-design-discussion-06.txt>
In the context of BGPsec, a withdrawal suppression occurs when an
adversary AS suppresses a prefix withdrawal with the intension of
continuing to attract traffic for that prefix based on a previous
(signed and valid) BGPsec announcement that was earlier propagated.
Subsequently if the adversary AS had a BGPsec session reset with a
neighboring BGPsec speaker and when the session is restored, the AS
replays said previous BGPsec announcement (even though it was
withdrawn), then such a replay action is called a replay attack. The
BGPsec protocol should incorporate a method for protection from
Replay Attack and Withdrawal Suppression (RAWS), at least to control
the window of exposure. This informational document provides design
discussion and comparison of multiple alternative RAWS protection
mechanisms weighing their pros and cons. This is meant to be a
companion document to the standards track I-D.-ietf-sidr-bgpsecrollover that will specify a method to be used with BGPsec for RAWS
protection.
"The application/stream+json Media Type", James Snell, 2012-10-11,
<draft-snell-activity-streams-type-01.txt>
This specification defines and registers the application/stream+json
Content Type for the JSON Activity Streams format.
"Cryptographic Security Characteristics of 802.11 Wireless LAN Access
Systems", Stephen Orr, Anthony Grieco, Dan Harkins, 2012-10-15,
<draft-orr-wlan-security-architectures-00.txt>
This note identifies all of the places that cryptography is used in
Wireless Local Area Network (WLAN) architectures, to simplify the
task of selecting the protocols, algorithms, and key sizes needed to
achieve a consistent security level across the entire architecture.

"VRRP PIM Interoperability", Wei Zhou, 2016-03-11,

<draft-zhou-pim-vrrp-06.txt>
This document introduces VRRP Aware PIM, a redundancy mechanism for
the Protocol Independent Multicast (PIM) to interoperate with Virtual
Router Redundancy Protocol (VRRP). It allows PIM to track VRRP state
and to preserve multicast traffic upon failover in a redundant
network with virtual routing groups enabled. The mechanism described
in this document is based on Cisco IOS software implementation.
"Observations on the experience and nature of Large Interim Meetings",
Joel Jaeggli, Jari Arkko, 2013-01-14,
<draft-jaeggli-interim-observations-04.txt>
Planning, particpipation and conclusions from the experience of
participating in the IETF LIM activity on september 29th 2012.
"I-PAKE: Identity-Based Password Authenticated Key Exchange", Taekyoung
Kwon, Hyojin Yoon, Sang Kim, 2013-05-03,
<draft-kwon-yoon-kim-ipake-01.txt>
Although password authentication is the most widespread user
authentication method today, cryptographic protocols for mutual
authentication and key agreement, i.e., password authenticated key
exchange (PAKE), in particular authenticated key exchange (AKE) based
on a password only, are not actively used in the real world. This
document introduces a quite novel form of PAKE protocols that employ
a particular concept of ID-based encryption (IBE). The resulting
cryptographic protocol is the ID-based password authenticated key
exchange (I-PAKE) protocol which is a secure and efficient PAKE
protocol in both soft- and hard-augmented models. I-PAKE achieves the
security goals of AKE, PAKE, and hard-augmented PAKE. I-PAKE also
achieves the great efficiency by allowing the whole pre-computation
of the ephemeral Diffie-Hellman public keys by both server and
client.
"The SignPuddle Standard for SignWriting Text", Stephen Slevinski,
2015-11-11, <draft-slevinski-signwriting-text-06.txt>
For concreteness, because the universal character set is not yet
universal, and because an international standard for the internet
community should be documented and stable, this I-D has been released
with the intention of producing an RFC to document the character use
and naming conventions of the SignWriting community on the Internet.
The SignWriting Script is an international standard for writing sign
languages by hand or with computers. From education to research,
from entertainment to religion, SignWriting has proven useful because
people are using it to write signed languages. The SignWriting
Script has two major families: Block Printing for the reader and
Handwriting for the writer.
Formal SignWriting uses ASCII strings to name logographic signs. The
mathematical names are explained with tokens and regular expression
patterns. Symbol keys reference the symbols of the International
SignWriting Alphabet 2010. Coordinates define X and Y number values
for 2-dimensional placement. Signs are written in a spatial SignBox,
where each symbol is positioned with a 2-dimension coordinate. For
sorting, each sign can have an optional temporal sequence of symbols

that is outside of the SignBox and the visible text. To create

sentences, completed signs are written sequentially, interspersed
with punctuation symbols.
The query language of Formal SignWriting uses a lite markup, similar
to FSW, to define a variety of searching possibilities. The spatial
SignBox can be searched for symbols or ranges of symbols. For each
symbol or range, the search can specify if the symbol only needs to
be found somewhere in the SignBox, or if the symbol needs to be found
near certain coordinates. The temporal sequence can be searched for
starting symbols, written as a sequential list of symbols and ranges
of symbols. When searching the temporal sequence, the search results
will be limited to signs that start with a matching temporal
sequence. Each query string is transformed into one or more regular
expressions. The regular expressions are used to quickly search
large amounts of data.
The styling string of Formal SignWriting uses a lite markup to define
a variety of styling options. The entire sign can be customized for
padding, coloring, and size. Individual symbols within a sign can be
customized for coloring and size.
SignWriting 2010 is the modern implementation and international
specification of the SignWriting Script for the internet community
that includes TrueType Fonts and a compact JavaScript library.
SignMaker is a standards based editor, utilizing HTML, CSS,
JavaScript, SVG, TrueType Fonts, and PNG images. SignMaker can be
used to create a private dictionary or to view dozens of sign
language dictionaries derived from SignPuddle Online.
For Unicode, there are several encodings possibilities. Formal
SignWriting is UTF-8. The plane 15 encoding is isomorphic with
Formal SignWriting strings, using 3 characters for each symbol, along
with structural marker characters and number characters. The plane
16 encoding is focused on the symbols only, using 1 character for
each symbol. The Unicode 8 specification uses 1 to 3 characters on
plane 1 to name each symbol of the International SignWriting Alphabet
2010.
Three appendices discuss additional topics to the standard. The
first discusses the Modern SignWriting theory and example document,
stable since January 12, 2012. The second discusses the symbol
encoding of the International SignWriting Alphabet 2010. The third
discusses the SignPuddle Standards: licences, infrastructure, and
compatibility.
This memo concretely defines a conceptual character encoding map for
the Internet community. It is published for reference, examination,
implementation, and evaluation. Distribution of this memo is
unlimited.
"remoteStorage", Michiel de Jong, F. Kooman, 2015-11-30,
<draft-dejong-remotestorage-06.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.

"OAuth Response Metadata", Nat Sakimura, Nov Matake, Sascha Preibisch,
2016-02-12, <draft-sakimura-oauth-meta-07.txt>
This specification defines an extensible metadata that may be
inserted into the OAuth 2.0 responses to assist the clients to
process those responses. It is expressed either as a link header, or
query parameters. It will allow the client to learn where the
members in the response could be used, what is the characteristics of
the payload is, how it should be processed, and so on. Since they
are just additional response header/query parameters, any client that
does not understand this extension should not break and work normally
while supporting clients can utilize the metadata to take the
advantage of the extension.
"The WebSocket Protocol as a Transport for the Message Session Relay
Protocol (MSRP)", Peter Dunkley, Gavin Llewellyn, Victor Pascual,
Gonzalo Salgueiro, Ram R, 2016-05-03,
<draft-pd-dispatch-msrp-websocket-12.txt>
The WebSocket protocol enables two-way real-time communication
between clients and servers in situations where direct access to TCP
and UDP are not available (for example, from within Javascript in a
web browser). This document specifies a new WebSocket sub-protocol
as a reliable transport mechanism between MSRP (Message Session Relay
Protocol) clients and relays to enable usage of MSRP in new
scenarios. This document normatively updates RFC 4975 and RFC 4976.
"OAuth 2.0 Resource Set Registration", Thomas Hardjono, Eve Maler,
Maciej Machulak, Domenico Catalano, 2016-01-26,
<draft-hardjono-oauth-resource-reg-07.txt>
This specification defines a resource set registration mechanism
between an OAuth 2.0 authorization server and resource server. The
resource server registers information about the semantics and
discovery properties of its resources with the authorization server.
"Self-published IP Geolocation Data", Erik Kline, Krzysztof Duleba,
Zoltan Szamonek, 2013-07-28,
<draft-google-self-published-geofeeds-02.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.
"Autonomous Extensible Internet with Network Address Multiplexing(AEIP
NAM)", Diao Yuping, Diao Yongping, Ming Liao, 2016-02-02,
<draft-diao-aeip-nam-06.txt>
The two key issues of today's Internet are autonomy and
extensibility. Autonomous Internet(AIP) technology can provide
extensible internet architecture, own independent root DNS servers

and self management internet network; Furthermore, based on the

Autonomous Internet, here provides a way with extensible address
capacity to solve IP address deficiency and realize
Autonomous Extensible Internet(AEIP) with global network address
and multiplexing local network address. This AEIP with Network
Address Multiplexing(AEIP NAM) can realize autonomy and extensibility
with minimal cost.
"Ruoska Encoding", JPM, 2013-10-12, <draft-ruoska-encoding-06.txt>
This document describes hierarchically structured binary encoding
format called Ruoska Encoding (later RSK). The main design goals are
minimal resource usage, well defined structure with good selection of
widely known data types, and still extendable for future usage.
The main benefit when compared to non binary hierarchically
structured formats like XML is simplicity and minimal resource
demands. Even basic XML parsing is time and memory consuming
operation.
When compared to other binary formats like BER encoding of ASN.1 the
main benefit is simplicity. ASN.1 with many different encodings is
complex and even simple implementation needs a lot of effort. RSK is
also more efficient than BER.
"IPv6 Source/Destination Routing using IS-IS", Fred Baker, David
Lamparter, 2016-04-17, <draft-baker-ipv6-isis-dst-src-routing-05.txt>
This note describes the changes necessary for IS-IS to route IPv6
traffic from a specified prefix to a specified prefix.
"PCEP Extensions for MPLS-TE LSP Automatic Bandwidth Adjustment with
Stateful PCE", Dhruv Dhody, Udayasree Palle, Ravi Singh, Rakesh Gandhi,
Luyuan Fang, 2016-02-28,
<draft-dhody-pce-stateful-pce-auto-bandwidth-07.txt>
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
"CoAP Communication with Alternative Transports", Bill Silverajan, Teemu
Savolainen, 2015-12-21,
<draft-silverajan-core-coap-alternative-transports-09.txt>
CoAP has been standardised as an application level REST-based
protocol. A single CoAP message is typically encapsulated and
transmitted using UDP or DTLS as transports. These transports are
optimal solutions for CoAP use in IP-based constrained environments
and nodes. However compelling motivation exists for allowing CoAP to
operate with other transports and protocols. Examples are M2M
communication in cellular networks using SMS, more suitable transport
protocols for firewall/NAT traversal, end-to-end reliability and
security such as TCP and TLS, or employing proxying and tunneling
gateway techniques such as the WebSocket protocol. This draft
examines the requirements for conveying CoAP messages to end points
over such alternative transports. It also provides a new URI format
for representing CoAP resources over alternative transports.
"Virtual Machine Mobility Protocol for Overlay Networks", Behcet
Sarikaya, Linda Dunbar, Bhumip Khasnabish, Frank Xia, 2016-03-21,

<draft-sarikaya-nvo3-vmm-dmm-pmip-10.txt>
This document describes a virtual machine mobility protocol commonly
used in data centers built with overlay-based network virtualization
approach. It is based on using a Network Virtualization Authority
(NVA)-Network Virtualization Edge (NVE) protocol to update Address
Resolution Protocol (ARP) table or neighbor cache entries at the NVA
and the source NVEs tunneling in-flight packets to the destination
NVE after the virtual machine moves from source NVE to the
destination NVE.
"Syslog Format for NAT Logging", Zhonghua Chen, Cathy Zhou, Tina Tsou,
Tom Taylor, 2014-01-24, <draft-ietf-behave-syslog-nat-logging-06.txt>
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.
"Cisco Enhanced Interior Gateway Routing Protocol", Donnie Savage, James
Ng, Steven Moore, Donald Slice, Peter Paluch, Russ White, 2016-02-23,
<draft-savage-eigrp-05.txt,.pdf>
This document describes the protocol design and architecture for
Enhanced Interior Gateway Routing Protocol (EIGRP). EIGRP is a routing
protocol based on Distance Vector technology. The specific algorithm
used is called DUAL, a Diffusing Update Algorithm as reference in
"Loop-Free Routing using Diffusing Computations". The algorithm and
procedures were researched, developed, and simulated by SRI
International.
"Autonomous Extensible Internet with Network Address Translation(AEIP
NAT)", Diao Yongping, Ming Liao, Diao Yuping, 2016-04-07,
<draft-diao-aeip-nat-06.txt>
The two key issues of today's Internet are autonomy and
extensibility. Autonomous Internet(AIP) technology can provide
extensible internet architecture, own independent root DNS servers
and self management internet network; Furthermore, based on the
Autonomous Internet, here provides a way with extensible address
capacity to solve IP address deficiency and realize
Autonomous Extensible Internet(AEIP). It mainly adopts local
network address based on per Autonomous IP network and uses
bilateral dynamic NAT with global network address between
Autonomous IP networks to solve IP address deficient problem.
This AEIP with Network Address Translation(AEIP NAT) can realize
autonomy and extensibility with minimal cost.

"An Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices",
David Binet, Mohamed Boucadair, Vizdal Ales, Gang Chen, Nick Heatley,
Ross Chandler, Dave Michaud, Diego Lopez, Walter Haeffner, 2015-12-17,
<draft-ietf-v6ops-mobile-device-profile-24.txt>
This document defines a profile that is a superset of that of the
connection to IPv6 cellular networks defined in the IPv6 for Third
Generation Partnership Project (3GPP) Cellular Hosts document. This
document defines an IPv6 profile that a number of operators recommend
in order to connect 3GPP mobile devices to an IPv6-only or dual-stack
wireless network (including 3GPP cellular network) with a special
focus on IPv4 service continuity features.
Both mobile hosts and mobile devices with capability to share their
3GPP mobile connectivity are in scope.
"Augmented Password-Authenticated Key Exchange for Transport Layer
Security (TLS)", SeongHan Shin, Kazukuni Kobara, 2016-01-21,
<draft-shin-tls-augpake-06.txt>
This document describes an efficient augmented password-authenticated
key exchange (AugPAKE) protocol where a user remembers a low-entropy
password and its verifier is registered in the intended server. In
general, the user password is chosen from a small set of dictionary
whose space is within the off-line dictionary attacks. The AugPAKE
protocol described here is secure against passive attacks, active
attacks and off-line dictionary attacks (on the obtained messages
with passive/active attacks), and also provides resistance to server
compromise (in the context of augmented PAKE security). Based on the
AugPAKE protocol, this document also specifies a new password-only
authentication handshake for Transport Layer Security (TLS) protocol.
"LISP Based FlowMapping for Scaling NFV", sbarkai@gmail.com, Dino
Farinacci, David Meyer, Fabio Maino, Vina Ermagan, Alberto
Rodriguez-Natal, Albert Cabellos-Aparicio, 2015-12-06,
<draft-barkai-lisp-nfv-07.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.
"IPFIX Information Elements for logging NAT Events", Senthil Sivakumar,
Reinaldo Penno, 2016-03-08, <draft-ietf-behave-ipfix-nat-logging-08.txt>
Network operators require NAT devices to log events like creation and
deletion of translations and information about the resources that the
NAT device is managing. The logs are essential in many cases to
identify an attacker or a host that was used to launch malicious
attacks and for various other purposes of accounting. Since there is
no standard way of logging this information, different NAT devices

log the information using proprietary formats and hence it is

difficult to expect a consistent behavior. The lack of a consistent
way to log the data makes it difficult to write the collector
applications that would receive this data and process it to present
useful information. This document describes the formats for logging
of NAT events.
"Mounting YANG-Defined Information from Remote Datastores", Alex Clemm,
Jan Medved, Eric Voit, 2016-03-21, <draft-clemm-netmod-mount-04.txt>
This document introduces capabilities that allow YANG datastores to
reference and incorporate information from remote datastores. This
is accomplished by extending YANG with the ability to define mount
points that reference data nodes in another YANG subtree, by
subsequently allowing those data nodes to be accessed by client
applications as if part of an alternative data hierarchy, and by
providing the necessary means to manage and administer those mount
points. Two flavors are defined: Alias-Mount allows to mount local
subtrees, while Peer-Mount allows subtrees to reside on and be
authoritatively owned by a remote server. YANG-Mount facilitates the
development of applications that need to access data that transcends
individual network devices while improving network-wide object
consistency, or that require an aliasing capability to be able to
create overlay structures for YANG data.
"Implementation Experience of Identifier-Locator Network Protocol for
IPv6 (ILNPv6)", Jun Bi, You Wang, Kai Gao, 2016-05-01,
<draft-bi-rrg-ilnpv6-implementation-experience-06.txt>
The Identifier-Locator Network Protocol (ILNP) defines an
evolutionary enhancement to IP to address multi-homing, mobility as
well as other issues. This document provides experience of
implementing ILNPv6 which is a specific engineering instance of ILNP
based on IPv6. This document describes the problems arisen and our
choices to solve the issues which may be helpful to others in
implementing the protocol.
"Schnorr NIZK Proof: Non-interactive Zero Knowledge Proof for Discrete
Logarithm", Feng Hao, 2016-02-29, <draft-hao-schnorr-03.txt>
This document describes Schnorr NIZK proof, a non-interactive variant
of the three-pass Schnorr identification scheme. The Schnorr NIZK
proof allows one to prove the knowledge of a discrete logarithm
without leaking any information about its value. It can serve as a
useful building block for many cryptographic protocols to ensure the
participants follow the protocol specification honestly. This
document specifies the Schnorr NIZK proof in both the finite field
and the elliptic curve settings.
"J-PAKE: Password Authenticated Key Exchange by Juggling", Feng Hao,
2016-02-29, <draft-hao-jpake-03.txt>
This document specifies a Password Authenticated Key Exchange by
Juggling (J-PAKE) protocol. This protocol allows the establishment
of a secure end-to-end communication channel between two remote
parties over an insecure network solely based on a shared password,
without requiring a Public Key Infrastructure (PKI) or any trusted
third party.
"Connectivity Provisioning Negotiation Protocol (CPNP)", Mohamed

Boucadair, Christian Jacquenet, Dacheng Zhang, Panos Georgatsos,

2016-03-14, <draft-boucadair-connectivity-provisioning-protocol-11.txt>
This document specifies the Connectivity Provisioning Negotiation
Protocol (CPNP) which is used for dynamic negotiation of service
parameters.
CPNP is a generic protocol that can be used for various negotiation
purposes that include (but are not necessarily limited to)
connectivity provisioning services, storage facilities, Content
Delivery Networks footprint, etc. The protocol can be extended with
new Information Elements.
"NSA's Cryptographic Message Syntax (CMS) Key Management Attributes",
Paul Timmel, Russ Housley, spt, 2016-03-15,
<draft-turner-km-attributes-07.txt>
This document defines key management attributes used by the National
Security Agency (NSA). The attributes can appear in asymmetric
and/or symmetric key packages as well as the Cryptographic Message
Syntax (CMS) content types that subsequently envelope the key
packages. Key packages described in RFC 5958 and RFC 6031 are
examples where these attributes can be used.
"Title", Phillip Hallam-Baker, 2016-03-08,
<draft-hallambaker-jsonbcd-05.txt>
Binary Encodings for JavaScript Object Notation: JSON-B, JSON-C,
JSON-D
"Session Description Protocol Support for Tunnels (L2TP)", Anton
Tveretin, 2016-03-15, <draft-tveretin-dispatch-l2tp-sdp-01.txt>
This document registeres new payload type (application/l2tp) to be
used with SDP, and clarifies procedure to be used by peers for L2TP
tunnels.
"GDOI Protocol Support for IEC 62351 Security Services", Brian Weis,
Maik Seewald, Herb Falk, 2016-03-21, <draft-weis-gdoi-iec62351-9-07.txt>
The IEC 61850 power utility automation family of standards describe
methods using Ethernet and IP for distributing control and data
frames within and between substations. The IEC 61850-90-5 and IEC
62351-9 standards specify the use of the Group Domain of
Interpretation (GDOI) protocol (RFC 6407) to distribute security
transforms for some IEC 61850 security protocols. This memo defines
GDOI payloads to support those security protocols.
"Port Control Protocol (PCP) for SIP Deployments in Managed Networks",
Mohamed Boucadair, Parthasarathi Ravindran, 2015-11-26,
<draft-boucadair-pcp-sip-ipv6-07.txt>
This document discusses how PCP (Port Control Protocol) can be used
in SIP deployments in managed networks. This document applies for
both IPv4 and IPv6.
"BGP vector routing.", Robert Raszuk, Keyur Patel, Burjiz Pithawala, Ali
Sajassi, eric.osborne@level3.com, Luay Jalil, Jim Uttaro, 2015-11-22,
<draft-patel-raszuk-bgp-vector-routing-06.txt>

Network architectures have begun to shift from pure destination based

routing to service aware routing. Operator requirements in this
space include forcing traffic through particular service nodes (e.g.
firewall, NAT) or segments. This document proposes an enhancement to
BGP to accommodate these new requirements.
This document proposes a pure control plane solution which allows
traffic to be routed via an ordered set of transit points (links,
nodes or services) on the way to traffic's destination, with no
change in the forwarding plane. This approach is in contrast to
other proposal in this space which provide similar capabilities via
modifications to the forwarding plane.
"CoAP Management Interface", Peter Van der Stok, Andy Bierman,
2016-03-07, <draft-vanderstok-core-comi-09.txt,.pdf>
This document describes a network management interface for
constrained devices, called CoMI. CoMI is an adaptation of the
RESTCONF protocol for use in constrained devices and networks. The
Constrained Application Protocol (CoAP) is used to access management
data resources specified in YANG, or SMIv2 converted to YANG. CoMI
use the YANG to CBOR mapping and encodes YANG names to reduce payload
size.
Note
Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org.
"Message Authorizing Email Header Field and its use for Draft &
Release", Alexey Melnikov, 2016-05-04,
<draft-melnikov-mmhs-authorizing-users-14.txt>
This document describes a procedure for when an Military Message
Handling System (MMHS) message is composed by one user and is only
released to the mail transfer system when one or more authorizing
users authorize release of the message by adding the MMHSAuthorizing-Users header field. The resulting message can be
optionally signed by the sender and/or reviewer, allowing recipients
to verify both the original signature (if any) and review signatures.
"Path Computation Element (PCE) Discovery using Domain Name
System(DNS)", Wenson Wu, Dhruv Dhody, Daniel King, Diego Lopez, Jeff
Tantsura, 2015-12-06, <draft-wu-pce-dns-pce-discovery-09.txt>
Discovery of the Path Computation Element (PCE) within an IGP area or
routing domain is possible using OSPF and IS-IS IGP discovery.
However, it has been established that in certain deployment scenarios
PCEs may not wish, or be able to participate within the IGP process.
In those scenarios, it is beneficial for the Path Computation Client
(PCC) (or other PCE) to discover PCEs via an alternative mechanism to
using an IGP discovery.
This document specifies the requirements, use cases, procedures and
extensions to support PCE discovery along with certain relevant
information type and capability discovery via DNS.
"Asserting DNS Administrative Boundaries Within DNS Zones", Andrew
Sullivan, Jeff Hodges, 2016-02-18,
<draft-sullivan-domain-policy-authority-02.txt>

Some entities on the Internet make inferences about the

administrative relationships among Internet services based on the
domain names at which those services are offered. At present, it is
not possible to ascertain organizational administrative boundaries in
the DNS; therefore such inferences can be erroneous. Mitigation
strategies deployed so far will not scale. This memo provides a
means to make explicit assertions regarding certain kinds of
administrative relationships between domain names.
"IP Flow Performance Measurement Framework", Mach Chen, Lianshu Zheng,
Greg Mirsky, Giuseppe Fioccola, Tal Mizrahi, 2016-03-17,
<draft-chen-ippm-coloring-based-ipfpm-framework-06.txt>
This document specifies a measurement method, the IP flow performance
measurement (IPFPM). With IPFPM, data packets are marked into
different blocks of markers by changing one or more bits of packets.
No additional delimiting packet is needed and the performance is
measured in-service and in-band without the insertion of additional
traffic.
"QoS-level aware Transmission Protocol (QTP) for virtual networks",
Julong Lan, Dongnian Cheng, Yuxiang Hu, Guozhen Cheng, Zhiming Wang, Lu
Sun, 2016-04-19, <draft-lan-nvo3-qtp-03.txt>
This document provides a QoS-level aware Transmission Protocol (QTP)
for virtual networks.
"Stateless user-plane architecture for virtualized EPC (vEPC)", Satoru
Matsushima, Ryuji Wakikawa, 2016-03-21,
<draft-matsushima-stateless-uplane-vepc-06.txt>
We envision a new mobile architecture for the future Evolved Packet
Core (EPC). The new architecture is designed to support the
virtualization scheme called NFV (Network Function Virtualization).
In our architecture, the user plane of EPC is decoupled from the
control-plane and uses routing information to forward packets of
mobile nodes. Although the EPC control plane will run on hypervisor,
our proposal does not modify the signaling of the EPC control plane.
The benefits of our architecture are 1) scalability, 2) flexibility
and 3) Manageability. How to run the EPC control plane on NFV is out
of our focus in this document.
"An IPv6 Distributed Client Mobility Management approach using existing
mechanisms", Carlos Bernardos, Antonio de la Oliva, Fabio Giust,
2016-03-14, <draft-bernardos-dmm-cmip-05.txt>
The use of centralized mobility management approaches -- such as
Mobile IPv6 -- poses some difficulties to operators of current and
future networks, due to the expected large number of mobile users and
their exigent demands. All this has triggered the need for
distributed mobility management alternatives, that alleviate
operators' concerns allowing for cheaper and more efficient network
deployments.
This draft describes a possible way of achieving a distributed
mobility behavior with Client Mobile IP, based on Mobile IPv6 and the
use of Cryptographic Generated Addresses.
"CoAP over WebSockets", Teemu Savolainen, Klaus Hartke, Bill Silverajan,

2016-03-19, <draft-savolainen-core-coap-websockets-06.txt>
This document specifies how to retrieve and update CoAP resources
using CoAP requests and responses over the WebSocket Protocol.
"MPLS Domain Wide Labels", Robert Raszuk, 2015-11-22,
<draft-raszuk-mpls-domain-wide-labels-05.txt>
This document describes a mechanism of using concept of Domain Wide
MPLS Labels in parallel with any of the existing deployments using
other label distribution and allocation methods where multi protocol
label switching paradigm is used for transport. Specifically it
defines a new type of context label which can be used to
differentiate lookup tables when using Domain Wide transport Labels
from other downstream or upstream assigned transport labels. The end
result is creation of clean new label space in data plane allowing
very easy and smooth migration to the number of applications choosing
to use Domain Wide MPLS Labels.
"DNSWL Email Authentication Method Extension", Ale, 2016-04-16,
<draft-vesely-authmethod-dnswl-06.txt>
This document describes an additional Email Authentication Method
compliant with RFC 7601. The method consists in looking up the
sender'IP in a DNS whitelist.
"Using ICN in disaster scenarios", Jan Seedorf, Mayutan Arumaithurai,
Atsushi Tagami, K. Ramakrishnan, Nicola Blefari-Melazzi, 2015-12-29,
<draft-seedorf-icn-disaster-05.txt>
Information Centric Networking (ICN) is a new paradigm where the
network provides users with named content, instead of communication
channels between hosts. This document outlines some research
directions for Information Centric Networking with respect to
applying ICN approaches for coping with natural or human-generated,
large-scale disasters.
"A Framework of Multipath Transport System Based on Application-Level
Relay (MPTS-AR)", Lei Weimin, Wei Zhang, Shaowei Liu, 2016-01-19,
<draft-leiwm-tsvwg-mpts-ar-05.txt>
Multipath transport is an important way to improve the efficiency of
data delivery. This document defines a multipath transport system
framework in which application-level relays are deployed to provide
the conditions to enable multiple paths between source and
destination. In the proposed framework, endpoints are allowed to use
multiple paths, including the default IP path and relay paths, to
transport data in a single session. A relay path may via one or more
application-level relays which provide application-level relay
services for endpoints. This framework defines three kinds of logical
entities including user agent, relay server and relay controller.
Relay server provides relay service for user agents based on a local
path-table. Relay controller manages relay servers and relay paths.
User agent maintains multiple end-to-end paths which include a
default path and multiple relay paths. The framework also defines a
relay service control protocol named OpenPath protocol in control
plane to manage relay servers and relay paths, and a profile of
multipath transport protocol suite in data plane to facilitate
multipath data transport. The multipath transport system framework
can support various applications including applications requiring

timely delivery of real-time data such as streaming media, and

applications requiring ordered reliable delivery of stream of data
such as file transfer.
"Multipath Message Transport Protocol Based on Application-level Relay
(MPMTP-AR)", Lei Weimin, Shaowei Liu, Wei Zhang, 2016-01-18,
<draft-leiwm-tsvwg-mpmtp-ar-05.txt>
Multipath transmission is an important way to improve quality of
service of message transport. This document defines a multipath
message transport protocol based on application level relay (MPMTPAR), which is a special profile of multipath transport protocol suite
defined in Multipath Transport System Based on Application-level
Relay (MPTS-AR). MPMTP-AR is responsible for reliably delivering data
over multiple paths. This document describes those new or changed
features, and expands the MPTP format. Moreover this document
illustrates the details of multipath transmission control mechanism.
"Multipath Real-Time Transport Protocol Based on Application-Level Relay
(MPRTP-AR)", Lei Weimin, Wei Zhang, Shaowei Liu, 2016-01-19,
<draft-leiwm-avtcore-mprtp-ar-05.txt>
Currently, most multimedia applications utilize a combination of
real-time transport protocol (RTP) and user datagram protocol (UDP).
Application programs at the source end format payload data into RTP
packets using RTP specifications and dispatch them using unreliable
UDP along a single path. Multipath transport is an important way to
improve the efficiency of data delivery. In order to apply the
framework of multipath transport system based on application-level
relay (MPTS-AR) to RTP-based multimedia applications, this document
defines a multipath real-time transport protocol based on
application-level relay (MPRTP-AR), which is a concrete
application-specific multipath transport protocol (MPTP). Packet
formats and packet types of MPRTP-AR follow the common rules
specified in MPTP profile. Based on MPRTP-AR, RTP-based multimedia
applications can make full use of the advantages brought by MPTS-AR.
"Remote APDU Call Secure (RACS)", Pascal Urien, 2015-12-21,
<draft-urien-core-racs-06.txt>
This document describes the Remote APDU Call Protocol Secure (RACS)
protocol, dedicated to Grid of Secure Elements (GoSE). These servers
host Secure Elements (SE), i.e. tamper resistant chips offering
secure storage and cryptographic resources.
Secure Elements are microcontrollers whose chip area is about 25mm2;
they deliver trusted computing services in constrained environments.
RACS supports commands for GoSE inventory and data exchange with
secure elements. It is designed according to the representational
State Transfer (REST) architecture. RACS resources are identified by
dedicated URIs. An HTTP interface is also supported.
"Use of the WebSocket Protocol as a Transport for the Remote Framebuffer
Protocol", Nicholas Wilson, 2013-10-07, <draft-realvnc-websocket-02.txt>
The Remote Framebuffer protocol (RFB) enables clients to connect to
and control remote graphical resources. This document describes a
transport for RFB using the WebSocket protocol, and defines a
corresponding WebSocket subprotocol, enabling an RFB server to offer

resources to clients with WebSocket connectivity, such as webbrowsers.

"Requirements and Use Cases for Source/Destination Routing", Fred Baker,
Mingwei Xu, Shu Yang, Jianping Wu, 2016-04-28,
<draft-baker-rtgwg-src-dst-routing-use-cases-02.txt>
This note attempts to capture important use cases for source/
destination routing.
"Use of the Hash-based Merkle Tree Signature (MTS) Algorithm in the
Cryptographic Message Syntax (CMS)", Russ Housley, 2016-03-21,
<draft-housley-cms-mts-hash-sig-04.txt>
This document specifies the conventions for using the Merkle Tree
Signatures (MTS) digital signature algorithm with the Cryptographic
Message Syntax (CMS). The MTS algorithm is one form of hash-based
digital signature.
"CoAP option for no server-response", Abhijan Bhattacharyya, Soma
Bandyopadhyay, Arpan Pal, Tulika Bose, 2016-04-12,
<draft-tcs-coap-no-response-option-16.txt>
There can be M2M scenarios where responses from a server against
requests from client are redundant. This kind of open-loop exchange
(with no response path from the server to the client) may be desired
to minimize resource consumption in constrained systems while
updating a bulk of resources simultaneously, or updating a resource
with a very high frequency. CoAP already provides Non-confirmable
(NON) messages that are not acknowledged by the recipient. However,
the request/response semantics still require the server to respond
with a status code indicating "the result of the attempt to
understand and satisfy the request".
This specification introduces a CoAP option called 'No-Response'.
Using this option the client can explicitly express to the server
its disinterest in all responses against the particular request.
This option also provides granular control to enable expression of
disinterest to a particular class of response or a combination of
response-classes. The server MAY decide to suppress the response by
not transmitting it back to the client according to the value of NoResponse option in the request. This option may be effective for
both unicast and multicast requests. This document also discusses a
few exemplary applications which benefit from this option.
"The TCP Service Number Option (SNO)", Joseph Touch, 2016-04-18,
<draft-touch-tcpm-sno-05.txt>
This document specifies a TCP option for service numbers. The
current SYN destination port is used both to indicate the desired
service and as a connection demultiplexing field. This option
separates those two functions, retaining the current destination
port solely for demultiplexing and indicating the service separately
in a service number option (SNO). By decoupling these two functions,
SNO allows a larger number of concurrent connections for a single
service, as might be useful between fixed addresses of proxies.
"NFS Protocol Extension: Retrospect and Prospect", David Noveck,
2016-03-10, <draft-dnoveck-nfs-extension-04.txt>

This document
been extended
versions. It
that might be

surveys the processes by which the NFS protocols have

in the past, including all of the NFS major and minor
also looks forward to methods of protocol extension
used by NFS in the future.

A particular focus is on how the minor versioning model of NFSv4 has

worked and what is being done to enhance version management within
NFSv4. The work already done in the new NFSv4 version management
document is summarized, and there is a discussion of further issues
the working group will need to address in moving that work forward.
"PCE support for Domain Diversity", Dhruv Dhody, Qin Wu, Udayasree
Palle, Xian Zhang, 2016-04-14, <draft-dwpz-pce-domain-diverse-05.txt>
The Path Computation Element (PCE) may be used for computing path for
services that traverse multi-area and multi-AS Multiprotocol Label
Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE)
networks.
Path computation should facilitate the selection of paths with domain
diversity. This document examines the existing mechanisms to do so
and further propose some extensions to Path Computation Element
Protocol (PCEP).
"GDOI GROUPKEY-PUSH Acknowledgement Message", Brian Weis, Umesh Mangla,
Nilesh Maheshwari, Thomas Karl, 2016-03-21,
<draft-weis-gdoi-rekey-ack-03.txt>
The Group Domain of Interpretation (RFC 6407) includes the ability
for a Group Controller/Key Server (GCKS) to provide a set of current
Group Member (GM) devices with additional security associations
(e.g., to rekey expiring security associations). This memo adds the
ability of a GCKS to request the GM devices to return an
acknowledgement of receipt of its rekey message, and specifies the
acknowledgement method.
"OSPF Routing with Cross-Address Family MPLS Traffic Engineering
Tunnels", Anton Smirnov, Alvaro Retana, Michael Barnes, 2016-04-18,
<draft-smirnov-ospf-xaf-te-05.txt>
When using Traffic Engineering (TE) in a dual-stack IPv4/IPv6 network
the Multiprotocol Label Switching (MPLS) TE Label Switched Paths
(LSP) infrastructure may be duplicated, even if the destination IPv4
and IPv6 addresses belong to the same remote router. In order to
achieve an integrated MPLS TE LSP infrastructure, OSPF routes must be
computed over MPLS TE tunnels created using information propagated in
another OSPF instance. This is solved by advertising cross-address
family (X-AF) OSPF TE information.
This document describes an update to RFC5786 that allows for the easy
identification of a router's local X-AF IP addresses.
"Ideas for a Next Generation of the Reliable Server Pooling Framework",
Thomas Dreibholz, 2016-01-08,
<draft-dreibholz-rserpool-nextgen-ideas-05.txt>
This document collects some idea for a next generation of the
Reliable Server Pooling framework.
"ALTO Traffic Engineering Cost Metrics", Qin Wu, Yang Yang, Young Lee,

Dhruv Dhody, Sabine Randriamasy, 2016-03-21,

<draft-wu-alto-te-metrics-07.txt>
Cost Metric is a basic concept in Application-Layer Traffic
Optimization (ALTO). It is used in both the Cost Map Service and the
Endpoint Cost Service. Future extensions to ALTO may also use Cost
Metric.
Different applications may benefit from different Cost Metrics. For
example, a Resource Consumer may prefer Resource Providers that have
low delay to the Resource Consumer. However the base ALTO protocol
[ALTO] has defined only a single cost metric, i.e., the generic
"routingcost" metric (Sec. 14.2 of ALTO base specification [ALTO]).
In this document, we define eleven Cost Metrics, derived from OSPF-TE
and ISIS-TE, to measure network delay, jitter, packet loss, hop
count, and bandwidth. The metrics defined in this document provide a
relatively comprehensive set of Cost Metrics for ALTO focusing on
traffic engineering (TE). Additional Cost Metrics such as financial
cost metrics may be defined in other documents.
"Routing Optimization with SDN", yangun@dcn.ssu.ac.kr,
gomjae@dcn.ssu.ac.kr, Young-Han Kim, 2016-01-06,
<draft-yang-dmm-sdn-dmm-05.txt>
DMM is a mobility protocol which has mobility functions to solve the
existing problems in the current centralized ones. However, when a
mobile node moves to another anchor, the previous flow is forwarded
by the previous router. For this reason, the routing optimization
could be an issue. This draft proposes a routing optimization method
in distributed anchor architecture. In this draft, we applied the
SDN concept to DMM architecture for routing optimization.
"Transmission of IPv6 Packets over IEEE 802.11 Networks Outside the
Context of a Basic Service Set", Alexandre Petrescu, Nabil Benamar, Tim
Leinmueller, 2016-04-19, <draft-petrescu-ipv6-over-80211p-04.txt>
In order to transmit IPv6 packets on IEEE 802.11 networks run outside
the context of a basic service set (OCB, earlier "802.11p") there is
a need to define a few parameters such as the recommended Maximum
Transmission Unit size, the header format preceding the IPv6 header,
the Type value within it, and others. This document describes these
parameters for IPv6 and IEEE 802.11 OCB networks; it portrays the
layering of IPv6 on 802.11 OCB similarly to other known 802.11 and
Ethernet layers - by using an Ethernet Adaptation Layer.
In addition, the document attempts to list what is different in
802.11 OCB (802.11p) compared to more 'traditional' 802.11a/b/g/n
layers, layers over which IPv6 protocols run ok. Most notably, the
operation outside the context of a BSS (OCB) has impact on IPv6
handover behaviour and on IPv6 security.
An example of an IPv6 packet captured while transmitted over an IEEE
802.11 OCB link (802.11p) is given.
"The Applicability of Reliable Server Pooling (RSerPool) for Virtual
Network Function Resource Pooling (VNFPOOL)", Thomas Dreibholz, Michael
Tuexen, Melinda Shore, Ning Zong, 2016-02-12,
<draft-dreibholz-vnfpool-rserpool-applic-03.txt>

This draft describes the application of Reliable Server

Pooling (RSerPool) for Virtual Network Function Resource
Pooling (VNFPOOL).
"Auditing of Congestion Exposure (ConEx) signals", David Wagner, Mirja
Khlewind, 2016-04-14, <draft-wagner-conex-audit-02.txt>
Congestion Exposure (ConEx) is a mechanism by which senders inform
the network about the congestion encountered by previous packets on
the same flow. Reliable auditing is necessary to provide a strong
incentive to declare ConEx information honestly. This document
defines how the signals are handled by an audit and lists
requirements for an audit implementation. This document does not
mandate a particular design but identifies state and functions that
any auditor element must provide to fulfill the requirements stated
in [draft-ietf-conex-abstract-mech].
"Extensions to PCEP for Distributing Label Cross Domains", Huaimo Chen,
Autumn Liu, Fengman Xu, Mehmet Toy, Vic Liu, 2016-03-18,
<draft-chen-pce-label-x-domains-04.txt>
This document specifies extensions to PCEP for distributing labels
crossing domains for an inter-domain Point-to-Point (P2P) or Pointto-Multipoint (P2MP) Traffic Engineering (TE) Label Switched Path
(LSP).
"Registry Fee Extension for the Extensible Provisioning Protocol (EPP)",
Gavin Brown, Jothan, 2016-04-08, <draft-brown-epp-fees-07.txt>
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for registry fees.
"Informational Add-on for HTTP over the Secure Sockets Layer (SSL)
Protocol and/or the Transport Layer Security (TLS) Protocol", Walter H.,
2013-11-25, <draft-hoehlhubmer-https-addon-07.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.
"Single SignON solution to WWW seen as one Giant computer", pradeep
xplorer, 2016-04-07, <draft-pkx-wwwogc-05.txt>
The document describes a SingleSignON solution to WWW seen as one Giant
computer. As WWW use increases, on average an user has many service
login
accounts they have to manage. It would be better for most users at
the
expense of some security risk to have one password for all the
services and
a WWW shell and a control panel. Also the WWW as an
intelligent being could
show information to an user interpreting their
needs from all their accounts.
"Information as a bird with wings that flies and hits the user device
screen as Icons", pradeep xplorer, 2016-01-16,

<draft-pkx-infobirdiconswww-06.txt>
The document proposes a WWW as an intelligent being that delivers
information
to users.
This can be combined with a Single SignON
solution for the WWW seen as one
Giant computer.
Imagine having a
handy device and you travel to Bangkok and in the morning when
you
authenticate
to WWW, your WWW navigation screen shows you very
useful Icons that can create a
better experience
for you.
"A Simpler Mechanism For Organizing FedFS NSDBs", Chuck Lever, Simo
Sorce, 2016-05-02, <draft-cel-nfsv4-federated-fs-nce-05.txt,.ps,.pdf>
This document describes a new, simpler mechanism for searching FedFS
NSDBs (Name Space Data Bases) for FedFS records. This mechanism
replaces the mechanism described in existing FedFS Proposed
Standards.
"Protocol independent multicast- Next Generation (PIM-NG): Protocol
Specifications", saeed sami, 2015-11-23, <draft-sami-pim-ng-08.txt,.pdf>
This document specifies protocol independent multicast- Next
generation or simply called PIM-NG. PIM-NG uses the underlying
unicast routing information, but unlike PIM-SM it doesn't necessarily
need to build unidirectional shared trees rooted at a Rendezvous
Point (RP) per group, due to the fact that the processes through
which a source registers with the Rendezvous Point and a host finds
the source of the multicast destination groups it needs are done in a
whole new way and hence, the source of multicast group (G) is
discovered faster. So at some points PIM-NG works faster than its
predecessor. Also the new Domain concept, unique to PIM-NG, along the
RPF check method used in PIM-NG specifications provides many features
along a robust and flexible control and administration over multicast
networks.
"Path Computation Element (PCE) Protocol Extensions for Stateful PCE
usage for Point-to-Multipoint Traffic Engineering Label Switched Paths",
Udayasree Palle, Dhruv Dhody, Yosuke Tanaka, Zafar Ali, Vishnu Pavan
Beeram, 2016-01-10, <draft-palle-pce-stateful-pce-p2mp-08.txt>
The Path Computation Element (PCE) has been identified as an
appropriate technology for the determination of the paths of pointto-multipoint (P2MP) TE LSPs. This document provides extensions
required for Path Computation Element communication Protocol (PCEP)
so as to enable the usage of a stateful PCE capability in supporting
P2MP TE LSPs.
"Generic Fault-avoidance Routing Protocol for Data Center Networks", Bin
Liu, Yantao Sun, Jing Cheng, Yichen Zhang, Bhumip Khasnabish,
2015-11-11, <draft-sl-rtgwg-far-dcn-05.txt>
This draft proposes a generic routing method and protocol for a
regular data center network, named as the fault-avoidance routing
(FAR) protocol. FAR protocol provides a generic routing method for
all types of network architectures that are proposed for large-scale
cloud-based data centers over the past few years. FAR protocol is
well designed to fully leverage the regularity in the topology and

compute its routing table in a simplistic manner. Fat-tree is taken

as an example architecture to illustrate how FAR protocol can be
applied in real operational scenarios.
"Asymmetric Extended Route Optimization (AERO)", Fred Templin,
2016-02-02, <draft-templin-aerolink-66.txt>
This document specifies the operation of IP over tunnel virtual links
using Asymmetric Extended Route Optimization (AERO). Nodes attached
to AERO links can exchange packets via trusted intermediate routers
that provide forwarding services to reach off-link destinations and
redirection services for route optimization. AERO provides an IPv6
link-local address format known as the AERO address that supports
operation of the IPv6 Neighbor Discovery (ND) protocol and links IPv6
ND to IP forwarding. Admission control, provisioning and mobility
are supported by the Dynamic Host Configuration Protocol for IPv6
(DHCPv6), and route optimization is naturally supported through
dynamic neighbor cache updates. Although DHCPv6 and IPv6 ND
messaging are used in the control plane, both IPv4 and IPv6 are
supported in the data plane. AERO is a widely-applicable tunneling
solution using standard control messaging exchanges as described in
this document.
"Yang Data Model for Service Function Chaining", Reinaldo Penno, Paul
Quinn, Danny Zhou, Johnson Li, 2016-01-03, <draft-penno-sfc-yang-14.txt>
This document defines a YANG data model that can be used to configure
and manage Service Function Chains.
"An IP option for describing the traffic flow", Robert Chodorek,
2015-12-10, <draft-chodorek-traffic-flow-option-04.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.
"CBOR data definition language (CDDL): a notational convention to
express CBOR data structures", Christoph Vigano, Henk Birkholz,
2016-03-21, <draft-greevenbosch-appsawg-cbor-cddl-08.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.
"Packet Optical Integration (POI) Use Cases for Abstraction and Control
of TE Networks (ACTN)", Dhruv Dhody, Xian Zhang, Oscar Gonzalez de Dios,
Daniele Ceccarelli, Bin-Yeong Yoon, 2016-04-14,
<draft-dhody-actn-poi-use-case-06.txt>
This document describes the Abstraction and Control of TE Networks
(ACTN) use cases related to Packet and Optical Integration (POI),
that may be potentially deployed in various TE networks and apply to
different applications.
"Barreto-Naehrig Curves", Akihiro Kato, Michael Scott, Tetsutaro
Kobayashi, Yuto Kawahara, 2016-03-24, <draft-kasamatsu-bncurves-02.txt>

Elliptic curves with pairings are useful tools for constructing

cryptographic primitives. In this memo, we specify domain parameters
of Barreto-Naehrig curves (BN-curves) [8]. The BN-curve is an
elliptic curve suitable for pairings and allows us to achieve high
security and efficiency of cryptographic schemes. This memo
specifies domain parameters of four 254-bit BN-curves [1] [2] [5]
which allow us to obtain efficient implementations.
"Experimental Option for TCP Host Identification", Brandon Williams,
Mohamed Boucadair, Dan Wing, 2015-11-05,
<draft-williams-exp-tcp-host-id-opt-07.txt>
Recent proposals discussed in the IETF have identified benefits to
more distinctly identifying the hosts that are hidden behind a shared
address/prefix sharing device or application-layer proxy. Analysis
indicates that the use of a TCP option for this purpose can be
successfully applied to some use cases. This document discusses
design, deployment, and privacy considerations for such a TCP option
that is in operational use on the Internet today.
"Federated Filesystem Security Addendum", Chuck Lever, 2016-05-02,
<draft-cel-nfsv4-federated-fs-security-addendum-05.txt,.ps,.pdf>
This document addresses critical security-related items that are
missing from existing FedFS Proposed Standards.
"Scalable-Group Tag eXchange Protocol (SXP)", Michael Smith, Rakesh
Kandula, 2016-02-10, <draft-smith-kandula-sxp-04.txt>
This document discusses scalable-group tag exchange protocol (SXP), a
control protocol to propagate IP address to Scalable Group Tag (SGT)
binding information across network devices.
"PCEP Extensions for PCE-initiated Point-to-Multipoint LSP Setup in a
Stateful PCE Model", Udayasree Palle, Dhruv Dhody, Yosuke Tanaka, Zafar
Ali, Vishnu Pavan Beeram, 2016-01-10,
<draft-palle-pce-stateful-pce-initiated-p2mp-lsp-07.txt>
The Path Computation Element (PCE) has been identified as an
appropriate technology for the determination of the paths of pointto-multipoint (P2MP) TE LSPs. This document provides extensions
required for Path Computation Element communication Protocol (PCEP)
so as to enable the usage of a stateful PCE initiation capability in
recommending P2MP TE LSP instantiation.
"PCEP Extensions for Receiving SRLG Information", Dhruv Dhody, Fatai
Zhang, Xian Zhang, Victor Lopezalvarez, Oscar Gonzalez de Dios,
2016-04-15, <draft-dhody-pce-recv-srlg-05.txt>
The Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering (TE) in networks
controlled by Multi-Protocol Label Switching (MPLS) and Generalized
MPLS (GMPLS).
This document provides extensions for the Path Computation Element
Protocol (PCEP) to receive Shared Risk Link Group (SRLG) information
during path computation via encoding this information in the path
computation reply message.

"Minimal ESP", Daniel Migault, Tobias Guggemos, Daniel Palomares,

2016-03-21, <draft-mglt-lwig-minimal-esp-02.txt>
This document describes a minimal version of the IP Encapsulation
Security Payload (ESP) described in RFC 4303 which is part of the
IPsec suite.
ESP is used to provide confidentiality, data origin authentication,
connectionless integrity, an anti-replay service (a form of partial
sequence integrity), and limited traffic flow confidentiality.
This document does not update or modify RFC 4303, but provides a
compact description of how to implement the minimal version of the
protocol. If this document and RFC 4303 conflicts then RFC 4303 is
the authoritative description.
"BGP Auto Discovery", Robert Raszuk, Warren Kumari, Jon Mitchell, Keyur
Patel, John Scudder, 2015-11-22,
<draft-raszuk-idr-bgp-auto-discovery-04.txt>
This document describes a method for automating portions of a
router's BGP configuration via discovery of BGP peers with which to
establish further sessions from an initial "bootstrap" router. This
method can apply for establishment of either Internal or External BGP
peering sessions.
"Connecting MPLS-SPRING Islands over IP Networks", Xiaohu Xu, Robert
Raszuk, Uma Chunduri, Luis Contreras, Luay Jalil, 2016-03-07,
<draft-xu-spring-islands-connection-over-ip-05.txt>
MPLS-SPRING is an MPLS-based source routing paradigm in which a
sender of a packet is allowed to partially or completely specify the
route the packet takes through the network by imposing stacked MPLS
labels to the packet. To facilitate the incremental deployment of
this new technology, this document describes a mechanism which allows
the outermost LSP be replaced by an IP-based tunnel.
"IGP extension for PCEP security capability support in the PCE
discovery", Diego Lopez, Qin Wu, Dhruv Dhody, Daniel King, Zitao Wang,
2016-02-02, <draft-wu-pce-discovery-pceps-support-05.txt>
When a Path Computation Element (PCE) is a Label Switching Router
(LSR) participating in the Interior Gateway Protocol (IGP), or even a
server participating in IGP, its presence and path computation
capabilities can be advertised using IGP flooding. The IGP
extensions for PCE discovery (RFC 5088 and RFC 5089) define a method
to advertise path computation capabilities using IGP flooding for
OSPF and IS-IS respectively. However these specifications lack a
method to advertise PCEP security (e.g., Transport Layer
Security(TLS),TCP Authentication Option (TCP-AO)) support capability.
This document proposes new capability flag bits for PCE-CAP-FLAGS
sub- TLV that can be announced as attribute in the IGP advertisement
to distribute PCEP security support information.
"PCEP Extensions for Service Function Chaining (SFC)", Qin Wu, Dhruv
Dhody, Mohamed Boucadair, Christian Jacquenet, Jeff Tantsura,
2016-03-07, <draft-wu-pce-traffic-steering-sfc-08.txt>
This document provides an overview of the usage of Path Computation

Element (PCE) to dynamically structure service function chains.

Service Function Chaining (SFC) is a technique that is meant to
facilitate the dynamic enforcement of differentiated traffic
forwarding policies within a domain. Service function chains are
composed of an ordered set of elementary Service Functions (such as
firewalls, load balancers) that need to be invoked according to the
design of a given service. Corresponding traffic is thus forwarded
along a Service Function Path (SFP) that can be computed by means of
PCE.
This document specifies extensions to the Path Computation Element
Protocol (PCEP) that allow a stateful PCE to compute and instantiate
Service Function Paths.
"NVO3 Fault Management", Tissa Senevirathne, Samer Salam, Deepak Kumar,
Norman Finn, Donald Eastlake, Sam Aldrin, 2016-04-06,
<draft-tissa-nvo3-oam-fm-03.txt>
This document specifies Fault Management solution for network
virtualization overlay networks. Methods in this document follow the
IEEE 802.1 CFM framework and reuse OAM tools where possible.
Additional messages and TLVs are defined for IETF overlay OAM
specific applications or where extensions beyond IEEE 802.1 CFM are
required.
"PCEP Procedures and Protocol Extensions for Using PCE as a Central
Controller (PCECC) of LSPs", Quintin Zhao, Zhenbin Li, Dhruv Dhody, Chao
Zhou, 2016-03-16,
<draft-zhao-pce-pcep-extension-for-pce-controller-03.txt>
In certain networks deployment scenarios, service providers would
like to keep all the existing MPLS functionalities in both MPLS and
GMPLS while removing the complexity of existing signalling protocols
such as LDP and RSVP-TE. In
[I-D.zhao-pce-central-controller-user-cases], we propose to use the
PCE [RFC5440] as a central controller (PCECC) so that LSP can be
calculated/ signalled/initiated and label forwarding entries are
downloaded through a centralized PCE server to each network devices
along the LSP path while leveraging the existing PCE technologies as
much as possible.
This draft specify the procedures and PCEP protocol extensions for
using the PCE as the central controller and user cases where LSPs are
calculated/setup/initiated and label forwarding entries are
downloaded through extending the existing PCE architectures and PCEP.
This document also discuss the role of PCECC in Segment Routing (SR).
"Requirements for IPv6 Enterprise Firewalls", Fernando Gont, Marco
Ermini, Shucheng LIU, 2016-03-21,
<draft-gont-opsec-ipv6-firewall-reqs-03.txt>
While there has been some work in the area of firewalls, concrete
requirements for IPv6 firewalls have never been specified in the RFC
series. The more limited experience with the IPv6 protocols and the
more reduced number of firewalls that support IPv6 has made it rather
difficult to infer what are reasonable features to expect in an IPv6
firewall. This has typically been a problem for network operators,
who typically have to produce a "Request for Proposal" from scratch
that describes such features. This document specifies a set of

requirements for IPv6 firewalls, in order to establish some commonground in terms of what features can be expected in them.
"Solution for Site Multihoming in a Real IP Environment", Shyam
Bandyopadhyay, 2016-04-12, <draft-shyam-site-multi-23.txt>
This document provides a solution for Site Multihoming of stub
networks in a real IP environment. Each user interface in a customer
network may have as many global unicast addresses as many service
providers it will be connected with. Users can establish multiple
connections through different service providers simultaneously.
Customer networks can maintain private address space to communicate
within its users. Customer networks can provide IP mobility services
as well.
"A TCP Authentication Option Extension for Payload Encryption", Joseph
Touch, 2016-04-18, <draft-touch-tcp-ao-encrypt-05.txt>
This document describes an extension to the TCP Authentication
Option (TCP-AO) to encrypt the TCP segment payload in addition to
providing TCP-AO's authentication of the payload, TCP header, and IP
pseudoheader. This extension augments how the packet contents and
headers are processed and which keys are derived, and adds a
capability for in-band coordination of unauthenticated DiffieHellman key exchange at connection establishment. The extension
preserves key rollover coordination and protection of long-lived
connections.
"Compression of IPsec AH and ESP Headers for 6LoWPAN Networks", Shahid
Raza, Simon Duquennoy, Goran Selander, 2016-03-18,
<draft-raza-6lo-ipsec-04.txt,.ps,.pdf>
This document describes the header compression mechanisms for IPsec
[RFC4301] based on the encoding scheme standardized in [RFC6282]. The
IPsec Authentication Header (AH) and Encapsulated Security Payload
(ESP) headers are compressed using Next Header Compression (NHC)
defined in [RFC6282]. This document does not invalidate any encoding
schemes proposed in 6LoWPAN [RFC6282] but rather complements it with
compressed IPsec AH and ESP headers using the free bits in the IPv6
Extension Header encoding. Also, this document does not require any
changes in a conventional IPsec host on the Internet; the header
compression is applied only at the 6LoWPAN layer and is effective
within 6LoWPAN networks.
"PCE support for Maximizing Diversity", Dhruv Dhody, Qin Wu, 2016-04-14,
<draft-dhody-pce-of-diverse-05.txt>
The computation of one or a set of Traffic Engineering Label Switched
Paths (TE LSPs) in MultiProtocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks is subject to a set of one or more
specific optimization criteria, referred to as objective functions.
In the Path Computation Element (PCE) architecture, a Path
Computation Client (PCC) may want a set of services that are required
to be diverse (disjointed) from each other. In case when full
diversity could not be achieved, it is helpful to maximize diversity
as much as possible (or in other words, minimize the common shared
resources).
This document defines objective function code types for three new

objective functions for this purpose to be applied to a set of

synchronized path computation requests.
"OpFlex Control Protocol", Michael Smith, Robert Adams, Mike Dvorkin,
Youcef Laribi, Vijoy Pandey, Pankaj Garg, Nik Weidenbacher, 2016-04-25,
<draft-smith-opflex-03.txt>
The OpFlex architecture provides a distributed control system based
on a declarative policy information model. The policies are defined
at a logically centralized policy repository (PR) and enforced within
a set of distributed policy elements (PE). The PR communicates with
the subordinate PEs using the OpFlex Control protocol. This protocol
allows for bidirectional communication of policy, events, statistics,
and faults. This document defines the OpFlex Control Protocol.
"Passive DNS - Common Output Format", Alexandre Dulaunoy, Aaron Kaplan,
Paul Vixie, Henry Stern, 2015-11-13,
<draft-dulaunoy-dnsop-passive-dns-cof-01.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.
"Further Mitigating Router ND Cache Exhaustion DoS Attacks Using
Solicited-Node Group Membership", Mark Smith, 2016-02-27,
<draft-smith-v6ops-mitigate-rtr-dos-mld-slctd-node-02.txt>
For each of their IPv6 unicast or anycast addresses, nodes join a
Solicited-Node multicast group, formed using the lower 24 bits of the
address. This Solicited-Node group membership could be used by
routers to further mitigate a Neighbor Discovery cache Denial of
Service attack.
"Uniform information with a hybrid naming (hn) scheme", Hong-Ke Zhang,
Fei Song, Wei Quan, Jianfeng Guan, Changqiao Xu, 2016-04-06,
<draft-zhang-icnrg-hn-04.txt>
This document defines a hybrid naming scheme for unifying all kinds
of information including resources, services and data. With many
proposals of novel network architectures emerging, such as DONA, ICN,
NDN, the location-based routing starts to transfer to the content-based
ones. Currently, it is incompatible that many different information
naming schemes are adopted in different network proposals,
respectively, i.e. flat names in DONA, hierarchical names in NDN. The
proposed naming scheme adopts a hybrid naming structure, which includes
hierarchical component, flat component and attribute component. The
hybrid naming (hn) scheme enables to identify different routing
information uniformly, and provides many great advantages, such as
high aggregation, limited length, suffix holes remission, fuzzy
matching support, high security and good compatibility with IPv4/IPv6,
DONA, CCN/NDN and so on.
"Security Mechanism Names for Media", Peter Dawes, 2016-05-03,
<draft-dawes-sipcore-mediasec-parameter-04.txt>
Negotiating the security mechanisms used between a Session Initiation
Protocol (SIP) user agent and its next-hop SIP entity is described in

RFC 3329 [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.
"EAP-based Authentication Service for CoAP", Raul Sanchez, Rafael Lopez,
Dan Garcia, 2016-04-20, <draft-marin-ace-wg-coap-eap-03.txt>
This document describes an authentication service that uses EAP
transported by means of CoAP messages with two purposes:
o Authenticate two CoAP endpoints.
o Bootstrap key material to protect CoAP messages exchanged between
them.
"SFC Header Mapping for Legacy SF", Haibin Song, Jianjie You, Lucy Yong,
Yuanlong Jiang, Linda Dunbar, Nicolas Bouthors, David Dolson,
2016-04-05, <draft-song-sfc-legacy-sf-mapping-07.txt>
A Service Function Chain (SFC) defines a set of abstract Service
Functions (SF) and ordering constraints that must be applied to
packets and/or frames selected as a result of classification. One
assumption of this document is that legacy service functions can
participate in service function chains without having support for the
SFC header, or even being aware of it. This document provides a
mechanism between an SFC proxy and an SFC-unaware service function
(herein termed "legacy SF"), to identify the SFC header associated
with a packet that is returned from a legacy SF, without an SFC
header being explicitly carried in the wired protocol between SFC
proxy and legacy SF.
"WebRTC Dependencies", Cullen Jennings, 2016-03-20,
<draft-jennings-rtcweb-deps-10.txt>
This draft will never be published as an RFC and is meant purely to
help track the IETF dependencies from the W3C WebRTC documents.
"Encoding claims in the OAuth 2 state parameter using a JWT", J.
Bradley, Torsten Lodderstedt, Hans Zandbelt, 2015-12-14,
<draft-bradley-oauth-jwt-encoded-state-05.txt>
This draft provides a method for a client to encode one or more
elements encoding information about the session into the OAuth 2
"state" parameter.
"Hypertext Transfer Protocol: Improved HTTP Caching", Chris Drechsler,
2015-11-15, <draft-drechsler-httpbis-improved-caching-04.txt>
This document describes an improved HTTP caching method which can be
applied in addition to the standard caching behavior for HTTP. It
defines the associated header field that controls this improved
caching mechanism and a modified caching operation which is slightly
different to standard caching operation for HTTP.
"Inter-Cloud Computing Architecture", Mohammad Aazam, 2015-11-13,
<draft-aazam-cdni-inter-cloud-architecture-03.txt>
With the rapid rise in digital content, cloud computing has become
the focus of academia and industry. Cloud computing comes with

sophisticated technologies for data storage, management, and

distribution. Ubiquitous access facility and pay-as-you-go billing
features are additional advantages associated with this paradigm.
However, the massive digital content, more importantly multimedia,
has to be managed in a more effective way. Heterogeneous cloud
customers, accessing different customized services, with more advanced
access networks and devices available today, makes it tough at times
for solitary clouds to fulfill the needs. In such cases, different
clouds have to interoperate and federate their resources. This
scenario is called inter-cloud computing of cloud federation. Since
the concept of inter-cloud computing is still very new, it lacks
standard architecture. This document focuses on presenting architectural
fundamentals and key concerns associated with inter-cloud computing.
"The Session Initiation Protocol (SIP) OAuth", Rifaat Shekh-Yusef,
Victor Pascual, Christer Holmberg, 2016-03-08,
<draft-yusef-sipcore-sip-oauth-03.txt>
This document defines an authorization framework for SIP that is
based on the OAuth 2.0 framework, and adds a simple identity layer on
top of that, based on the OpenID Connect Core 1.0, to enable Clients
to verify the identity of the End-User based on the authentication
performed by an Authorization Server, as well as to obtain basic
profile information about the End-User.
"Integration of Dynamic Automated Metadata Exchange into the SAML 2.0
Web Browser SSO Profile", Daniela Poehn, Stefan Metzger, Wolfgang
Hommel, Michael Grabatin, 2015-12-07, <draft-poehn-dame-04.txt>
This document specifies the integration of Dynamic Automated Metadata
Exchange (DAME) through an intermediate trusted third party into the
Security Assertion Markup Language (SAML) 2.0 Web Browser SSO
Profile. The user-triggered, on-demand, and fully automated metadata
exchange between identity provider (IDP) and service provider (SP) is
intended for scenarios in which the a-priori, e.g., federation-based
exchange of SAML metadata is neither practical, scalable nor
mandatory for non-technical aspects, such as contract-based trust
building between IDP and SP. The main benefit of DAME is the removal
of waiting times for users and manual setup tasks for IDP and SP
administrators before users can access the service. Implementations
of DAME can leverage existing metadata repositories, such as REEP,
and metadata transfer protocols, such as MD Query.
"Requirements for an update to 6LoWPAN ND", Pascal Thubert, Peter Van
der Stok, 2016-04-04, <draft-thubert-6lo-rfc6775-update-reqs-07.txt>
Work presented at the ROLL, 6lo, 6TiSCH and 6MAN Working Groups
suggest that enhancements to the 6LoWPAN ND mechanism are now needed.
This document elaborates on those requirements and suggests
approaches to serve them.
"HTTP/2 Gzipped Data", Matthew Kerwin, 2016-04-11,
<draft-kerwin-http2-encoded-data-08.txt>
This document introduces a new frame type for transporting gzipencoded data between peers in the Hypertext Transfer Protocol Version
2 (HTTP/2), and an associated error code for handling invalid
encoding.
*Note to Readers*

The issues list for this draft can be found at

https://github.com/phluid61/internet-drafts/labels/
HTTP%2F2%20Gzipped%20Data
The most recent (often unpublished) draft is at
http://phluid61.github.io/internet-drafts/http2-encoded-data/
"PCEP Extensions for Establishing Relationships Between Sets of LSPs",
Ina Minei, Edward Crabbe, Siva Sivabalan, Hariharan Ananthakrishnan,
Xian Zhang, Yosuke Tanaka, 2015-11-09,
<draft-minei-pce-association-group-04.txt>
This document introduces a generic mechanism to create a grouping of
LSPs in the context of a PCE. This grouping can then be used to
define associations between sets of LSPs or between a set of LSPs and
a set of attributes (such as configuration parameters or behaviors),
and is equally applicable to the active and passive modes of a
stateful PCE as well as a stateless PCE.
"SDP codepoints for gateway control", Albrecht Schwarz, Christian
Groves, 2016-05-02, <draft-schwarz-mmusic-sdp-for-gw-05.txt>
SDP is used in many signalling protocols at call control level (such
as SAP, SIP, BICC), bearer control level (such as RTSP, IPBCP) and
gateway control level (such as H.248/MEGACO, MGCP). Scope of this
RFC is related to gateway control specific SDP usage. Gateway
control protocols do NOT usually define and introduce any new SDP
parameters, however, gateway control protocols need specific SDP
parameter values in addition to those defined at call or bearer
control level. Such SDP codepoints are collected by this RFC with
the purpose of registration with IANA.
"Need for an httpi intelligent service", pradeep xplorer, 2016-01-16,
<draft-httpi-11.txt>
This document describes the need for an httpi protocol similar to
https used for intelligent surfing of information.
"PCEP Extensions for MPSL-TE LSP Path Protection with stateful PCE",
Hariharan Ananthakrishnan, Siva Sivabalan, Colby Barth, Raveendra Torvi,
Ina Minei, Edward Crabbe, 2016-03-10,
<draft-ananthakrishnan-pce-stateful-path-protection-01.txt>
A stateful Path Computation Element (PCE) is capable of computing as
well as controlling via Path Computation Element Protocol (PCEP)
Multiprotocol Label Switching Traffic Engineering Label Switched
Paths (MPLS LSP). Furthermore, it is also possible for a stateful
PCE to create, maintain, and delete LSPs. This document describes
PCEP extension to associate two or more LSPs to provide end-to-end
path protection.
"BFD Stability", Ashesh Mishra, Mahesh Jethanandani, Ankur Saxena,
Juniper Networks, Mach Chen, Peng Fan, 2016-03-04,
<draft-ashesh-bfd-stability-04.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 as well as
local delay measurements for BFD transmitter and receiver.

"BGP Extensions for Path Computation Element (PCE) Discovery", Jie Dong,
Mach Chen, Dhruv Dhody, Jeff Tantsura, 2016-03-09,
<draft-dong-pce-discovery-proto-bgp-04.txt>
In networks where Path Computation Element (PCE) is used for
centralized path computation, it is desirable for the Path
Computation Clients (PCCs) to automatically discover a set of PCEs
and select the suitable ones to establish the PCEP session. RFC 5088
and RFC 5089 define the PCE discovery mechanisms based on Interior
Gateway Protocols (IGP). This document describes several scenarios
in which the IGP based PCE discovery mechanisms cannot be used
directly. In such scenarios, BGP might be suitable, thus this
document specifies the BGP extensions for PCE discovery. The BGP
based PCE discovery mechanism is complementary to the existing IGP
based mechanisms.
"Usage of the Peer-to-Peer Streaming Protocol (PPSP)", Hong-Ke Zhang,
Fei Song, Di Wu, Mi Zhang, Tianming Zhao, 2016-03-04,
<draft-zhang-ppsp-usage-04.txt>
This document focuses on several crucial operation issues of Peer-toPeer Streaming Protocol (PPSP) usage, considering two basic modes:
Leech mode and Seed mode. The settings of related parameters for
default PPSP scenario reference to tracker protocol and peer protocol
respectively. In addition, the limitations and gaps of current PPSP
system are identified at with the standpoint of satisfying PPSP
requirements.
"A JSON Encoding for HTTP Header Field Values", Julian Reschke,
2016-03-15, <draft-reschke-http-jfv-03.txt>
This document establishes a convention for use of JSON-encoded field
values in HTTP header fields.
"Including Geolocation Information in IPv6 Packet Headers (IPv6 GEO)",
Brian Skeen, Edwin King, Fred Templin, 2016-05-02,
<draft-skeen-6man-ipv6geo-02.txt>
This document provides a specification for including geolocation
information in the headers of IPv6 packets (IPv6 GEO). The
information is intended to be included in packets for which the
location of the source node is to be conveyed via the network to the
destination node or nodes.
"MIF API extension for combining IEEE 802.21", Hong-Ke Zhang, Boxin Du,
Mi Zhang, Fei Song, 2015-11-29,
<draft-zhang-mif-api-extension-802-21-03.txt>
The Application Program Interface (API) of MIF, specified in the MIF
API consideration, must rely on lower layer functionalities when
handover between homogeneous or heterogeneous networks is necessary.
To improve the connectivity performance,the existing MIF API needs to
be extended. IEEE is also aimed at the similar issue from different
way. A kind of logical entities over the link layer protocol for
handling the seamless handover has been defined in IEEE 802.21. This
document proposes a mechanism via conbining the MIF API and IEEE
802.21 to support application service better.
"IP Flow Performance Measurement Report", Mach Chen, Lianshu Zheng, Greg

Mirsky, 2016-04-19, <draft-chen-ippm-ipfpm-report-01.txt>

A "marking" based IP Flow Performance Measurement (IPFPM) framework
is specified in draft-chen-ippm-coloring-based-ipfpm-framework. IP
Flow Information eXport (IPFIX) is used for exporting the performance
of IPFPM. Several new Information Elements of IPFIX are defined for
IPFPM in this document.
"Auto-attach using LLDP with IEEE 802.1aq SPBM networks", Paul
Unbehagen, Dan Romascanu, John Seligson, Carl Keene, Nigel Bragg,
Ludovic Beliveau, 2016-01-28, <draft-unbehagen-lldp-spb-02.txt>
This informational document describes a method that allows for the
automatic attachment of end stations and network devices to a core
network based on the individual services that are run or configured
on the stations or devices, and the mapping of the services to the
managed paths in the network.
Specifically the document describes a compact method based on the
IEEE802.1AB Link Layer Discovery Protocol (LLDP) to automatically
attach network devices not supporting IEEE 802.1ah to individual
services in an IEEE 802.1aq Shortest Path Bridging (SPB) network.
"Distributed Mobility Management Protocol for WiFi Users in Fixed
Network", Behcet Sarikaya, Li Xue, 2016-03-15,
<draft-sarikaya-dmm-for-wifi-04.txt>
As networks are moving towards flat architectures, a distributed
approach is needed to mobility management. This document defines a
distributed mobility management protocol called Distributed Mobility
Management for Wi-Fi protocol. The protocol is based on mobility
aware virtualized routing system with software-defined network
support. Routing is in Layer 2 in the access network and in Layer 3
in the core network. Smart phones access the network over IEEE
802.11 (Wi-Fi) interface and can move in home, hotspot and enterprise
buildings.
"NEMO (NEtwork MOdeling) Language", Yinben Xia, Sheng Jiang, Tianran
Zhou, Susan Hares, Yali Zhang, 2016-04-14,
<draft-xia-sdnrg-nemo-language-04.txt>
The North-Bound Interface (NBI), located between the control plane
and the applications, is essential to enable the application
innovations and nourish the eco-system of SDN.
While most of the NBIs are provided in the form of API, this document
proposes the NEtwork MOdeling (NEMO) language which is intent based
interface with novel language fashion. Concept, model and syntax are
introduced in the document.
"LISP-OAM (Operations, Administration and Management): Use cases and
requirements", Alberto Rodriguez-Natal, Albert Cabellos-Aparicio, Marc
Portoles-Comeras, Michael Kowal, Darrel Lewis, Fabio Maino, 2015-12-06,
<draft-rodrigueznatal-lisp-oam-03.txt>
This document describes Operations Administration and Management
(OAM) use-cases and the requirements that they have towards the LISP
architecture.
"Diversity Routing for the Babel Routing Protocol", Juliusz Chroboczek,

2016-02-15, <draft-chroboczek-babel-diversity-routing-01.txt>
This document defines an extension to the Babel routing protocol that
allows routing updates to carry radio frequency information, and
therefore makes it possible to use radio diversity information for
route selection.
"Internet Measurement System", m.ooki@ntt.com, Satoshi Kamei,
2015-12-21, <draft-ooki-lmap-internet-measurement-system-03.txt>
This document describes an experience of Japanese Internet
measurement system to measure end-to-end performance of user's
experience. We have developed the system toward the enhancement of
the network performance in an ISP since October 2013. The systems
and the considerations about the Internet measurement are introduced
along with our current status. This document is expected to be
useful for the standardization of Internet measurements.
"6tisch secure join using 6top", Michael Richardson, 2015-11-20,
<draft-richardson-6tisch--security-6top-05.txt>
This document details a security architecture that permits a new
6tisch compliant node to join an 802.15.4e network. The process
bootstraps the new node authenticating the node to the network, and
the network to the node, and configuring the new node with the
required 6tisch schedule. Any resemblance to WirelessHART/IEC62591
is entirely intentional.
"Ideas for a Next Generation of the Stream Control Transmission Protocol
(SCTP)", Thomas Dreibholz, 2016-01-08,
<draft-dreibholz-tsvwg-sctp-nextgen-ideas-03.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.
"Congestion Control Using FEC for Conversational Media", Varun, Marcin
Nagy, Joerg Ott, Lars Eggert, 2016-03-20,
<draft-singh-rmcat-adaptive-fec-03.txt,.pdf>
This document describes a new mechanism for conversational multimedia
flows. The proposed mechanism uses Forward Error Correction (FEC)
encoded RTP packets (redundant packets) along side the media packets
to probe for available network capacity. A straightforward
interpretation is, the sending endpoint increases the transmission
rate by keeping the media rate constant but increases the amount of
FEC. If no losses and discards occur, the endpoint can then increase
the media rate. If losses occur, the redundant FEC packets help in
recovering the lost packets. Consequently, the endpoint can vary the
FEC bit rate to conservatively (by a small amount) or aggressively
(by a large amount) probe for available network capacity.
"Use cases for remote-initiated LSPs via Path Computation Element
Communication Protocol (PCEP)", Victor Lopez, Oscar Gonzalez de Dios,
Zafar Ali, zhenghaomian@huawei.com, 2016-03-21,
<draft-lopez-pce-use-cases-initiated-pce-01.txt,.pdf>
Thanks to the extensions defined in [I-D. draft-ietf-pce-pceinitiated-lsp] and [I-D.draft-ietf-pce-remote-initiated-gmpls-lsp],

it is possible to initiate LSP Setup in a Stateful PCE Model for

MPLS and GMPLS scenarios. This document complements previous
documents by providing an explanation of the use cases to use such
PCEP extensions.
This document presents single layer and multi-layer use cases,
where not only the PCE is involved, but also other modules defined
in IETF, such as Virtual Network Topology Manager and Provisioning
Manager.
"Delay-based Congestion Control for MPTCP", Mingwei Xu, Yu Cao, Enhuan
Dong, 2016-01-03, <draft-xu-mptcp-congestion-control-03.txt>
This document describes the mechanism of wVegas (weighted Vegas),
which is a delay-based congestion control for MPTCP. The current
congestion control algorithm of MPTCP, LIA, achieves only coursegrained load balancing, since it is based on packet loss event. On
the contrary, wVegas adopts packet queuing delay as congestion
signals, thus achieving fine-grained load balancing. Compared with
loss-based algorithms, wVegas is more sensitive to the changes of
network congestion and thus achieves more timely traffic shifting and
quicker convergence. WVegas has been implemented in the Linux Kernel
and is part of the UCLouvain's MPTCP implementation now.
"TCP SYN Extended Option Space Using an Out-of-Band Segment", Joseph
Touch, Ted Faber, 2016-04-18, <draft-touch-tcpm-tcp-syn-ext-opt-04.txt>
This document describes an experimental method to extend the option
space for connection parameters within the initial TCP SYN segment,
at the start of a TCP connection. This method effectively extends
the option space of an initial SYN by using an additional coupled
segment that is sent 'out-of-band'. It complements the proposed
Extended Data Offset (EDO) option that is applicable only after the
initial segment.
"Balanced Linked Adaptation Congestion Control Algorithm for MPTCP",
Anwar Walid, Qiuyu Peng, Jaehyun Hwang, Steven Low, 2016-01-25,
<draft-walid-mptcp-congestion-control-04.txt,.pdf>
This document describes the mechanism of Balia, the "Balanced linked
adaptation", which is a congestion control algorithm for Multipath
TCP (MPTCP). The recent proposals, LIA and OLIA, suffer from either
unfriendliness to Single Path TCP (SPTCP) or unresponsiveness to
network changes under certain conditions. The tradeoff between
friendliness and responsiveness is inevitable, but Balia judiciously
balances this tradeoff based on a new design framework that allows
one to systematically explore the design space. Balia has been
implemented in the Linux kernel and also included in the UCLouvain's
MPTCP implementation.
"Path Computation Element communication Protocol extension for
relationship between LSPs and Attributes or Policies", Dhruv Dhody,
Wenson Wu, 2016-04-19, <draft-dhody-pce-association-attr-04.txt>
The Path Computation Element (PCE) provides functions of path
computation in support of traffic engineering in networks controlled
by Multi-Protocol Label Switching (MPLS) and Generalized MPLS
(GMPLS).
This document defines a mechanism to create associations between a

set of LSPs and a set of attributes (such as configuration

parameters) or policies.
"The application/pdf Media Type", Matthew Hardy, Larry Masinter, Dejan
Markovic, Duff Johnson, Martin Bailey, 2016-04-07,
<draft-hardy-pdf-mime-01.txt,.pdf>
<1>
The Portable Document Format (PDF) is an ISO standard (ISO
32000-1:2008) defining a final-form document representation language
in use for document exchange, including on the Internet, since 1993.
This document provides an overview of the PDF format and updates the
media type registration of "application/pdf".
"BGP Path Record Attribute", Robert Raszuk, Russ White, Jie Dong,
2015-11-22, <draft-raszuk-idr-bgp-pr-04.txt>
The BGP protocol contains number of built in mechanisms which records
information about the routers which have processed a specific piece
of reachability information critical to insuring only loop free paths
are chosen by the protocol. For instance, the AS_PATH, CLUSTER_LIST
and ORIGINATOR_ID attributes carry information designed to insure
permanent routing loops are not formed in the path chosen towards a
particular destination. However, there are no provisions to record
other useful information along the path, metadata about the routers
through which reachability information has passed which can be
helpful to the operator in order to enhance end to end visibility of
the BGP control plane.
In order to solve this problem this document proposes a new single
BGP attribute designed as an generic and extensible container to
carry number of new optional information corresponding to the BGP
speakers given BGP advertisement (or withdraw) message traverses.
"Advertising Tunnelling Capability in IS-IS", Xiaohu Xu, Bruno Decraene,
Robert Raszuk, Uma Chunduri, Luis Contreras, Luay Jalil, 2015-11-10,
<draft-xu-isis-encapsulation-cap-06.txt>
Some networks use tunnels for a variety of reasons. A large variety
of tunnel types are defined and the ingress needs to select a type of
tunnel which is supported by the egress. This document defines how
to advertise egress tunnel capabilities in IS-IS Router Capability
TLV.
"Network Service Header (NSH) Context Header Allocation (Data Center)",
Jim Guichard, Michael Smith, Surendra, Sumandra Majee, Puneet Agarwal,
Kevin, Youcef Laribi, 2016-02-16,
<draft-guichard-sfc-nsh-dc-allocation-04.txt>
This document provides a recommended default allocation for the fixed
context headers within a Network Service Header (NSH). NSH is
defined in [I-D.ietf-sfc-nsh]. The allocation scheme is relevant
when NSH is used for Service Function Chaining within a data center
and may be used to support use cases such as those described in
[I-D.ietf-sfc-dc-use-cases].
"EdDSA for OpenPGP", Werner Koch, 2016-02-28,
<draft-koch-eddsa-for-openpgp-04.txt>
This specification extends OpenPGP with the EdDSA public key

algorithm and describes the use of curve Ed25519.

"Service Function Path Establishment", Julong Lan, Yuxiang Hu, Guozhen
Cheng, Peng Wang, Le Tian, 2016-04-19,
<draft-lan-sfp-establishment-01.txt>
Service Function Chain architecture leads to more adaptive network
nodes. It allows splitting the network function into fine-grained
build blocks --- service function, and combining the network
functions into service function chain to formulate complicated
services. Further, the service function chain should be instantiated
by selecting the optimal instance from the candidates for each
service function in it. This document discusses the required
components during the instantiation of service function chain in the
network.
"Representing DNS Messages in JSON", Paul Hoffman, 2016-03-07,
<draft-hoffman-dns-in-json-06.txt>
Some applications use DNS messages, or parts of DNS messages, as
data. For example, a system that captures DNS queries and responses
might want to be able to easily search those without having to decode
the messages each time. Another example is a system that puts
together DNS queries and responses from message parts. This document
describes a standardized format for DNS message data in JSON.
"BGP Link-State Extensions for Seamless BFD", Shunwan Zhuang, Zhenbin
Li, Jeff Tantsura, Greg Mirsky, 2015-12-25,
<draft-zhuang-idr-bgp-ls-sbfd-extensions-01.txt>
[I-D.ietf-bfd-seamless-base] defines a simplified mechanism to use
Bidirectional Forwarding Detection (BFD) with large portions of
negotiation aspects eliminated, thus providing benefits such as quick
provisioning as well as improved control and flexibility to network
nodes initiating the path monitoring. The link-state routing
protocols (IS-IS, OSPF and OSPFv3) have been extended to advertise
the Seamless BFD (S-BFD) Discriminators.
This draft defines extensions to the BGP Link-state address-family to
carry the S-BFD Discriminators information via BGP.
"Remote checksum offload for encapsulation", Tom Herbert, 2016-03-01,
<draft-herbert-remotecsumoffload-02.txt>
This document describes remote checksum offload for encapsulation,
which is a mechanism that provides checksum offload of encapsulated
packets using rudimentary offload capabilities found in most Network
Interface Card (NIC) devices. The outer header checksum e.g. that in
UDP or GRE) is enabled in packets and, with some additional meta
information, a receiver is able to deduce the checksum to be set for
an inner encapsulated packet. Effectively this offloads the
computation of the inner checksum. Enabling the outer checksum in
encapsulation has the additional advantage that it covers more of the
packet than the inner checksum including the encapsulation headers.
"Defeating Attacks which employ Forged ICMP/ICMPv6 Error Messages",
Fernando Gont, Ray Hunter, Jeroen, Shucheng LIU, 2016-03-21,
<draft-gont-opsec-icmp-ingress-filtering-02.txt>
Over the years, a number of attack vectors that employ forged ICMP/

ICMPv6 error messages have been disclosed and exploited in the wild.
The aforementioned attack vectors do not require that the source
address of the packets be forged, but do require that the addresses
of the IP/IPv6 packet embedded in the ICMP/ICMPv6 payload be forged.
This document discusses a simple, effective, and straightforward
method for using ingress traffic filtering to mitigate attacks that
use forged addresses in the IP/IPv6 packet embedded in an ICMP/ICMPv6
payload.
"Extensions to OSPF for Advertising Prefix/Link Administrative Tags",
Acee Lindem, Peter Psenak, 2016-03-15,
<draft-acee-ospf-admin-tags-04.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-SoStubby-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.
"Source Address Dependent Routing and Source Address Selection for IPv6
Hosts: Problem Space Overview", Behcet Sarikaya, Mohamed Boucadair,
2016-01-04, <draft-sarikaya-6man-sadr-overview-09.txt>
This document presents the source address dependent routing (SADR)
problem space from the host perspective. Both multihomed hosts and
hosts with multiple interfaces are considered. Several network
architectures are presented to illustrate why source address
selection and next hop resolution in view of source address dependent
routing is needed.
"YANG Data Model for MPLS-TP Operations, Administration, and Maintenance
(OAM)", Li Zhang, Lianshu Zheng, Sam Aldrin, Greg Mirsky, 2016-02-23,
<draft-zhang-mpls-tp-yang-oam-02.txt>
The Transport Profile of Multiprotocol Label Switching (MPLS-TP)
[RFC5921]is a packet-based transport technology based on the MPLS
Traffic Engineering (MPLS-TE) and pseudowire (PW) data-plane
architectures. A comprehensive set of Operations, Administration,
and Maintenance (OAM) procedures that fulfill the MPLS-TP OAM
requirements for fault, performance, and protection-switching
management had been defined. YANG [RFC6020]is a data definition
language that was introduced to define the contents of a conceptual
data store that allows networked devices to be managed using NETCONF
[RFC6241]. This document presents the YANG Data model for MPLS-TP
OAM, including the basic functions of Fault Management and
Performance Monitoring.
"Advertising LSPs with Segment Routing", Chris Bowers, Hannes Gredler,
Uma Chunduri, 2015-11-18,
<draft-bowers-spring-advertising-lsps-with-sr-02.txt>
Segment routing uses globally-known labels to accomplish forwarding

along shortest paths, and label stacks to accomplish explicit routing

along arbitrary paths. These labels are advertised using an IGP.
This draft describes how label bindings corresponding to RSVP, LDP,
BGP labeled-unicast, and static LSPs are advertised in segment
routing and how these labels can be combined with other segment
routing labels to create forwarding paths. This draft also describes
how context labels for egress node protection are advertised in using
segment routing IGP extensions.
"IPv4/IPv6 Transition Practice in OpenStack", Yi Bai, Congxiao Bao,
Kevin Yin, Xing Li, 2016-03-21,
<draft-ybai-v6ops-ipv6-for-openstack-03.txt>
OpenStack is a free and open-source software cloud computing
platform. It is primarily deployed as an infrastructure as a service
(IaaS) solution. However, OpenStack is designed mainly for IPv4, it
internally uses [RFC1918] addresses and heavily relies on NAT to map
RFC1918 addresses to public IPv4 addresses known as floating IP
addresses for the external access. Due to the different nature of
IPv6 and IPv4, the IPv6 support for the OpenStack is still in the
early stage. In this document, two mechanisms are presented to
provide IPv4/IPv6 dual stack external access for the OpenStack, one
scenario is internal IPv4 and uses stateful IPv4/IPv6 translator for
the external IPv6 access, and another scenario is internal IPv6 and
uses stateless IPv4/IPv6 translation for the external IPv4 access.
Both mechanisms have been deployed in CERNET and providing services
to the global IPv4/IPv6 Internet.
"Service Function Chaining Using MPLS-SPRING", Xiaohu Xu, Zhenbin Li,
Himanshu Shah, Luis Contreras, 2016-03-07,
<draft-xu-sfc-using-mpls-spring-05.txt>
Source Packet Routing in Networking (SPRING) WG specifies a special
source routing mechanism. Such source routing mechanism can be
leveraged to realize the service path layer functionality of the
service function chaining (i.e, steering traffic through a particular
service function path) by encoding the service function path or the
service function chain information as the explicit path information.
This document describes how to leverage the MPLS-based source routing
mechanism as developed by the SPRING WG to realize the service path
layer functionality of the service function chaining.
"Adding Support for Salted Password Databases to EAP-pwd", Dan Harkins,
2016-02-19, <draft-harkins-salted-eap-pwd-03.txt>
EAP-pwd is an EAP method that uses a shared password for
authentication using a technique that is resistant to dictionary
attack. It included support for raw keys and RFC2751-style double
hashing of a password but did not include support for salted
passwords. There are many existing databases of salted passwords and
it is desirable to allow their use with EAP-pwd.
"SDP Descriptors for MMTP", Imed Bouazizi, 2016-03-21,
<draft-bouazizi-sdp-descriptors-mmtp-01.txt>
This document specifies the use of SDP for the description of MPEG
Media Transport protocol (MMTP) sessions. It defines the parameters
required to begin, join, receive data from, and/or end MMTP sessions.
"Additional XML Security Uniform Resource Identifiers (URIs)", Donald

Eastlake, 2016-04-04, <draft-eastlake-rfc6931bis-xmlsec-uris-03.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.
"Cisco Systems' Encapsulated Remote Switch Port Analyzer (ERSPAN)",
Marco Foschiano, 2016-01-23, <draft-foschiano-erspan-01.txt>
This document describes an IP-based packet capture format that can
be used to transport exact copies of packets to a network probe to
analyze and characterize the operational load and protocol
distribution of a network as well as to detect anomalies such as
network-based worms or viruses. This replication and transport
mechanism operates over one or multiple switch or router ports whose
traffic can be mirrored and forwarded to a destination device in
charge of traffic analysis and reporting.
"Allocation Token Extension for the Extensible Provisioning Protocol
(EPP)", James Gould, Trung Tran, Sharon Wodjenski, 2015-11-23,
<draft-gould-allocation-token-03.txt>
This document describes an Extensible Provisioning Protocol (EPP)
extension for including an allocation token or code for allocating an
object like a domain name to the client. The allocation token MAY be
transferred out-of-band to a client to give them authorization to
allocate an object using one of the EPP transform commands including
create, update, and transfer.
"A YANG Data Model for Path Computation Element Communications Protocol
(PCEP)", Dhruv Dhody, Jonathan Hardwick, Vishnu Pavan Beeram, Jeff
Tantsura, 2016-01-28, <draft-pkd-pce-pcep-yang-05.txt>
This document defines a YANG data model for the management of Path
Computation Element communications Protocol (PCEP) for communications
between a Path Computation Client (PCC) and a Path Computation
Element (PCE), or between two PCEs. The data model includes
configuration data and state data (status information and counters
for the collection of statistics).
"NFVIaaS Architectural Framework for Policy Based Resource Placement and
Scheduling", Ram (Ramki) Krishnan, Norival Figueira, Dilip Krishnaswamy,
Diego Lopez, Steven Wright, Tim Hinrichs, Ruby Krishnaswamy, Arun Yerra,
2016-03-02, <draft-krishnan-nfvrg-policy-based-rm-nfviaas-06.txt>
One of the goals of Network Functions Virtualization (NFV) is to
offer the NFV infrastructure as a service to other SP customers this is called NFVIaaS. Virtual Network Function (VNF) deployment in
this paradigm will drive support for unique placement policies,
given VNF's stringent service level specifications (SLS) required by
customer SPs. Additionally, NFV DCs often have capacity, energy and
other constraints - thus, optimizing the overall resource usage
based on policy is an important part of the overall solution. The
purpose of this document is to depict an architectural framework for
policy based resource placement and scheduling in the context of

NFVIaaS.
"Declaring Kerberos Realm Names in DNS (_kerberos TXT)", Rick van Rein,
2016-03-15, <draft-vanrein-dnstxt-krb1-08.txt>
This specification defines a method to determine Kerberos realm names
for services that are known by their DNS name. Currently, such
information can only be found in static mappings or through educated
guesses. DNS can make this process more flexible, provided that
DNSSEC is used to assure authenticity of resource records.
"YANG Data Model for NVO3 Protocols", Mingui Zhang, Lianshu Zheng, Feng
Zheng, Fu Qiao, 2015-12-15, <draft-zhang-nvo3-yang-cfg-03.txt>
This document describes the base YANG data model that can be used by
operators to configure and manage NVO3 protocols.
"Unifying Carrier and Cloud Networks: Problem Statement and Challenges",
Robert Szabo, Andras Csaszar, Kostas Pentikousis, Mario Kind, Diego
Daino, Zu Qiang, Hagen Woesner, 2016-01-13,
<draft-unify-nfvrg-challenges-03.txt>
The introduction of network and service functionality virtualization
in carrier-grade networks promises improved operations in terms of
flexibility, efficiency, and manageability. In current practice,
virtualization is controlled through orchestrator entities that
expose programmable interfaces according to the underlying resource
types. Typically this means the adoption of, on the one hand,
established data center compute/storage and, on the other, network
control APIs which were originally developed in isolation. Arguably,
the possibility for innovation highly depends on the capabilities and
openness of the aforementioned interfaces. This document introduces
in simple terms the problems arising when one follows this approach
and motivates the need for a high level of programmability beyond
policy and service descriptions. This document also summarizes the
challenges related to orchestration programming in this unified cloud
and carrier network production environment. A subsequent problem is
the resource orchestration. This is handled separately in
[I-D.caszpe-nfvrg-orchestration-challenges] and will be merged in the
next iteration of this document.
"Framework for Deriving Interface Data Schema from UML Information
Models", Malcolm Betts, Nigel Davis, Kam Lam, Eve Varma, Bernd Zeuner,
Scott Mansfield, Paul Doolan, 2016-03-18,
<draft-betts-netmod-framework-data-schema-uml-03.txt,.pdf>
This draft describes a framework for how purpose and protocol
specific interfaces can be systematically derived from an underlying
common information model, focusing upon the networking and forwarding
domain. The benefit of using such an approach in interface
specification development is to promote convergence,
interoperability, and efficiency.
"Existing Support for Network Operations in Multilayer Transport Network
based upon unified approach to OAM (Layer 0 - Layer 2)", Kam Lam, Eve
Varma, Scott Mansfield, Yuji Tochio, Huub van Helvoort, Maarten Vissers,
Paul Doolan, 2016-03-18,
<draft-lam-lime-summary-l0-l2-layer-independent-04.txt,.pdf>
This draft summarizes the existing ITU-T SG 15 standards, (Layer 0 -

Layer 2) both technology-specific and generic across these

technologies, relevant to leveraging OAM to support fault management,
performance monitoring, and configuration management. Knowledge from
this domain may be leveraged for the benefit of developing generic
layer independent management for other layers.
"AC-influenced Designated Forwarder Election for EVPN", Jorge Rabadan,
Kiran Nagaraj, Senthil Sathappan, Vinod Prabhu, Wim Henderickx, Autumn
Liu, 2016-01-11, <draft-rabadan-bess-evpn-ac-df-03.txt>
The Designated Forwarder (DF) in EVPN networks is the PE responsible
for sending multicast, broadcast and unknown unicast traffic to a
multi-homed CE, on a given Ethernet Tag on a particular Ethernet
Segment (ES). The DF is selected based on the list of PEs that
advertise the Ethernet Segment Identifier (ESI) to the EVPN network.
While PE node or link failures trigger the DF re-election for a given
<ESI, EVI>, individual Attachment Circuit (AC) or MAC-VRF failures do
not trigger such DF re-election and the traffic may therefore be
permanently impacted, even though there is an alternative path. This
document improves the DF election algorithm so that the AC status can
influence the result of the election and this type of "logical"
failures can be protected too.
"Session Initiation Protocol (SIP) Cause URI parameter for Service
Number translation", Marianne Mohali, Mary Barnes, 2016-03-21,
<draft-mohali-dispatch-cause-for-service-number-06.txt>
[RFC4458] defines a "cause" URI parameter as having predefined values
for Redirecting reasons as a mapping from ITU-T Q.732.2-5 Redirecting
Reasons. The "cause" URI parameter is to be used in SIP or SIPs URI.
In particular, it may appear in the Request-URI of a SIP request.
This specification creates a new predefined value for the "cause" URI
parameter for cases when the retargeting is due to specific service
action leading to a called service access number translation.
This document updates [RFC4458].
"Egress Peer Engineering using BGP-LU", Hannes Gredler, Kaliraj
Vairavakkalai, Chandra R, Balaji Rajagopalan, Luyuan Fang, exa,
2016-03-10, <draft-gredler-idr-bgplu-epe-05.txt>
The MPLS source routing paradigm provides path control for both
intra- and inter- Autonomous System (AS) traffic. RSVP-TE is
utilized for intra-AS path control. This documents outlines how MPLS
routers may use the BGP labeled unicast protocol (BGP-LU) for doing
traffic-engineering on inter-AS links.
"A YANG Data Model for L2TPv3 Tunnel", Haoxing Shen, Bing Liu, David
Bannister, Mikael Abrahamsson, 2015-12-23,
<draft-shen-l2tpext-l2tpv3-yang-model-03.txt>
This document defines a YANG data model for managing L2TPv3 tunnels.
"YANG Data Model for Active-Active NVEs Configuration", Mingui Zhang,
Jinwei Xia, Fu Qiao, Muhammad Durrani, Zu Qiang, Sujay Gupta,
2015-12-15, <draft-zhang-nvo3-yang-active-active-cfg-03.txt>
When a Tenant System is not collocated with Network Virtualization
Edges (NVEs), it's possible for this Tenant System to connect to a
group of NVEs or a single NVE with multiple underlay IP addresses to
use the active-active multihoming L2/L3 service provided by these

NVEs.
This document defines the YANG data model that can be used to
configure NVEs of a NVO3 network to achieve active-active multihoming.
"Software-Defined Networking Based Security Services using Interface to
Network Security Functions", Jaehoon Jeong, Hyoungshick Kim, Park
Jung-Soo, Tae-Jin Ahn, sehuilee@kt.com, 2016-03-16,
<draft-jeong-i2nsf-sdn-security-services-04.txt>
This document describes a framework, objectives, requirements, and
use cases for security services based on Software-Defined Networking
(SDN) using a common Interface to Network Security Functions (I2NSF).
It first proposes the framework of SDN-based security services in the
I2NSF framework. It then explains three use cases, such as a
centralized firewall system, centralized DDoS-attack mitigation
system, and centralized VoIP/VoLTE security system.
"LIME base model extension for BFD Support", Zitao Wang, Liang Xia,
Deepak Kumar, Qin Wu, 2015-11-27, <draft-wang-yang-bfd-oam-06.txt>
This document discusses how LIME base model is applied to BFD and
present an example of YANG Data model for BFD support. The YANG
Model presented in this document extends the technology independent
YANG model for OAM with BFD technology specifics.
"Analysis on Forwarding Methods for Service Chaining", Shunsuke Homma,
Kengo Naito, Diego Lopez, Martin Stiemerling, David Dolson, Alexey
Gorbunov, Nicolai Leymann, P. Bottorff, don.fedyk@hpe.com, 2016-01-29,
<draft-homma-sfc-forwarding-methods-analysis-05.txt>
This document presents the results of analyzing packet forwarding
methods and path selection patterns for achieving Service Chaining.
In Service Chaining, data packets need to be forwarded to the
appropriate service functions deployed in networks based on service
provided for the packets, and distribution of the service-oriented
route information and steering data packets following the route
information would be required.
"YANG Data Model for SFC Operations, Administration, and Maintenance
(OAM)", Liang Xia, Qin Wu, Deepak Kumar, Mohamed Boucadair, Zitao Wang,
2015-12-11, <draft-xia-sfc-yang-oam-05.txt>
This document defines YANG data model for Service Function Chaining
(SFC Operations, Administration, and Maintenance (OAM). It extends
from the basic YANG data model for Layer independent OAM Management
defined in [I-D.ietf-lime-yang-oam-model] with SFC technology
specifics. It includes SFC OAM related configuration, state, and RPC
information data.
"Multi-Layering OAM for Service function Chaining", Cui Wang, Wei Meng,
Bhumip Khasnabish, 2015-12-21, <draft-wang-sfc-multi-layer-oam-03.txt>
This document tries to discuss some problems in SFC OAM framework
document and proposes the SFC OAM multi-layering requirements in SFC
domain to improve the troubleshooting efficiency.
"Generic UDP Encapsulation (GUE) for Network Virtualization Overlay",
Lucy Yong, Tom Herbert, Osama Zia, 2016-03-14,

<draft-hy-nvo3-gue-4-nvo-03.txt>
This document describes network virtualization overlay encapsulation
scheme by use of Generic UDP Encapsulation (GUE) [GUE]. It allocates
one GUE optional flag and defines a 32 bit field for Virtual Network
Identifier (VNID).
"Generic UDP Encapsulation (GUE) for Secure Transport", Lucy Yong, Tom
Herbert, 2016-03-14, <draft-hy-gue-4-secure-transport-03.txt>
This document specifies the ability of Generic UDP Encapsulation
(GUE) to provide secure transport over IP networks and the Internet,
including GUE header integrity protection and origin authentication
and GUE payload encryption. These are optional features of GUE.
"Concise Binary Object Representation (CBOR) Tags for ASN.1 Object
Identifiers", Carsten Bormann, Sean Leonard, 2016-01-06,
<draft-bormann-cbor-tags-oid-02.txt>
The Concise Binary Object Representation (CBOR, RFC 7049) is a data
format whose design goals include the possibility of extremely small
code size, fairly small message size, and extensibility without the
need for version negotiation.
The present document makes use of this extensibility to define CBOR
tags <<O>> and <<R>> [values TBD] for ASN.1 object identifiers. It
is intended as the reference document for the IANA registration of
the CBOR tags so defined.
"DevOps for Software-Defined Telecom Infrastructures", Catalin Meirosu,
Antonio Manzalini, Rebecca Steinert, Guido Marchetto, Ioanna Papafili,
Kostas Pentikousis, Steven Wright, 2016-03-20,
<draft-unify-nfvrg-devops-04.txt>
Carrier-grade network management was optimized for environments built
with monolithic physical nodes and involves significant deployment,
integration and maintenance efforts from network service providers.
The introduction of virtualization technologies, from the physical
layer all the way up to the application layer, however, invalidates
several well-established assumptions in this domain. This draft opens
the discussion in NFVRG about challenges related to transforming the
telecom network infrastructure into an agile, model-driven production
environment for communication services. We take inspiration from data
center DevOps regarding how to simplify and automate management
processes for a telecom service provider software-defined
infrastructure (SDI). Among the identified challenges, we consider
scalability of observability processes and automated inference of
monitoring requirements from logical forwarding graphs, as well as
initial placement (and re-placement) of monitoring functionality
following changes in flow paths enforced by the controllers. In
another category of challenges, verifying correctness of behavior for
network functions where flow rules are no longer necessary and
sufficient for determining the forwarding state (for example,
stateful firewalls or load balancers) is very difficult with current
technology. Finally, we introduce challenges associated with
operationalizing DevOps principles at scale in software-defined
telecom networks in three areas related to key monitoring,
verification and troubleshooting processes.
"Object Security of CoAP (OSCOAP)", Goran Selander, John Mattsson,

Francesca Palombini, Ludwig Seitz, 2016-03-21,

<draft-selander-ace-object-security-04.txt>
This memo defines Object Security of CoAP (OSCOAP), a method for
application layer protection of message exchanges with the
Constrained Application Protocol (CoAP), using the CBOR Encoded
Message Syntax. OSCOAP provides end-to-end encryption, integrity and
replay protection to CoAP payload, options, and header fields, as
well as a secure binding between CoAP request and response messages.
The use of OSCOAP is signaled with the CoAP option Object-Security,
also defined in this memo.
"LFA selection for Multi-Homed Prefixes", Shraddha Hegde, Chris Bowers,
Uma Chunduri, Jeff Tantsura, Bruno Decraene, Hannes Gredler, 2016-01-20,
<draft-psarkar-rtgwg-multihomed-prefix-lfa-03.txt>
This document shares experience gained from implementing algorithms
to determine Loop-Free Alternates for multi-homed prefixes. In
particular, this document provides explicit inequalities that can be
used to evaluate neighbors as a potential alternates for multi-homed
prefixes. It also provides detailed criteria for evaluating
potential alternates for external prefixes advertised by OSPF ASBRs.
"A Survey of Worldwide Censorship Techniques", J.L. Hall, Michael Aaron,
Ben Jones, Nick Feamster, 2016-03-21,
<draft-hall-censorship-tech-03.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.
"Publish-Subscribe Broker for the Constrained Application Protocol
(CoAP)", Michael Koster, Ari Keranen, Jaime Jimenez, 2015-11-05,
<draft-koster-core-coap-pubsub-04.txt,.pdf>
The Constrained Application Protocol (CoAP), and related extensions
are intended to support machine-to-machine communication in systems
where one or more nodes are resource constrained, in particular for
low power wireless sensor networks. This document defines a publishsubscribe broker for CoAP that extends the capabilities of CoAP for
supporting nodes with long breaks in connectivity and/or up-time.
"MPLS-Based Hierarchical SDN for Hyper-Scale DC/Cloud", Luyuan Fang,
Deepak Bansal, Fabio Chiussi, Chandra R, exa, Shahram Davari, Barak
Gafni, daniel.voyer@bell.ca, Nabil Bitar, 2016-01-23,
<draft-fang-mpls-hsdn-for-hsdc-05.txt>
This document describes Hierarchical SDN (HSDN), an architectural
solution to scale the Data Center (DC) and Data Center Interconnect
(DCI) networks to support tens of millions of physical underlay
endpoints, while efficiently handling both Equal Cost Multi Path
(ECMP) load-balanced traffic and any-to-any end-to-end Traffic
Engineered (TE) traffic. HSDN achieves massive scale using
surprisingly small forwarding tables in the network nodes. HSDN
introduces a new paradigm for both forwarding and control planes, in
that all paths in the network are pre-established in the forwarding

tables and the labels can identify entire paths rather than simply
destinations. The HSDN forwarding architecture is based on four main
concepts: 1. Dividing the DC and DCI in a hierarchically-partitioned
structure; 2. Assigning groups of Underlay Border Nodes in charge of
forwarding within each partition; 3. Constructing HSDN MPLS label
stacks to identify endpoints and paths according to the HSDN
structure; and 4. Forwarding using the HSDN MPLS labels.
"Enhanced Mobility Anchoring in Distributed Mobility Management",
Young-Han Kim, Seil Jeon, 2016-03-21,
<draft-yhkim-dmm-enhanced-anchoring-04.txt>
This document presents a new perspective for the solution design of
enhanced mobility anchoring over DMM deployment models described in
[draft-sijeon-dmm-deployment-models].
"Cooperative Stateful Path Computation Element (PCE) for Inter-Domain
Inter-Vendor PCE-initiated LSP Setup", Xiaoping Zheng, Nan Hua, Wangyang
Liu, Yinqiu Jia, Yanlong Li, Bingkun Zhou, Guoying Zhang, 2016-04-27,
<draft-zheng-pce-stateful-pce-inter-domain-lsp-03.txt,.pdf>
A stateful Path Computation Element (PCE) maintains the information
of Label Switched Path (LSP) and resource availability within a
domain. Multiple stateful PCEs are able to provide traffic
engineering inter-domain LSPs through cooperating with each other.
This document introduces the applicability of cooperative stateful
PCE for establishing inter-domain inter-vendor LSPs which are
initiated by PCE.
"Constrained-Cast: Source-Routed Multicast for RPL", Olaf Bergmann,
Carsten Bormann, Stefanie Gerdes, Hao Chen, 2016-04-04,
<draft-bergmann-bier-ccast-01.txt>
This specification defines a protocol for forwarding multicast
traffic in a constrained node network employing the RPL routing
protocol in non-storing mode.
"VXLAN Group Policy Option", Michael Smith, Lawrence Kreeger,
2016-04-25, <draft-smith-vxlan-group-policy-02.txt>
This document defines a backward compatible extension to Virtual
eXtensible Local Area Network (VXLAN) that allows a Tenant System
Interface (TSI) Group Identifier to be carried for the purposes of
policy enforcement.
"AERO Minimal Encapsulation", Fred Templin, 2016-01-08,
<draft-templin-aeromin-03.txt>
Asymmetric Extended Route Optimization (AERO) specifies both a
control messaging and data packet forwarding facility for managing
tunnels over an enterprise network or other Internetwork. Although
AERO can operate with any tunnel encapsulation format, the base
document considers Generic UDP Encapsulation (GUE) as the default.
This document presents minimal encapsulation formats for AERO using
other encapsulation types.
"YANG data model for Flexi-Grid Optical Networks", Universidad de
Madrid, Victor Lopezalvarez, Oscar Gonzalez de Dios, Daniel King, Young
Lee, Zafar Ali, 2016-03-02, <draft-vergara-ccamp-flexigrid-yang-02.txt>

This document defines a YANG model for managing flexi-grid optical

Networks. The model described in this document is composed of two
submodels: one to define a flexi-grid traffic engineering database,
and other one to describe the flexi-grid paths or media channels.
"PSTNization of the Internet", Radi Romansky, Bhumip Khasnabish,
2015-12-30, <draft-rdsx1-intarea-pstnize-internet-02.txt>
This draft discusses the features and functions that the Internet
must support in order to be as robust and trustworthy as the public
switched telephone network (PSTN, http://en.wikipedia.org/wiki/
Public_switched_telephone_network). In general the PSTN-like
features and functions include verifiable addressing and numbering,
higher privacy and security, increased reliability (no more than
around five minutes of unplanned outage over one year time period),
survivability and resiliency, desirable level of scalability, alarms,
correlation, and diagnosis capability, and local/international level
of accountability. Incorporation of these (or similar) features are
expected to harden the Internet.
The topics related to Internet hardening were discussed during IETF88
technical plenary (http://www.ietf.org/proceedings/88/technicalplenary.html) in Vancouver, BC, Canada in Nov. 2013. A follow-up
joint W3C/IAB workshop on strengthening the Internet against
pervasive monitoring (STRINT, https://www.w3.org/2014/strint) was
held before IETF89 meeting in London, UK. During the IETF90
Technical Plenary Session
(http://www.ietf.org/proceedings/90/minutes/minutes-90-iabtechplenary) on Monday, 21 July 2014 in Toronto, Canada the Technical
Topic discussion focused on Network topology and geography. The
presentations revealed that for business relationship and/or policy
reasons, local traffic routinely cross national borders for so called
'efficient' routing, thereby facilitating monitoring, copying, and
surveillance of traffic from users' sessions by both authorized and
unauthorized entities. All of the technical presentations are
available at the website of IETF90
proceedings(http://www.ietf.org/proceedings/90/slides/slides-90-iabtechplenary-9.pdf).
In this draft, we discuss the requirements for PSTNization of
Internet interfaces, protocols, services, and management and
configuration capabilities.
NOTE: We are looking for additional contributors to update the
contents of Section 2 to Section 6. If you are interested, please
send an email to draft-rdsx1-intarea-pstnize-internet@tools.ietf.org
with the relevant Section Number and Section Title in the Subject
line of your email with an estimated completion time.
"Remote checksum offload for VXLAN", Tom Herbert, 2016-03-01,
<draft-herbert-vxlan-rco-01.txt>
This specification describes remote checksum offload for VXLAN.
Remote checksum offload is a mechanism that provides checksum offload
of transport checksums in encapsulated packets using rudimentary
offload capabilities found in most Network Interface Card (NIC)
devices. The outer UDP checksum is enabled on transmit and, with some
additional meta data, a receiver is able to deduce the checksum to be
set in an encapsulated packet. Effectively this offloads the

computation of the inner checksum which can be a significant

performance optimization. Enabling the UDP checksum has the
additional advantage that it covers more of the packet including the
IP pseudo header and virtual network identifier.
"A YANG Data Model for Virtual Router Redundancy Protocol (VRRP)",
Xufeng Liu, Athanasios Kyparlis, Ravi Parikh, Acee Lindem, Mingui Zhang,
2016-04-05, <draft-liu-rtgwg-yang-vrrp-04.txt>
This document describes a data model for Virtual Router Redundancy
Protocol (VRRP). Both version 2 and version 3 of VRRP are covered.
"Use of BGP for Opaque Signaling", Petr Lapukhov, exa, Pedro Marques,
Edet Nkposong, 2016-04-23, <draft-lapukhov-bgp-opaque-signaling-02.txt>
Border Gateway Protocol with multi-protocol extensions (MP-BGP)
enables the use of the protocol for dissemination of virtually any
information. This document proposes a new Address Family/Subsequent
Address Family to be used for distribution of opaque data. This
functionality is intended to be used by applications other than BGP
for exchange of their own data on top of BGP mesh. The structure of
such data SHOULD NOT be interpreted by the regular BGP speakers,
rather the goal is to use BGP purely as a convenient and scalable
communication system.
"Simplemux. A generic multiplexing protocol", Jose Saldana, 2016-01-27,
<draft-saldana-tsvwg-simplemux-04.txt,.pdf>
The low efficiency caused by the high amount of small packets present
in the network can be alleviated by means of packet aggregation.
There are some situations in which multiplexing a number of small
packets into a bigger one is desirable. For example, a number of
small packets can be sent together between a pair of machines if they
share a common network path. Thus, the traffic profile can be
shifted from small to larger packets, reducing the network overhead
and the number of packets per second to be managed by intermediate
routers.
This document describes Simplemux, a protocol able to encapsulate a
number of packets belonging to different protocols into a single
packet. It includes the "Protocol" field on each multiplexing
header, thus allowing the inclusion of a number of packets belonging
to different protocols (multiplexed packets) on a packet of another
protocol (tunneling protocol).
In order to reduce the overhead, the size of the multiplexing headers
is kept very low (it may be a single byte when multiplexing small
packets).
"WebDAV: User Notifications", evert, Cyrus Daboo, 2016-01-11,
<draft-pot-webdav-notifications-02.txt>
This specification defines an extension to WebDAV that allows the
server to provide notifications to users.
"WebDAV Resource Sharing", evert, Cyrus Daboo, Eric <>, 2016-01-11,
<draft-pot-webdav-resource-sharing-03.txt>
This specification defines an extension to WebDAV that enables the
sharing of resources between users on a WebDAV server.

"Syntactic and Semantic Checks for Domain Validation Certificates",

Stephen Kent, Rick Andrews, 2015-12-23,
<draft-kent-trans-domain-validation-cert-checks-02.txt>
Certificate Transparency (CT) [RFC6962-bis] is a system for publicly
logging the existence of X.509 certificates as they are issued or
observed. The logging mechanism allows anyone to audit certification
authority (CA) activity and detect the issuance of "suspect"
certificates. Detecting mis-issuance of certificates is a primary
goal of CT.
A certificate is considered to be mis-issued if it fails to meet
syntactic and/or semantic criteria associated with the type of
certificate being issued. Mis-issuance can be detected by CT log
servers, whose feedback to a CA could prompt the CA to not issue a
suspect certificate. (Preventing the mis-issuance of such a
certificate is preferable to issuing it and detecting it later.)
Compliant CT log servers could offer these checks to a CA submitting
a pre-certificate to be logged. These checks are intended to be used
in an environment in which CAs optionally assert the version of the
EV guidelines to which the submitted pre-certificate purportedly
conforms. Log servers would then perform the checks of supported
[CABF-DV] versions and include the CA's assertion and the log
server's result in its Signed Certificate Timestamp (SCT).
Monitors can also perform checks to detect suspect certificates on
behalf of certificate Subjects. Checks performed by a Monitor also
serve to double check log servers that claim to have checked a
certificate, to identify those that are not doing the checks
properly, e.g., because of errors, compromise, or conspiracy. This
provides Monitors and CT clients with additional information when
choosing which logs to use.
"Syntactic and Semantic Checks for Extended Validation Certificates",
Stephen Kent, Rick Andrews, 2015-12-23,
<draft-kent-trans-extended-validation-cert-checks-02.txt>
Certificate Transparency (CT) [RFC6962-bis] is a system for publicly
logging the existence of X.509 certificates as they are issued or
observed. The logging mechanism allows anyone to audit certification
authority (CA) activity and detect the issuance of "suspect"
certificates. Detecting mis-issuance of certificates is a primary
goal of CT.
A certificate is considered to be mis-issued if it fails to meet
syntactic and/or semantic criteria associated with the type of
certificate being issued. Mis-issuance can be detected by CT log
servers, whose feedback to a CA could prompt the CA to not issue a
suspect certificate. (Preventing the mis-issuance of such a
certificate is preferable to issuing it and detecting it later.)
Compliant CT log servers could offer these checks to a CA submitting
a pre-certificate to be logged. These checks are intended to be used
in an environment in which CAs optionally assert the version of the
EV guidelines to which the submitted pre-certificate purportedly
conforms. Log servers would then perform the checks of supported
[CABF-EV] versions and include the CA's assertion and the log
server's result in its Signed Certificate Timestamp (SCT).

Monitors can also perform checks to detect suspect certificates on

behalf of certificate Subjects. Checks performed by a Monitor also
serve to double check log servers that claim to have checked a
certificate, to identify those that are not doing the checks
properly, e.g., because of errors, compromise, or conspiracy. This
provides Monitors and CT clients with additional information when
choosing which logs to use.
"Windows Image Media Types", Sean Leonard, 2016-04-07,
<draft-seantek-windows-image-03.txt>
This document registers media types for certain image formats
promulgated in Microsoft Windows, namely image/wmf, image/x-wmf,
image/emf, image/x-emf, and image/bmp for use with Windows Metafile,
Enhanced Metafile, and Windows Bitmap formats. Originally designed
for Microsoft Windows 2.0 and 3.0, these image files are intended to
be portable between applications and devices, and may contain both
vector and raster graphics.
"The Applicability Index of IPv4/IPv6 Encapsulation", Wei Mi, Jingguo
Ge, 2015-12-28,
<draft-mi-softwire-applicable-index-encapsulation-01.txt,.pdf>
The Softwire working group is currently discussing both encapsulation
and translation based stateless IPv4/IPv6 solutions in order to be
able to provide IPv4 connectivity to customers in an IPv6-Only
environment.
The purpose of this document is to describe the basic issues and key
elements of the IPv4/IPv6 encapsulation, and presents its
applicability index that would help the operators decide on the
development scheme for their IPv6 transition.It could lead to
significant operational benefits and potential savings for the
operators.
"Multiple multicast addressing architecture", Robert Chodorek,
2016-01-05, <draft-chodorek-6man-multigroup-multicast-addr-02.txt>
This document introduces a new class of IPv6 multicast addresses
called "multiple multicast". We define multiple multicast as a set
of multicast addresses belonging to one multicast session.
"A YANG Data Model for DHCP Configuration", Bing Liu, Kunkun Lou,
2015-12-23, <draft-liu-dhc-dhcp-yang-model-04.txt>
This document defines a YANG data model for configuring DHCP Server,
relay, and client.
"The Applicability Index of Translation", Wei Mi, Jingguo Ge,
2015-12-28, <draft-mi-softwire-applicable-index-translation-01.txt,.pdf>
The Softwire working group is currently discussing both encapsulation
and translation based stateless IPv4/IPv6 solutions in order to be
able to provide IPv4 connectivity to customers in an IPv6-Only
environment.
The purpose of this document is to describe the basic issues and key
elements of the IPv4/IPv6 translation, and presents its applicability
index that would help the operators decide on the development scheme

for their IPv6 transition.It could lead to significant operational

benefits and potential savings for the operators.
"IAB, IESG, and IAOC Selection, Confirmation, and Recall Process:
Operation of the Nominating and Recall Committees", Murray Kucherawy,
2016-04-04, <draft-kucherawy-rfc7437bis-05.txt>
The process by which the members of the IAB and IESG, and some
members of the IAOC, are selected, confirmed, and recalled is
specified in this document. This document is a self-consistent,
organized compilation of the process as it has evolved since the
publication of [RFC7437].
"DBOUND: DNS Administrative Boundaries Problem Statement", Andrew
Sullivan, Jeff Hodges, John Levine, 2016-02-18,
<draft-sullivan-dbound-problem-statement-02.txt>
Some Internet client entities on the Internet make inferences about
the administrative relationships among services on the Internet based
on the domain names at which they are offered. At present, it is not
possible to ascertain organizational administrative boundaries in the
DNS, therefore such inferences can be erroneous in various ways.
Mitigation strategies deployed so far will not scale. This memo
outlines what issues are to be addressed.
"Returning multiple answers in DNS responses.", Warren Kumari, Zhiwei
Yan, Wesley Hardaker, 2016-01-05,
<draft-wkumari-dnsop-multiple-responses-02.txt>
This document (re)introduces the ability to provide multiple answers
in a DNS response.
"Intrusion Detection Parametrization Exchange Format (IDPEF)", Bjoern-C.
Boesch, 2016-02-29, <draft-boesch-idxp-idpef-04.txt>
The Intrusion Detection Parametrization Exchange Format (IDPEF)
defines data formats and exchange procedures to standardize
parametrization information exchange within intrusion detection and
response systems from a Manager to an Analyzer.
This Internet-Draft describes a data model to represent
parametrization information of intrusion detection system entities,
and explains the rationale for using this model. An implementation
of the data model in the Extensible Markup Language (XML) is
presented, a XML Document Type Definition is developed, and
parametrization examples are provided.
"Support of IEEE-1588 time stamp format in Two-Way Active Measurement
Protocol (TWAMP)", Greg Mirsky, Israel Meilik, 2016-02-09,
<draft-mirsky-ippm-time-format-03.txt>
This document describes an OPTIONAL feature for active performance
measurement protocols allowing use of time stamp format defined in
IEEE-1588v2-2008.
"Change Poll Extension for the Extensible Provisioning Protocol (EPP)",
James Gould, Sharon Wodjenski, 2016-03-15,
<draft-gould-change-poll-04.txt>
This document describes an Extensible Provisioning Protocol (EPP)

extension for notifying clients of operations on client sponsored

objects that were not initiated by the client through EPP. These
operations MAY include contractual or policy requirements including
but not limited to regular batch processes, customer support actions,
Uniform Domain-Name Dispute-Resolution Policy (UDRP) or Uniform Rapid
Suspension (URS) actions, court directed actions, and bulk updates
based on customer requests. Since the client is not directly
involved or knowledgable of these operations, the extension is used
along with an EPP object mapping to provide the resulting state of
the post-operation object, and optionally a pre-operation object,
with the operation meta-data of what, when, who, and why.
"AES-OCB (Offset Codebook Mode) Ciphersuites for Transport Layer
Security (TLS)", Aaron Zauner, 2016-04-04,
<draft-zauner-tls-aes-ocb-04.txt>
This memo describes the use of the Advanced Encryption Standard (AES)
in the Offset Codebook Mode (OCB) of operation within Transport Layer
Security (TLS) and Datagram TLS (DTLS) to provide confidentiality and
data origin authentication. The AES-OCB algorithm is highly
parallelizable, provable secure and can be efficiently implemented in
software and hardware providing high performance. Furthermore, use
of AES-OCB in TLS is exempt from former IPR claims by various
parties.
"Identifier-locator addressing for network virtualization", Tom Herbert,
2016-03-14, <draft-herbert-nvo3-ila-02.txt>
This specification describes identifier-locator addressing (ILA) in
IPv6 for network virtualization. Identifier-locator addressing
differentiates between location and identity of a network node. Part
of an address expresses the immutable identity of the node, and
another part indicates the location of the node which can be dynamic.
Identifier-locator addressing can be used to efficiently implement
overlay networks for network virtualization
"IPv4 with 64 bit Address Space", William Chimiak, Samuel Patton, James
Brown, Jeronimo Bezerra, Humberto de Freitas, Jonathan Smith,
2015-12-08, <draft-chimiak-enhanced-ipv4-02.txt>
This document describes a solution to the Internet address depletion
problem through use of a clever IPv4 options mechanism as a solution.
This IPv4 protocol extension is called enhanced IP (EnIP). Because
it is IPv4, it maximizes backward compatibility while increasing
address space by a factor of 17.9 million. Unlike other similar
proposals, care was taken to avoid costly changes and requirements to
the core network and border routers, with the exception that options
be passed in that equipment as described below. Because it is
backward compatible, current IPv4 software, network equipment,
firewalls, intrusion detection/protection, and layer 5 firewalls can
be maintained until IPv6 system information security reaches
acceptable maturity and availability.
"Information Model of Interface to Network Security Functions Capability
Interface", Liang Xia, Dacheng Zhang, Ed, Nicolas Bouthors, Luyuan Fang,
2016-03-21, <draft-xia-i2nsf-capability-interface-im-05.txt>
This draft is focused on the capability interface of NSFs (Network
Security Functions) and proposes its information model for
controlling the various network security functions.

"Remote Call Control and Call Pick-up in SIP", Anton Tveretin,

2016-03-15, <draft-tveretin-dispatch-remote-02.txt>
This memo defines a mechanism by which a SIP user agent could inspect
calls at another user agent, and control a call, including picking up
for itself.
"RSVP Extensions for Dynamic Reservation", Robert Chodorek, Agnieszka
Chodorek, 2015-12-19, <draft-chodorek-tsvwg-rsvp-dynamic-resv-02.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.
"Report from the Workshop and Prize on Root Causes and Mitigation of
Name Collisions", Matthew Thomas, Allison Mankin, Lixia Zhang,
2016-03-09, <draft-thomas-namecollisions-workshop-report-04.txt>
This document provides context and a report of a workshop on Root
Causes and Mitigation of Name Collisions, which took place in London,
United Kindgdom, on March 8 to 10, 2014. The main goal of the
workshop was to foster a discussion on the causes and potential
mitigations of domain name collisions. This report provides a small
amount of background and context, then provides a summary of the
workshop's discussions.
"Yang Data Model for LSP-PING", Lianshu Zheng, Sam Aldrin, Guangying
Zheng, Greg Mirsky, Reshad Rahman, 2016-03-20,
<draft-zheng-mpls-lsp-ping-yang-cfg-03.txt>
When an LSP fails to deliver user traffic, the failure cannot always
be detected by the MPLS control plane. RFC4379 defines a mechanism
that would enable users to detect such failure and to isolate faults.
YANG [RFC6020] is a data definition language that was introduced to
define the contents of a conceptual data store that allows networked
devices to be managed using NETCONF RFC[6241]. This document defines
a YANG data model that can be used to configure and manage LSP-Ping.
"Use Cases and API Extension for Source IP Address Selection", Seil
Jeon, Sergio Figueiredo, Young-Han Kim, John Kaippallimalil, 2016-03-21,
<draft-sijeon-dmm-use-cases-api-source-03.txt>
This draft specifies and analyzes the expected cases regarding the
selection of a proper source IP address and address type based on the
application features over a distributed mobility management (DMM)
network. It also provides available selection methods to better
achieve DMM goals in the specified scenarios.
"Service Function Simple Offloads", Surendra, Jim Guichard, Paul Quinn,
Joel Halpern, 2016-03-15, <draft-kumar-sfc-offloads-02.txt>
Service Function Chaining (SFC) enables services to be delivered by
selective traffic steering through an ordered set of service
functions. Once classified into an SFC, the traffic for a given flow
is steered through all the service functions of the SFC for the life
of the traffic flow even though this is often not necessary.
Steering traffic to service functions only while required and not

otherwise, leads to shorter SFC forwarding paths with improved

latencies, reduced resource consumption and better user experience.
This document describes the rationale, techniques and necessary
protocol extensions to achieve such optimization, with focus on one
such technique termed "simple offloads".
"Explicit Tracking with Wild Card Routes in Multicast VPN", Andrew
Dolganow, Jayant Kotalwar, Eric Rosen, Jeffrey Zhang, 2016-02-16,
<draft-dolganow-bess-mvpn-expl-track-02.txt>
The MVPN specifications provide procedures to allow a multicast
ingress node to invoke "explicit tracking" for a multicast flow or
set of flows, thus learning the egress nodes for that flow or set of
flows. However, the specifications are not completely clear about
how the explicit tracking procedures work in certain scenarios. This
document provides the necessary clarifications. It also specifies a
new, optimized explicit tracking procedure. This new procedure
allows an ingress node, by sending a single message, to request
explicit tracking of each of a set of flows, where the set of flows
is specified using a wildcard mechanism. This document updates
RFC6625.
"Layer-Transcending Traceroute for Overlay Networks like VXLAN", Erik
Nordmark, Chandra Appanna, Alton Lo, 2016-03-21,
<draft-nordmark-nvo3-transcending-traceroute-02.txt>
Tools like traceroute have been very valuable for the operation of
the Internet. Part of that value comes from being able to display
information about routers and paths over which the user of the tool
has no control, but the traceroute output can be passed along to
someone else that can further investigate or fix the problem.
In overlay networks such as VXLAN and NVGRE the prevailing view is
that since the overlay network has no control of the underlay there
needs to be special tools and agreements to enable extracting traces
from the underlay. We argue that enabling visibility into the
underlay and using existing tools like traceroute has been overlooked
and would add value in many deployments of overlay networks.
This document specifies an approach that can be used to make
traceroute transcend layers of encapsulation including details for
how to apply this to VXLAN. The technique can be applied to other
encapsulations used for overlay networks. It can also be implemented
using current commercial silicon.
"A packet based method for passive performance monitoring", Alessandro
Capello, Mauro Cociglio, Giuseppe Fioccola, Luca Castaldelli, Alberto
Bonda, 2016-03-21, <draft-tempia-ippm-p3m-03.txt>
This document describes a passive method to perform packet loss,
delay and jitter measurements on live traffic. This method is based
on Alternate Marking (Coloring) technique. A report on the
operational experiment done at Telecom Italia is explained in order
to give an example and show the method applicability. This technique
can be applied in various situations as detailed in this document.
The previous IETF drafts about this technique were:
[I-D.cociglio-mboned-multicast-pm] and [I-D.tempia-opsawg-p3m].
"Implementing Draft & Release and Draft & Review in Internet Mail",

Alexey Melnikov, 2015-12-17,

<draft-melnikov-email-draft-and-release-02.txt>
This document describes how draft messages intended for Draft &
Release and Draft & Review environments can be represented in
Internet Email.
"BIER Ping and Trace", Nagendra Kumar, Carlos Pignataro, Nobo Akiya,
Lianshu Zheng, Mach Chen, Greg Mirsky, 2015-12-31,
<draft-kumarzheng-bier-ping-02.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 perflow state. BIER also does not require any explicit tree-building
protocol for its operation. A multicast data packet enters a BIER
domain at a "Bit-Forwarding Ingress Router" (BFIR), and leaves the
BIER domain at one or more "Bit-Forwarding Egress Routers" (BFERs).
The BFIR router adds a BIER header to the packet. The BIER header
contains a bit-string in which each bit represents exactly one BFER
to forward the packet to. The set of BFERs to which the multicast
packet needs to be forwarded is expressed by setting the bits that
correspond to those routers in the BIER header.
This document describes the mechanism and basic BIER OAM packet
format that can be used to perform failure detection and isolation on
BIER data plane.
"Traffic Engineering for Bit Index Explicit Replication BIER-TE",
Toerless Eckert, Gregory Cauchie, Wolfgang Braun, Michael Menth,
2016-03-20, <draft-eckert-bier-te-arch-03.txt>
This document proposes an architecture for BIER-TE: Traffic
Engineering for Bit Index Explicit Replication (BIER).
BIER-TE shares part of its architecture with BIER as described in
[I-D.ietf-bier-architecture]. It also proposes to share the packet
format with BIER.
BIER-TE forwards and replicates packets like BIER based on a
BitString in the packet header but it does not require an IGP. It
does support traffic engineering by explicit hop-by-hop forwarding
and loose hop forwarding of packets. It does support Fast ReRoute
(FRR) for link and node protection and incremental deployment.
Because BIER-TE like BIER operates without explicit in-network treebuilding but also supports traffic engineering, it is more similar to
SR than RSVP-TE.
"Communicating Prefix Cost to Mobile Nodes", Pete McCann, John
Kaippallimalil, 2016-04-11, <draft-mccann-dmm-prefixcost-03.txt>
In a network implementing Distributed Mobility Management, it has
been agreed that Mobile Nodes (MNs) should exhibit agility in their
use of IP addresses. For example, an MN might use an old address for
ongoing socket connections but use a new, locally assigned address
for new socket connections. Determining when to assign a new
address, and when to release old addresses, is currently an open
problem. Making an optimal decision about address assignment and
release must involve a tradeoff in the amount of signaling used to
allocate the new addresses, the amount of utility that applications

are deriving from the use of a previously assigned address, and the
cost of maintaining an address that was assigned at a previous point
of attachment. As the MN moves farther and farther from the initial
point where an address was assigned, more and more resources are used
to redirect packets destined for that IP address to its current
location. The MN currently does not know the amount of resources
used as this depends on mobility path and internal routing topology
of the network(s) which are known only to the network operator. This
document provides a mechanism to communicate to the MN the cost of
maintaining a given prefix at the MN's current point of attachment so
that the MN can make better decisions about when to release old
addresses and assign new ones.
"Comparison between Segment Routing and LDP/RSVP-TE", Zhenbin Li,
2016-03-12, <draft-li-spring-compare-sr-ldp-rsvpte-01.txt>
Segment Routing has been proposed to cope with the use cases in
traffic engineering, fast re-reroute, service chain, etc. This
document is to compare Segment Routing with the existing LDP and
RSVP-TE. Through the comparison the challenges are clarified for the
Segment Routing when deploy in the existing MPLS network.
"DHCPv6 Extension for On Demand Mobility exposure", Danny Moses, Alper
Yegin, 2015-12-08, <draft-moses-dmm-dhcp-ondemand-mobility-02.txt>
Applications differ with respect to whether or not they need IP
session continuity and/or IP address reachability. Networks
providing the same type of service to any mobile host and any
application running on the host yields inefficiencies. This document
describes extensions to the DHCPv6 protocol to enable mobile hosts to
indicate the required mobility service type associated with a
requested IP address, and networks to indicate the type of mobility
service associated with the allocated IP address in return.
"Definition of P2MP PW TLV for LSP-Ping Mechanisms", Parag Jain, Sami
Boutros, Sam Aldrin, 2016-03-21,
<draft-jain-bess-p2mp-pw-lsp-ping-03.txt>
LSP-Ping is a widely deployed Operation, Administration, and
Maintenance (OAM) mechanism in MPLS networks. This document
describes a mechanism to verify connectivity of Point-to-Multipoint
(P2MP) Pseudowires (PW) using LSP Ping.
"Propagation of IPv6 Neighbor Advertisement Flags in EVPN", Jorge
Rabadan, Senthil Sathappan, Kiran Nagaraj, 2016-01-11,
<draft-snr-bess-evpn-na-flags-03.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.

"Modern Problem Statement, Use Cases, and Framework", Jon Peterson, Tom
McGarry, 2016-03-21, <draft-peterson-modern-problems-04.txt>
The functions of the public switched telephone network (PSTN) are
rapidly migrating to the Internet. This is generating new
requirements for many traditional elements of the PSTN, including
telephone numbers (TNs). TNs no longer serve simply as telephone
routing addresses, they are now identifiers which may be used by
Internet-based services for a variety of purposes including session
establishment, identity verification, and service enablement. This
problem statement examines how the existing tools for allocating and
managing telephone numbers do not align with the use cases of the
Internet environment, and proposes a framework for Internet-based
services relying on TNs.
"SIP Authentication using the EC-SRP5 Protocol", Fuwen liu, Minpeng Qi,
Min Zuo, 2016-03-03, <draft-liu-sipcore-ec-srp5-02.txt>
This document specifies the way that the elliptic curve secure remote
protocol (EC-SRP) is applied to SIP authentication. SIP Client and
server perform mutual authenticate by using the modern 'zero
knowledge' method without disclosing the password in the process. It
has low computation complexity and low bandwidth consumption due to
the use of elliptical curve cryptography. This makes it more suitable
for resource-constrained environments,e.g. wireless network. The
security of the scheme is based on the computational intractability
of the elliptic curve discrete logarithm problem. It is resilient to
various kinds of attacks, including off-line dictionary attacks.
"Processing Multiple Replies for One Request in NETCONF", Bing Liu,
Guangying Zheng, Mahesh Jethanandani, Kent Watsen, 2016-03-21,
<draft-liu-netconf-multiple-replies-02.txt>
This document discusses several scenarios that multiple replies for a
single request are needed, with the ability to terminate the replies
at any time. Such scenarios are not well supported by current
NETCONF (Network Configuration) protocol. An extention at the
NETCONF messaging layer is needed to fulfill the requirement.
"Deterministic Networking Architecture", Norman Finn, Pascal Thubert,
Michael Teener, 2016-03-21, <draft-finn-detnet-architecture-04.txt>
Deterministic Networking (DetNet) provides a capability to carry
specified unicast or multicast data flows for real-time applications
with extremely low data loss rates and bounded latency. Techniques
used include: 1) reserving data plane resources for individual (or
aggregated) DetNet flows in some or all of the relay systems (bridges
or routers) along the path of the flow; 2) providing fixed paths for
DetNet flows that do not rapidly change with the network topology;
and 3) sequentializing, replicating, and eliminating duplicate
packets at various points to ensure the availability of at least one
path. The capabilities can be managed by configuration, or by manual
or automatic network management.
"IPFIX Information Element extension for SFC", Nagendra Kumar, Carlos
Pignataro, Paul Quinn, 2015-12-31,
<draft-kumar-ipfix-sfc-extension-02.txt>
Service Function Chaining (SFC) is an architecture that enables any

operator to apply selective set of services by steering the traffic

through an ordered set of service functions without any topology
dependency.
This document defines the required Information Elements to represent
the details about service flows over any Service Function Path.
"Distributed Mobility Anchoring", Anthony Chan, Xinpeng Wei, Jong-Hyouk
Lee, Seil Jeon, Fred Templin, 2016-03-18,
<draft-chan-dmm-distributed-mobility-anchoring-07.txt,.pdf>
This document defines distributed mobility anchoring. Multiple
anchors and nodes are configured with appropriate mobility functions
and work together to enable mobility solutions. Example solution is
mid-session switching of the IP prefix anchor. Without ongoing
session requiring session continuity, a flow can be started or restarted using the new IP prefix which is allocated from the new
network and is therefore anchored to the new network. With ongoing
session, the anchoring of the prior IP prefix may be relocated to the
new network to enable session continuity.
"Terminology related to TLS and DTLS", Jens Guballa, Juergen
Stoetzer-Bradler, He Bing, 2016-03-11,
<draft-guballa-tls-terminology-03.txt>
Purpose of this RFC is to provide a central place of all key terms
as used by the various RFCs on protocols TLS and DTLS.
"BGP Next-Hop dependant capabilities", Bruno Decraene, Kireeti Kompella,
Wim Henderickx, 2016-03-11,
<draft-decraene-idr-next-hop-capability-02.txt>
RFC 5492 defines capabilities advertisement for the BGP peer. In
addition, it is useful to be able to advertise BGP Next-Hop dependant
capabilities, in particular for forwarding plane features. RFC 5492
is not applicable because the BGP peer may be different from the BGP
Next-Hop, in particular when BGP Route Reflection is used. This
document defines a mechanism to advertise such BGP Next Hop dependant
Capabilities.
This document defines a new BGP non-transitive attribute to carry
Next-Hop Capabilities. This attribute is deleted or possibly
modified when the BGP Next Hop is changed.
This document also defines a Next-Hop capability to advertise the
ability to handle the MPLS Entropy Label defined in RFC 6790. It
updates RFC 6790 with regard to this BGP signaling.
"Definition of P2MP PW TLV for LSP-Ping Mechanisms", Parag Jain, Sami
Boutros, Sam Aldrin, 2016-05-06,
<draft-jain-pals-p2mp-pw-lsp-ping-01.txt>
LSP-Ping is a widely deployed Operation, Administration, and
Maintenance (OAM) mechanism in MPLS networks. This document
describes a mechanism to verify connectivity of Point-to-Multipoint
(P2MP) Pseudowires (PW) using LSP Ping.
"EVPN-VPWS Service Edge Gateway", Sami Boutros, Patrice Brissette, Ali
Sajassi, daniel.voyer@bell.ca, John Drake, 2016-03-16,
<draft-boutros-bess-evpn-vpws-service-edge-gateway-02.txt>

This document describes how a service node can dynamically terminate

EVPN virtual private wire transport service (VPWS) from access nodes
and offer Layer 2, Layer 3 and Ethernet VPN overlay services to
Customer edge devices connected to the access nodes. Service nodes
using EVPN will advertise to access nodes the L2, L3 and Ethernet VPN
overlay services it can offer for the terminated EVPN VPWS transport
service. On an access node an operator can specify the L2 or L3 or
Ethernet VPN overlay service needed by the customer edge device
connected to the access node that will be transported over the EVPNVPWS service between access node and service node.
"RSVP-TE Summary Fast Reroute Extensions for LSP Tunnels", Mike Taillon,
Tarek Saad, Nicholas Tan, Abhishek Deshmukh, Markus Jork, Vishnu Pavan
Beeram, 2016-03-18, <draft-mtaillon-mpls-summary-frr-rsvpte-04.txt>
This document defines RSVP-TE signaling extensions that reduce the
amount of RSVP signaling required for Fast Reroute (FRR) procedures
and subsequently improve the scalability of the RSVP-TE signaling
when undergoing FRR convergence post a link or node failure. Such
extensions allow the RSVP message exchange between the Point of Local
Repair (PLR) and the Merge Point (MP) to be independent of the number
of protected Label Switched Paths (LSP)s traversing between them (eg.
when bypass LSP FRR protection is used). The new signaling
extensions are fully backwards compatible with nodes that do not
support them.
"TRILL: Link Security", Donald Eastlake, Dacheng Zhang, 2016-04-12,
<draft-eastlake-trill-link-security-03.txt>
The TRILL protocol supports arbitrary link technologies between TRILL
switches, both point-to-point and broadcast links, and supports
Ethernet links between edge TRILL switches and end stations.
Communications links are constantly under attack by criminals and
national intelligence agencies as discussed in RFC 7258. Link
security is an important element of security in depth, particularly
for links that are not entirely under the physical control of the
TRILL network operator or that include device which may have been
compromised. This document specifies link security recommendations
for TRILL over Ethernet, PPP, and pseudowire links. It updates RFC
6325, RFC 6361, and RFC 7173. It requires that link encryption MUST
be implemented and that all TRILL Data packets between TRILL switch
ports capable of encryption at line speed MUST default to being
encrypted.
[This is a early partial draft.]
"Cooperative Adaptive Cruise Control and Platooning at SDOs and Gap
Analysis", Alexandre Petrescu, Jing Huang, Thierry Ernst, Rex
Buddenberg, Charles Perkins, 2016-04-18,
<draft-petrescu-its-cacc-sdo-05.txt>
This document describes the use-cases of Cooperative Adaptive Cruise
Control, and Platooning, as defined by several Standards Development
Organizations such as ETSI, IEEE P1609, SAE, 3GPP, ISO and FirstNet.
C-ACC and Platooning involve concepts of direct vehicle-to-vehicle,
and device-to-device communications, which are developed by 3GPP
following on work done within the METIS EU project. They are
illustrated very clearly in emergency settings such as FirstNet.

IP packets - instead of link-layer frames - are pertinent for C-ACC

and Platooning use-cases because applications for road safety such as
WAZE, iRezQ and Coyote (currently involving infrastructure) make use
of IP messages, and have proved successful in deployments.
Applications such as Sentinel operate directly between vehicles, but
currently use messages not carried over IP.
"OSPF TE Topology-Transparent Zone", Huaimo Chen, Renwei Li, Gregory
Cauchie, Alvaro Retana, So Ning, Fengman Xu, Vic Liu, Mehmet Toy, Lei
Liu, 2016-03-21, <draft-chen-ospf-te-ttz-02.txt>
A topology-transparent zone is virtualized as the edges of the zone
fully connected. This document proposes extensions to OSPF protocols
to support Traffic Engineering (TE) topology-transparent zone.
"CoAP Protocol Negotiation", Bill Silverajan, 2016-03-10,
<draft-silverajan-core-coap-protocol-negotiation-02.txt>
CoAP has been standardised as an application-level REST-based
protocol. This document introduces a way forward for CoAP clients
and servers to exchange resource representations when multiple
transports exist at an endpoint, by agreeing upon alternate locations
as well as transport and protocol configurations.
"Session Description Protocol (SDP) WebSocket Connection URI Attribute",
Ram R, Gonzalo Salgueiro, 2016-02-16,
<draft-ram-bfcpbis-sdp-ws-uri-03.txt>
The WebSocket protocol enables bidirectional real-time communication
between clients and servers in web-based applications. This document
specifies extensions to Session Description Protocol (SDP) for
application protocols using WebSocket as a transport.
"Comprehensive Core Rules and References for ABNF", Sean Leonard,
2016-03-11, <draft-seantek-abnf-more-core-rules-05.txt>
This document extends the base definition of ABNF (Augmented BackusNaur Form) to include comprehensive support for certain symbols
related to ASCII, and defines a reference syntax.
"YANG Data Model for MPLS LDP and mLDP", Kamran Raza, Rajiv Asati,
Xufeng Liu, Santosh Esale, Xia Chen, Himanshu Shah, 2016-03-21,
<draft-raza-mpls-ldp-mldp-yang-03.txt>
This document describes a YANG data model for Multi-Protocol Label
Switching (MPLS) Label Distribution Protocol (LDP) and Multipoint LDP
(mLDP).
"Forwarding-Label support in CCN Protocol", Ravi Ravindran, Asit
Chakraborti, aytav.azgin, 2016-03-21,
<draft-ravi-ccn-forwarding-label-02.txt>
The objective of this proposal is to enable ID and Locator namespace
split in the CCN protocol that has several applications such as
towards Interest routing optimization, mobility, handling
indirections in manifests, and routing scalability. We enable this
through the notion of forwarding-label (FL) object, which is an
optional hop-by-hop payload in the Interest message with a locator
name which identifies a network domain, router, or a host. Depending

on the application and trust context, an FL object can be subjected

to policy based actions by the forwarders such as invoking security
verification or enabling other service-centric actions such as FL
object replacement. FL object can be inserted by the applications or
by the network. To enable dynamic name resolution FL objects can
also be modified in the network by designated points such as the edge
routers.
"BGP-LU for HSDN Label Distribution", Luyuan Fang, Deepak Bansal,
Chandra R, Fabio Chiussi, Nabil Bitar, Yakov Rekhter, 2016-01-23,
<draft-fang-idr-bgplu-for-hsdn-03.txt>
This document describes modifications of BGP Labeled Unicast (BGP-LU)
procedures for label distribution in a partitioned network.
Specifically, these procedures are suitable for building the
Hierarchical SDN (HSDN) control plane for the hyper-scale Data Center
(DC) and cloud networks.
"Using Operator-defined TLVs for Agile Service Deployment", Uma
Chunduri, Xiaohu Xu, Luis Contreras, Mohamed Boucadair, Luay Jalil,
2016-01-06, <draft-chunduri-ospf-operator-defined-tlvs-02.txt>
This document proposes a TLV within the body of the OSPF Router
Information (RI) Opaque LSA, called Operator-defined Sub-TLV
Container TLV. Here the term OSPF means both OSPFv2 and OSPFv3.This
attribute is meant to accommodate policy-based and deploymentspecific use cases.
"Simple Certificate Enrolment Protocol", Peter Gutmann, Jerome Marcon,
2016-03-15, <draft-gutmann-scep-02.txt>
This document specifies the Simple Certificate Enrolment Protocol
(SCEP), a Public Key Infrastructure (PKI) communication protocol
which 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 now enjoys wide
support in both client and server implementations, as well as being
relied upon by numerous other industry standards that work with
certificates.
"Off-Path Signaling Protocol for Service Function Chaining", Mauro
Femminella, Gianluca Reali, Dario Valocchi, 2016-04-04,
<draft-femmreali-sfc-offpath-signaling-02.txt>
This document illustrates a reference protocol able to discover
deployed instances of Service Functions (SFs), which can be located
also off-path with respect to the IP datapath between flow source
and flow destination. It is an application protocol organized in two
layers: signaling transport, which deal lower layer signaling
transport, and signaling application, which directly interfaces with
the intended SF. Discovery of SFs is a primary step to for
implementing Service Function Chaining (SFC).
"Fluffy: Simplified Key Exchange for Constrained Environments", Thomas
Hardjono, Ned Smith, 2016-01-04, <draft-hardjono-ace-fluffy-02.txt>
This document proposes a simplified key exchange protocol for the
establishment of a symmetric key shared between two devices or
entities within a constrained environment. The pair-wise key
establishment is performed using the mediation of a trusted Simple

Key Distribution Center (SKDC) entity. The protocol also supports

the mediated distribution of a group-key among multiple devices or
entities for the purposes of protecting multicast messages.
"NSEC5, DNSSEC Authenticated Denial of Existence", Jan Vcelak, Sharon
Goldberg, Dimitrios Papadopoulos, 2016-03-21,
<draft-vcelak-nsec5-02.txt>
The Domain Name System Security (DNSSEC) Extensions introduced the
NSEC resource record (RR) for authenticated denial of existence and
the NSEC3 for hashed authenticated denial of existence. The NSEC RR
allows for the entire zone contents to be enumerated if a server is
queried for carefully chosen domain names; N queries suffice to
enumerate a zone containing N names. The NSEC3 RR adds domain-name
hashing, which makes the zone enumeration harder, but not impossible.
This document introduces NSEC5, which provides an cryptographicallyproven mechanism that prevents zone enumeration. NSEC5 has the
additional advantage of not requiring private zone-signing keys to be
present on all authoritative servers for the zone.
"Transmission of IPv6 Packets over WIA-PA Networks", Heng Wang, Ping
Wang, Ji Zou, Xinyu Wei, 2016-03-17, <draft-wang-6lo-wiapa-04.txt,.pdf>
This document describes an Internet Protocol Version 6 (IPv6) packet
transmission scheme for Wireless Networks for Industrial AutomationProcess Automation (WIA-PA) networks. According to the specific
demands of WIA-PA networks, the document proposes the improved WIAPA protocol stack architecture for IPv6 technology, and the
transmission format of IPv6 packets for WIA-PA networks. Furthermore,
based on the characteristics of WIA-PA networks, the IPv6 address
auto-configuration method is also proposed.
"The "vnc" URI Scheme", David, Iordan Iordanov, 2016-02-25,
<draft-warden-appsawg-vnc-scheme-10.txt>
Virtual Network Computing (VNC) software provides remote desktop
functionality. This document describes a Uniform Resource
Identifier (URI) scheme enabling the launch of VNC clients from
other applications. The scheme specifies parameters useful in
securely connecting clients with remote hosts.
"Multi-party Multi-Domain Trust Architecture Recommendations for SDN
Deployment in Carrier Network", saurabhchattopadhya@hcl.com, Kaushik
Datta, 2016-03-21,
<draft-chattopadhyay-sdnrg-multi-party-sdn-trust-02.txt>
This draft analyzes the complexities involved in setting up the
certification infrastructure for multi-tenant, multi-domain SDN
adopted network environment. There are certain architectural options
available to address these complexities, and the same have been
consolidated and analyzed in the draft. However, there are certain
implementation level challenges that create difficulties to
operationalize these options. And these challenges have been
recognized in the draft and further translated into requirements for
setting up an operational framework suitable for managing certificate
chains for SDN integrated environment. Finally, a next level of
assessment has been carried out to consolidate contemporary work
happening in different Work Groups and their likely coverage over
identified operational framework requirements.

"Session Security Envelope", Robert Moskowitz, Igor Faynberg, Huilan Lu,

Susan Hares, Pierpaolo Giacomin, 2016-03-21,
<draft-moskowitz-sse-03.txt>
This memo specifies the details of the Session Security Envelope
(SSE). SSE is a session protocol aiming to guarantee
confidentiality, integrity and authentication completely
independently by the underlying context, namely network and transport
layers. A single session using the SEE protocol can include a single
transport session or multiple transport sessions. This mean that SSE
can survive the break-down in network and transport layers or to
attacks carried against them. SSE is also applicable in networks
lacking in classic inter-networking and transport protocols SSE
relies on modern AEAD block cipher modes of operations, a class of
block cipher modes which allows, at the same time, to authenticate
the message while encrypting a part of it.
"Requirements and Design Patterns for REST Northbound API in SDN", lli,
Wei Zhou, Min Luo, Wu Chou, 2016-03-14,
<draft-li-sdnrg-design-restapi-01.txt>
As stated in ONF SDN Architecture WG Charter [Arc2013], in the SDN
architecture, the control and data planes are decoupled, network
intelligence and state are logically centralized, and the underlying
network infrastructure is abstracted from the applications. As a
result, network operators gain programmability, automation, and
network control, enabling them to build highly scalable, flexible
networks that readily adapt to changing business needs. In this
architecture, the Northbound API provides interfaces to the external
components where applicable.
As REST architectural style has gained more popularity in
implementing loosely-coupled systems, RESTful services are becoming
the style of choice for SDN Northbound API and gaining increasingly
importance in SDN architecture, for example, the Floodlight
[Floodlight] has a Northbound API based on REST.
However, despite the recent advances made on RESTful web services,
there is a lack of guidelines for designing RESTful networking
protocols and communication web services, especially based on the
Resource-Oriented Architecture (ROA) that further refines the REST
principles. Many networking protocols that claim to be REST APIs are
not hypertext driven as prescribed by REST. This situation can lead
to REST networking APIs that are not as scalable, extensible,
maintainable, and interoperable as promised by REST.
This document describes the key rules and design patterns for the
SDN Northbound API in a truly RESTful manner, based on our
experiences with REST API designs in general and SDN Northbound API
design in particular. The rules and the design patterns illustrate
the solutions to the common API problems in REST API designs, using
the network virtualization API of OpenStack as an example.
"MPTCP Experiences in the NorNet Testbed", Thomas Dreibholz, Simone
Ferlin, ozgu@simula.no, Ahmed Elmokashfi, Ioana Livadariu, Xing Zhou,
2016-03-18, <draft-dreibholz-mptcp-nornet-experience-02.txt>
This document collects some experiences of Multi-Path TCP (MPTCP)
evaluations in the NorNet testbed.

"Looking Glass API", Markus Stubbig, 2015-12-07,

<draft-mst-lgapi-03.txt>
This document introduces an application programming interface (API)
to the web-based "Network Looking Glass" software. Its purpose is to
provide application programmers uniform access to the Looking Glass
service and to analyze standardized response.
The API interface is supposed to provide the same level of
information as web-based interfaces, but in a computer-readable
format.
"Multipath Transmission Control Protocol (MPTCP) Partial Reliability
Extension", Changqiao Xu, Hui Huang, Hongke Zhang, Chunshan Xiong, Lei
Zhu, 2016-04-04, <draft-xu-mptcp-prmp-02.txt>
This memo presents an extension to the Multipath Transmission Control
Protocol (MPTCP) that allows MPTCP endpoints in which case both
sender side and receiver side support this function to provide
partially reliable data transmission service to the upper layer
applications. In order to achieve the above goal, this memo extents
MPTCP by adding two new subtypes which are expressed as "PR_CAPABLE"
and "ACK_NOTIFY" and the corresponding processes are also introduced.
The extension can provide the backward-compatibility with MPTCP if
the new features are not available.
"EVPN Inter-subnet Multicast Forwarding", Wen Lin, Jeffrey Zhang, John
Drake, Jorge Rabadan, 2016-03-17, <draft-lin-bess-evpn-irb-mcast-02.txt>
This document describes inter-subnet multicast forwarding procedures
for Ethernet VPNs (EVPN).
"Syslog Management Information Base", Hiroshi Tsunoda, Glenn Mansfield,
2016-04-10, <draft-tsuno-syslog-mib-02.txt>
This memo defines a
the Syslog MIB, for
Internet community.
monitor and control

portion of the Management Information Base (MIB),

use with network management protocols in the
In particular, the Syslog MIB will be used to
syslog applications.

"GRE Tunnel Fragmentation", Fred Templin, 2016-01-26,

<draft-templin-intarea-grefrag-02.txt>
GRE tunnels use IPv4 or IPv6 fragmentation of the delivery packet
when the delivery packet exceeds the tunnel MTU, or when otherwise
necessary. This can cause problems when unmitigated IPv4
fragemntation ensues, or when middleboxes drop IPv6 fragments
unconditionally. This document introduces GRE tunnel fragmentation
which avoids these pitfalls..
"CoRE Application Descriptions", Klaus Hartke, 2016-02-12,
<draft-hartke-core-apps-03.txt>
The interfaces of RESTful, hypertext-driven applications consist of
reusable components such as Internet media types and link relation
types. This document defines a simple standard that application
designers can use to describe the interface of their application in a
structured way so that other parties can develop interoperable
clients and servers or reuse the components in their own
applications.

Note to Readers
This Internet-Draft should be discussed on the Thing-to-Thing
Research Group (T2TRG) mailing list <t2trg@irtf.org>.
"Encapsulating IP in UDP", Xiaohu Xu, Rajiv Asati, Tom Herbert, Lucy
Yong, Yiu Lee, Fan Yongbing, Iljitsch van Beijnum, 2016-01-31,
<draft-xu-intarea-ip-in-udp-03.txt>
Existing Softwire encapsulation technologies are not adequate for
efficient load balancing of Softwire service traffic across IP
networks. This document specifies additional Softwire encapsulation
technology, referred to as IP-in-UDP (User Datagram Protocol), which
can facilitate the load balancing of Softwire service traffic across
IP networks.
"Framework for Interface to Network Security Functions", Ed, Diego
Lopez, Linda Dunbar, John Strassner, Xiaojun Zhuang, Joe Parrott, Ram
(Ramki) Krishnan, Seetharama Durbha, 2016-03-16,
<draft-merged-i2nsf-framework-05.txt>
This document defines the framework for guiding the functionality
provided by I2NSF. Network security functions (NSFs) are packetprocessing engines that inspect and optionally modify packets
traversing networks, either directly or in the context of sessions
in which the packet is associated. This document provides an
overview of how NSFs are used, and describes how NSF software
interfaces are controlled and monitored using rulesets. The design
of these software interfaces must prevent the creation of implied
constraints on NSF capability and functionality.
"An Autonomic IPv6 Addressing Scheme", Michael Behringer, 2016-04-06,
<draft-behringer-anima-autonomic-addressing-03.txt>
The content of this document was merged into
[I-D.ietf-anima-autonomic-control-plane]. This document it no longer
maintained.
"Link Relation Types for Web Services", Erik Wilde, 2016-02-22,
<draft-wilde-service-link-rel-01.txt>
Many resources provided on the Web are part of a sets of resources
that are provided in a context that is defined and managed by one
particular service provider. Often, these sets of resources are
referred to as "Web Services" or "Web APIs". This specification
defines two link relations that allow to represent relationships from
those resources to ones that provide documentation or descriptions of
the Web services. The difference between these concepts is that
documentation is primarily intended for human consumers, whereas
descriptions are primarily intended for automated consumers.
"Carrying Binding Label/Segment-ID in PCE-based Networks.", Siva
Sivabalan, Clarence Filsfils, Stefano Previdi, Jeff Tantsura, Jonathan
Hardwick, Mohan Nanduri, 2016-03-21,
<draft-sivabalan-pce-binding-label-sid-01.txt>
It is possible to associate a binding label to RSVP-TE signaled
Traffic Engineering Label Switching Path or binding Segment-ID (SID)
to Segment Routed Traffic Engineering path. Such a binding label/SID

can be used by an upstream node for steering traffic into the

appropriate TE path to enforce TE policies. This document proposes
an approach for reporting binding label/SID to Path Computation
Element (PCE) for supporting PCE-based Traffic Engineering policies.
"Internet Printing Protocol/1.1: Encoding and Transport", Michael Sweet,
Ira McDonald, 2015-12-15, <draft-sweet-rfc2910bis-07.txt>
This document is one of a set of documents, which together describe
all aspects of a new Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technologies. This document defines the
rules for encoding IPP operations and IPP attributes into the
Internet MIME media type called "application/ipp". This document
also defines the rules for transporting a message body whose ContentType is "application/ipp" over HTTP.
"Internet Printing Protocol/1.1: Model and Semantics", Michael Sweet,
Ira McDonald, 2016-04-20, <draft-sweet-rfc2911bis-09.txt>
This document is one of a set of documents, which together describe
all aspects of the Internet Printing Protocol (IPP). IPP is an
application level protocol that can be used for distributed printing
using Internet tools and technologies. This document describes a
simplified model consisting of abstract objects, their attributes,
and their operations that is independent of encoding and transport.
The model consists of several objects including Printers and Jobs.
Jobs optionally support multiple Documents. IPP 1.1 semantics allow
End Users and Operators to query Printer capabilities, submit print
jobs, inquire about the status of print Jobs and printers, and
cancel, hold, and release print Jobs. IPP 1.1 semantics allow
Operators to pause and resume (Jobs from) Printer objects. This
document also addresses security, internationalization, and directory
issues.
"IMAP REPLACE Extension", S.Brandt, 2016-01-19,
<draft-brandt-imap-replace-02.txt,.pdf>
This document defines an IMAP extension which can be used to replace
an existing message in a message store with a new message. Message
replacement is a common operation for clients that automatically save
drafts or notes as a user composes them.
"Using Application Identification in Services Function Chaining
Metadata", Reinaldo Penno, Benoit Claise, Carlos Pignataro, Christophe
Fontaine, 2015-12-01, <draft-penno-sfc-appid-03.txt>
This document proposes to use the structured application information
in the service function chaining metadata, and specifies a YANG model
for the configuration of the application registry.
"Reseller Extension for the Extensible Provisioning Protocol (EPP)",
Linlin Zhou, Ning, Junkai Wei, XiaoDong Lee, James Gould, 2016-03-09,
<draft-zhou-eppext-reseller-03.txt>
This mapping, an extension to EPP object mappings like the EPP domain
name mapping [RFC5731], to support assigning a reseller to any
existing object (domain, host, contact) as well as any future
objects. Specified in Extensible Markup Language (XML), this
extended mapping is applied to provide additional features required

for the provisioning of resellers.

"Extensible Provisioning Protocol (EPP) Reseller Mapping", Linlin Zhou,
Ning, Guiqing Zhou, XiaoDong Lee, James Gould, 2016-03-09,
<draft-zhou-eppext-reseller-mapping-03.txt>
This document describes an Extensible Provisioning Protocol (EPP)
mapping for provisioning and management of reseller object stored in
a shared central repository. Specified in Extensible Markup Language
(XML), this extended mapping is applied to provide additional
features required for the provisioning of resellers.
"BFD for VXLAN", Juniper Networks, Basil, Sudarsan Paragiri, Vengada
Govindan, Mallik Mudigonda, Greg Mirsky, 2016-04-15,
<draft-spallagatti-bfd-vxlan-03.txt>
This document describes use of Bidirectional Forwarding Detection
(BFD) protocol for VXLAN .
"OVAL and the SACM Information Model", mhansbury@mitre.org, Daniel
Haynes, Juan Gonzalez, 2016-03-07,
<draft-hansbury-sacm-oval-info-model-mapping-02.txt>
The OVAL community has spent more than ten years developing and
employing the OVAL Language. During this time, the community has
made a number of design decisions and learned a number of lessons
that should be leveraged as the next-generation endpoint posture
assessment standards are formulated. There are also a number of
places where portions of the OVAL Language align with the SACM
Information Model and could serve as a starting point for related
work. Another output of the work executed under the OVAL project is
a number of lessons that are applicable to the SACM work. These
lessons include a clear separation of data collection and evaluation;
a call to focus on ensuring both primary source vendors and third
party security experts feel invited to the discussion and are
empowered to leverage their unique domain knowledge; and to strive
for simplicity and flexibility, where possible. In addition, the
OVAL community has a set of clear recommendations with respect to
which parts of OVAL should be used by SACM as a means to make best
use of the efforts of those that have worked on and supported OVAL
over the past ten years. Those recommendations are:
o Use the OVAL System Characteristics Model to inform the
development of a data model for representing endpoint posture
attributes.
o Use the OVAL Definitions Model to inform the development of data
models for representing evaluation and collection guidance.
o Do not use the OVAL Results Model to inform the development of a
data model for representing evaluation results.
Lastly, this document will discuss the OVAL submission, how it is
expected to be used, and how it aligns with the SACM Vulnerability
Assessment Scenario.
"MPEG Media Transport Protocol (MMTP)", Imed Bouazizi, 2016-03-21,
<draft-bouazizi-tsvwg-mmtp-01.txt>
The MPEG Media Transport Protocol (MMTP) is a transport protocol that

is designed to support download, progressive download, and streaming

applications simultaneously. MMTP provides a generic media streaming
mode by optimizing the delivery of generic media data encapsulated
according to the ISO-Base Media File Format (ISOBMFF). In the file
delivery mode, MMTP supports the delivery of any type of file. MMTP
may used in IP unicast or multicast delivery and supports both
Forward Error Correction (FEC) and retransmissions for reliable
delivery of content.
"Endpoint Compliance Standard", Jessica Fitzgerald-McKay, 2015-11-17,
<draft-fitzgeraldmckay-sacm-endpointcompliance-01.txt>
This document describes how published standards can be used to meet
SACM endpoint compliance use cases.
"YANG Data Model for VxLAN Protocol", fangwei hu, Ran Chen, Mallik
Mahalingam, Zu Qiang, 2015-12-01, <draft-chen-nvo3-vxlan-yang-02.txt>
This document defines a YANG data model for VxLAN protocol.
"Network management of encrypted traffic", Kevin Smith, 2015-11-13,
<draft-smith-encrypted-traffic-management-04.txt>
Encrypted Internet traffic may pose traffic management challenges to
network operators. This document recommends approaches to help
manage encrypted traffic, without breaching user privacy or security.
"DAV Server Information Object", Michael Douglass, 2016-04-17,
<draft-douglass-server-info-03.txt,.pdf>
This specification describes a new XML object that can be retrieved
from hosts to discover applications, features and limits for that
host or domain.
"Hostname Capability for BGP", Daniel Walton, Dinesh Dutt, 2016-01-06,
<draft-walton-bgp-hostname-capability-02.txt>
In this document, we introduce a new BGP capability that allows the
advertisemnet of a BGP speaker's hostname.
"UDP Transport for Network Service Header", Surendra, Lawrence Kreeger,
Sumandra Majee, Walter Haeffner, Rajeev Manur, David Melman, 2016-02-11,
<draft-kumar-sfc-nsh-udp-transport-02.txt>
This draft describes the transport encapsulation to carry Network
Service Header (NSH) over UDP transport protocol. This enables
applications and services using NSH to communicate over a simple
layer-3 network without topological constraints. It brings down the
barrier to deploy NSH by not requiring additional overhead as is
typical of overlay encapsulation mechanisms designed on top of UDP.
As a first benefit, this method eases the deployment of Service
Function Chaining (SFC) by allowing SFC components to utilize the
basic UDP/IP stack available in virtually all network elements and
end systems to setup the virtual network and realize Service Function
Chains (SFCs).
"Vpls Best-site id", Anshu Verma, John Drake, Rodny Molina, Wen Lin,
2016-05-02, <draft-anshuverma-bess-vpls-best-site-id-02.txt>

With network-based applications becoming prevalent, solutions that

provide connectivity over wide area become more attractive for
customers. In small-to-medium enterprise sector, Virtual Private LAN
Service (VPLS), is a very useful service provider offering. It
creates an emulated LAN segments fully capable of learning and
forwarding Ethernet MAC addresses.
Today, in VPLS implementations, within the context of a VPLS PE (VE),
a single-site is selected from which all PWs are rooted. The siteelection mechanism is usually hard-coded by different vendors (e.g.
minimum or maximum site-id), and as such, is outside end-users
control. This offers no flexibility to end-users as it forces them to
define the site-id allocation scheme well in advance, or deal with
the consequences of a suboptimal site-id election. Moreover, whenever
the elected site-id is declared down, the traffic to and from all
other sites hosted within the same VE is impacted as well.
This draft defines protocol extensions to keep core-facing
pseudowires (PWs) established at all times, regardless of the events
taking place on the attachment-circuit (AC) segment when using the
BGP-based signaling procedures.
"Path Detection in VXLAN Overlay Network", Junying <>, Dapeng Liu,
Dapeng Liu, Dacheng Zhang, Li Yizhou, Hao Chen, David <>, BoJian <>,
Deepak Kumar, Ruichang Gao, Yan Qiao, 2016-03-20,
<draft-pang-nvo3-vxlan-path-detection-02.txt>
In VXLAN overlay networks, Operation and Management(OAM)functions are
important for fault management and performance monitoring. Path
Detection(PD) is one critical OAM function which is applied to
monitor and/or diagnose the potential paths between two VTEPs or
between two Tenant System. In addition, it can assist to identify
the locations of failures on data transmission paths.
This document specifies a method of PD method for VXLAN Overlay
Networks by using a centralized controller. However,the method can
be easily extended to support the overlay networks without a
centrilized controller. It can also be generalized to other overlay
technique such as NVGRE.
"Intent Common Information Model", Yinben Xia, Tianran Zhou, Yan Zhang,
Susan Hares, Pedro Aranda, Diego Lopez, Jon Crowcroft, Yali Zhang,
2015-11-29, <draft-xia-ibnemo-icim-01.txt>
Intent Common Information Model (ICIM) defines a unified model for
expressing different layers' intent whatever role, responsibility,
knowledge, etc. This document provides an information model to be
inherited and expanded to construct specific intent model in
different areas. According to this information model, network intent
model is put forward which can satisfy users' need in different
layers, such as, end-users, business developers, and network
administers.
"Uniform Data Fingerprint (UDF)", Phillip Hallam-Baker, 2016-03-07,
<draft-hallambaker-udf-03.txt>
This document describes means of generating Uniform Data Fingerprint
(UDF) values and their presentation as text sequences and as URIs.
Cryptographic digests provide a means of uniquely identifying static

data without the need for a registration authority. A fingerprint is

a form of presenting a cryptographic digest that makes it suitable
for use in applications where human readability is required. The UDF
fingerprint format improves over existing formats through the
introduction of a compact algorithm identifier affording an
intentionally limited choice of digest algorithm and the inclusion of
an IANA registered 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.
"Hierarchical Service Function Chaining", David Dolson, Shunsuke Homma,
Diego Lopez, Mohamed Boucadair, Dapeng Liu, Ting Ao, 2016-03-07,
<draft-dolson-sfc-hierarchical-05.txt>
Hierarchical Service Function Chaining (hSFC) is a network
architecture allowing an organization to compartmentalize a largescale network into multiple domains of administration.
The goals of hSFC are to make a large-scale network easier to reason
about, simpler to control and to support independent functional
groups within large operators.
"Dynamic GRE Tunnel", Sheng Jiang, Dayong Guo, Li Xue, 2015-11-24,
<draft-jiang-intarea-dynamic-gre-01.txt>
Generic Routing Encapsulation (GRE) is regarded as a popular
encapsulation tunnel technology. When a node tries to encapsulate
the user traffic in GRE, it needs the IP address of the destination
node which decapsulates the GRE packets. In practice, the GRE tunnel
destination IP addresses are mainly configured manually. This
configuration mechanism causes efficiency issues for operators. This
document proposes an approach to configure the GRE information
dynamically.
"Gap Analysis for Layer and Technology Independent OAM Management in the
Multi-Layer Environment", Yuji Tochio, Huub van Helvoort, Liang Xia,
2015-12-03, <draft-txh-lime-gap-analysis-01.txt,.pdf>
This draft analyses the existing management plane OAM related works
in different SDOs, against the key objectives of Layer Independent
OAM Management (LIME), to find the gap between them. The results can
be used as the guidance for further work. This gap analysis is not
targeted at L0-L2 transport OAM in ITU-T, either technology specific
or generic across those technologies. Rather, it is intended to
leverage knowledge from that domain for the benefit of developing
generic layer independent OAM management for L3-L7 (and L2.5 MPLS
OAM).
"Extensible Provisioning Protocol (EPP) and Registration Data Access
Protocol (RDAP) Status Mapping", James Gould, 2015-11-23,
<draft-gould-epp-rdap-status-mapping-02.txt>
This document describes the mapping of the Extensible Provisioning
Protocol (EPP) statuses with the statuses registered for use in the
Registration Data Access Protocol (RDAP). This document identifies
gaps in the mapping, and registers RDAP statuses to fill the gaps to
ensure that all of the EPP RFC statuses are supported in RDAP.

"Referencing Internet-Drafts in RFCs", Paul Hoffman, 2015-11-23,

<draft-hoffman-id-references-01.txt>
RFC 2026 places restrictions on how Internet-Drafts can be referred
to in RFCs. Over time, the way that the IETF community uses
Internet-Drafts has changed. The restrictions from RFC 2026
sometimes make RFCs inaccurate (because many drafts that are referred
to are not actually "works in progress", and also make references to
Internet-Drafts nearly useless to RFC readers. This document updates
the one part of RFC 2026, and the one part of RFC 7322, that covers
referencing Internet-Drafts.
"HTTP Secure Remote Password (SRP) Authentication Scheme", Rifaat
Shekh-Yusef, Yaron Sheffer, 2016-01-18,
<draft-yusef-httpauth-srp-scheme-02.txt>
This document defines an HTTP Authentication Scheme that is based on
the Secure Remote Password (SRP) protocol. The SRP protocol is an
Augmented Password Authenticated Key Exchange (PAKE) protocol
suitable for authenticating users and exchanging keys over an
untrusted network.
"Use Cases for an Interface to BGP Protocol", Keyur Patel, Russ White,
Susan Hares, 2016-03-21,
<draft-keyupate-idr-i2rs-bgp-usecases-02.txt,.pdf>
A network routing protocol like BGP is typically configured and
analyzed through some form of Command Line Interface (CLI) or
NETCONF. These interactions to control BGP and diagnose its
operation encompass: configuration of protocol parameters, display of
protocol data, setting of certain protocol state and debugging of the
protocol.
Interface to the Routing System's (I2RS) Programmatic interfaces
provides an alternate way to control and diagnose the operation of
the BGP protocol. I2RS may be used for the configuration,
manipulation, analyzing or collecting the protocol data. This
document describes set of use cases for which I2RS can be used for
BGP protocol. It is intended to provide a base for the solution
draft describing a set of interfaces to the BGP protocol.
"Location Source Parameter for the SIP Geolocation Header Field", James
Winterbottom, Laura Liess, Bruno Chatras, Andrew Hutton, 2015-12-04,
<draft-winterbottom-dispatch-locparam-01.txt>
There are some circumstances where a geolocation header field may
contain more than one location value. Knowing the identity of the
node adding the location value allows the recipient more freedom in
selecting the value to look at first rather than relying solely on
the order of the location values.
"'Out-Of-Band' Content Coding for HTTP", Julian Reschke, Salvatore
Loreto, 2016-04-26, <draft-reschke-http-oob-encoding-06.txt>
This document describes an Hypertext Transfer Protocol (HTTP) content
coding that can be used to describe the location of a secondary
resource that contains the payload.
"Multicast Group Address Auto-Provisioning For NVO3 Network", Hao

Weiguo, Li Yizhou, Lili Wang, 2016-03-07,

<draft-hao-bess-mcast-auto-nvo3-01.txt>
This document provides dynamic underlay multicast group address
provisioning mechanism for each VNI or combination of VNI and
overlay multicast group address. The underlay multicast group
address allocation function is provided on NVA(centralized point),
NVE communicates with NVA using BGP protocol extension.
"A Message-Oriented Extension to Multipath Transmission Control Protocol
(MPTCP)", Changqiao Xu, Jiuren Qin, Hongke Zhang, Chunshan Xiong, Lei
Zhu, 2015-12-03, <draft-xu-mptcp-momp-01.txt>
This memo specifies a message-oriented extension for Multipath TCP
(MPTCP) which aims to serve high-bandwidth and real-time
applications. By introducing a message mapping to MPTCP, MessageOriented MPTCP (MO-MPTCP) attaches some message features like
boundaries, priority and dependency to bytestream. With such
message-oriented information, MPTCP senders can optimize their
transfers.
"Via header field parameter to indicate received realm", Christer
Holmberg, Yi Jiang, 2015-12-07,
<draft-holmberg-dispatch-received-realm-01.txt>
This specification defines a new Session Initiation Protocol (SIP)
Via header field parameter, "received-realm", which allows a SIP
entity acting as an entry point to a transit network to indicate from
which adjacent upstream network a SIP request is received, using a
network realm value associated with the adjacent network.
"YANG Data Model for QoS", I. Chen, 2016-04-20,
<draft-chen-rtgwg-qos-yang-02.txt>
This document defines a YANG data model to describe quality-ofservice (QoS) configurations.
"ANIMA Intent Policy and Format", Zongpeng Du, Sheng Jiang, Jeff,
Laurent Ciavaglia, 2016-03-21, <draft-du-anima-an-intent-03.txt,.pdf>
One of the goals of autonomic networking is to simplify the
management of networks by human operators. Intent Based Networking
(IBN) is a possible approach to realize this goal. With IBN, the
operator indicates to the network what to do (i.e. her intent) and
not how to do it. In the field of Policy Based Management (PBM), the
concept of intent is called a declarative policy. This document
proposes a refinement of the intent concept initially defined in
[RFC7575] for autonomic networks by providing a definition, a
hierarchy of policy levels, examples and a tentative format of the
ANIMA Intent Policy.
"Fast failure detection in VRRP with BFD", Nitish Gupta, Aditya Dogra,
Colin Docherty, Greg Mirsky, Jeff Tantsura, 2016-04-13,
<draft-nitish-vrrp-bfd-03.txt>
This document describes how Bidirectional Forwarding Detection (BFD)
can be used to support sub-second detection of a Master Router
failure in the Virtual Router Redundancy Protocol (VRRP).
"Framework for Abstraction and Control of Traffic Engineered Networks",

Daniele Ceccarelli, Young Lee, 2016-04-14,

<draft-ceccarelli-teas-actn-framework-02.txt>
Traffic Engineered networks have a variety of mechanisms to
facilitate the
separation of the data plane and control plane. They also have a
range of management and provisioning protocols to configure and
activate network resources. These mechanisms represent key
technologies for enabling flexible and dynamic networking.
Abstraction of network resources is a technique that can be applied
"Privacy-Enhanced Tokens for Authorization in ACE", Jorge Cuellar,
Prabhakaran Kasinathan, Daniel Calvo, 2016-04-19,
<draft-cuellar-ace-pat-priv-enhanced-authz-tokens-02.txt>
fixed size m (= 256 bits). But this data structure may be
implemented in several different ways, for instance as a set of
tables representing the currently relevant parts of the tree.
We use a sequence of integer numbers as indexes for the nodes
(values) in the tree. To avoid parentheses, commas, and semicolons
we write for instance: "123" for the sequence of 3 numbers "1", "2",
and "3". In what follows, in all our examples of integer sequences,
we will not use numbers that require 2 or more digits (that is,
numbers > 9).
The sequences of integers are used to index values in a tree: x_a is
the value at the node with position (address) a. In other words, the
nodes (and their values) are denoted as x_a, where a is a sequence of
integer numbers. The tree has a root x (x_a where a = epsilon is the
empty sequence). The children of x are x_1, x_2, x_3, ..., x_N,
where k = 1..N is a singleton list, that is a list with only one
number. If x_a is a node in the tree, then the children of x_a all
have the form x_a', where a'=a;i is a the concatenation of a and an
integer i. The value x_a'= x_a; i=x_(a;i) is calculated as G(x_a,i).
In the case of a hash h:
"Negotiating the Maximum Number of Multipath TCP (MPTCP) Subflows",
Mohamed Boucadair, Christian Jacquenet, 2015-12-07,
<draft-boucadair-mptcp-max-subflow-01.txt>
This document specifies an experimental Multipath TCP (MPTCP) option
that is meant to negotiate the maximum number of subflows that can be
established and maintained for a given MPTCP connection. The purpose
is to minimize any possible performance degradation that can be
induced by a possibly large number of establishment requests for
additional subflows if the remote endpoint is not appropriately
dimensioned to handle such requests.
"Generic YANG Data Model for Operations, Administration, and Maintenance
(OAM) Performance Management", Zitao Wang, Qin Wu, Deepak Kumar, Tom
Taylor, 2015-11-28, <draft-wang-lime-yang-pm-01.txt>
This document presents a YANG Data model for OAM Performance
management support. The YANG Model presented in this document
extends the Generic YANG Data Model for OAM with Loss Measurement and
Delay measurement to support OAM Performance management.
"A Minimal Set of Transport Services for TAPS Systems", Stein Gjessing,

Michael Welzl, 2016-03-18, <draft-gjessing-taps-minset-01.txt,.pdf>

This draft will eventually recommend a minimal set of IETF Transport
Services offered by end systems supporting TAPS, and give guidance on
choosing among the available mechanisms and protocols. It
categorizes the set of transport services given in the TAPS document
draft-ietf-taps-transports-usage-00, assuming that the eventual
minimal set of transport services will be based on a similar form of
categorization.
"TLS and DTLS Security Modules", Pascal Urien, 2015-12-21,
<draft-urien-uta-tls-dtls-security-module-01.txt>
Security and trust are very critical topics in the context of the
anywhere, anytime, anything internet connectivity. TLS and DTLS are
two major IETF protocols widely used to secure IP exchanges.
According to COAP, DTLS is the protocol used by constraint nodes in
the Internet of Things (IoT) context.
In this draft we specify an ISO7816 interface for TLS and DTLS
secure modules based on ISO7816 secure chips, which are today
manufactured per billions every year.
Secure elements are cheap secure microcontrollers whose size is
about 25mm2 and whose security is ranked by evaluations typically
according to Common Criteria (CC) standards.
The support of TLS and DTLS is based on the EAP-TLS protocol, and
the IETF draft "EAP Support in smartcard" describing EAP-TLS support
for secure elements. First implementation demonstrates that such low
cost security modules are realistic, with a setup time for handshake
completion under the second.
"MLD Security", Eric Vyncke, Enno Rey, Antonios Atlasis, 2015-12-24,
<draft-vyncke-pim-mld-security-01.txt>
The latest version of Multicast Listener Discovery protocol is
defined in RFC 3810, dated back in 2004, while the first version of
MLD, which is still in use and has not been deprecated, is defined in
RFC 2710 and is dated back in 1999. New security research has
exhibited new vulnerabilities in MLD, both remote and local attack
vectors. This document describes those vulnerabilities and proposes
specific mitigation techniques.
"Vectors of Trust", Justin Richer, Leif Johansson, 2015-11-12,
<draft-richer-vectors-of-trust-02.txt>
This document defines a mechanism for describing and signaling
several aspects that are used to calculate trust placed in a digital
identity transaction.
"TLS Client Authentication via DANE TLSA records", Shumon Huque, Dan
James, Viktor Dukhovni, 2016-01-05,
<draft-huque-dane-client-cert-02.txt>
The DANE TLSA protocol [RFC6698] [RFC7671] describes how to publish
Transport Layer Security (TLS) server certificates or public keys in
the DNS. This document updates RFC 6698 and RFC 7671. It describes
how to additionally use the TLSA record to publish client
certificates or public keys, and also the rules and considerations

for using them with TLS.

"EVPN auto provisioning using a controller", Sami Boutros, Rex Fernando,
Ali Sajassi, Junying Pang, Tapraj Singh, 2016-03-18,
<draft-boutros-bess-evpn-auto-provisoning-01.txt>
In some datacenter use cases, priori knowledge of what PE/NVE to be
configured for a given L2 or L3 service may not be available. This
document describes how EVPN can be extended to discover what L2 or L3
services to be enabled on a given PE/NVE, based on first sign of life
FSOL packets received on the PE/NVE ports. An EVPN route based on the
FSOL packets will be sent to a controller to trigger a push of the
related L2/L3 or subscriber service configuration to be provisioned
on the PE/NVE and on the switch ports.
"Applicability of Generic YANG Data Model for layer Independent OAM
Management", Tom Taylor, Zhuangyan, 2015-12-11,
<draft-zhuang-lime-yang-oam-model-applicability-02.txt>
A generic YANG data model for Operations, Administration, and
Maintenance (OAM) has been defined in [GENYANGOAM], with the
intention that technology-specific extensions will be developed to be
able reference/use the Generic YANG model. In this document, we
describe the applicability of the generic YANG OAM data model to
specific OAM technologies. To be concrete, we also demonstrate the
usability and extensibility of the generic YANG OAM model with OAM
protocols such as IP Ping, traceroute, BFD and MPLS LSP Ping.
"ECDHE_PSK with AES-GCM and AES-CCM Cipher Suites for Transport Layer
Security (TLS)", John Mattsson, Daniel Migault, 2016-04-18,
<draft-mattsson-tls-ecdhe-psk-aead-05.txt>
This document defines several new cipher suites for the Transport
Layer Security (TLS) protocol. The cipher suites are all based on
the Ephemeral Elliptic Curve Diffie-Hellman with Pre-Shared Key
(ECDHE_PSK) key exchange together with the Authenticated Encryption
with Associated Data (AEAD) algorithms AES-GCM and AES-CCM. PSK
provides light and efficient authentication, ECDHE provides perfect
forward secrecy, and AES-GCM and AES-CCM provides encryption and
integrity protection.
"PCEP Extensions for LSP scheduling with stateful PCE", Zhuangyan, Qin
Wu, Dhruv Dhody, Daniele Ceccarelli, 2016-03-21,
<draft-zhuang-pce-stateful-pce-lsp-scheduling-02.txt>
This document proposes a set of extensions needed to the stateful
Path Computation Element (PCE) communication Protocol (PCEP), so as
to enable Labeled Switched Path (LSP) scheduling for path computation
and LSP setup/deletion based on the actual network resource usage
duration of a traffic service in a centralized network environment.
A scheduled LSP can be setup at the its starting time and deleted
after its usage duration such that LSPs for the other traffic
services can take over these network resources beyond that period.
"The Lightweight Directory Access Protocol (LDAP) Content
Synchronization Operation with Transactions", Petr Spacek, 2015-11-18,
<draft-spacek-ldapext-syncrepl-transaction-01.txt>
This document specifies LDAP Control which extends the persist stage
of the Content Synchronization Operation with information about LDAP

transaction boundaries. This information can be used to support

application-level transactions or for application-level
optimizations.
"Co-operative DDoS Mitigation", Tirumaleswar Reddy, Dan Wing, Prashanth
Patil, Mike Geller, Mohamed Boucadair, Robert Moskowitz, 2016-03-16,
<draft-reddy-dots-transport-03.txt>
This document discusses mechanisms that a DOTS client can use, when
it detects a potential Distributed Denial-of-Service (DDoS) attack,
to signal that the DOTS client is under an attack or request an
upstream DOTS server to perform inbound filtering in its ingress
routers for traffic that the DOTS client wishes to drop. The DOTS
server can then undertake appropriate actions (including, blackhole,
drop, rate-limit, or add to watch list) on the suspect traffic to the
DOTS client, thus reducing the effectiveness of the attack.
"Problem statement of SDN and NFV co-deployment in cloud datacenters",
Rong Gu, Chen Li, Ruixue Wang, 2016-02-29,
<draft-gu-sdnrg-problem-statement-of-sdn-nfv-in-dc-01.txt>
With the development of cloud computing technology, cloud datacenters
have been influenced. Co-deployment of SDN and NFV technology shows
its distinct advantages of vitalizing network resources in providing
VPC services and SFC services.In order to deploy SDN and NFV in cloud
datacenters, a resolution test has been conducted. According to the
resolution test, SDN and NFV technology has been nearly mature for
the commercial deployment in operators' network. However, there are
some key problems on network architecture, virtualized platform,
standard interfaces, performance of SDN devices and so on to be
working out in practical practice.
"PMTUD Over Vxlan", Saumya Dikshit, Nayak A, 2015-12-22,
<draft-saum-nvo3-pmtud-over-vxlan-02.txt>
Path MTU Discovery between hosts/VM/servers/end-points connected over
a Data-Center/Service-Provider Overlay Network, is still an
unattended problem. It needs a converged solution to ensure optimal
usage of network and computational resources for all hooked end-point
devices.
"TCP Alternative Backoff with ECN (ABE)", Naeem Khademi, Michael Welzl,
Grenville Armitage, Gorry Fairhurst, 2016-04-04,
<draft-khademi-alternativebackoff-ecn-03.txt>
This memo provides an experimental update to RFC3168. It updates the
TCP sender-side reaction to a congestion notification received via
Explicit Congestion Notification (ECN). The updated method reduces
cwnd by a smaller amount than TCP does in reaction to loss. The
intention is to achieve good throughput when the queue at the
bottleneck is smaller than the bandwidth-delay-product of the
connection. This is more likely when an Active Queue Management
(AQM) mechanism has used ECN to CE-mark a packet, than when a packet
was lost. Future versions of this document will discuss SCTP as well
as other transports using ECN.
"BULK DNS Resource Records", john.woodworth@centurylink.com, Dean
Ballew, Shashwath Raghavan, 2015-12-30, <draft-woodworth-bulk-rr-01.txt>
The BULK DNS resource record type defines a method of pattern based

creation of DNS resource records to be used in place of NXDOMAIN

errors which would normally be returned. These records are currently
restricted to registered DNS resource record types A, AAAA, PTR and
CNAME. The key benefit of the BULK resource record type is the
simplification of maintaining "generic" record assignments which
would otherwise be too many to manage or require scripts or
proprietary methods as bind's $GENERATE.
This document updates RFCs 2308, 4033, 4034 and 4035.
"Virtual multi-instancing for link state protocols", Shraddha Hegde,
Salih, Mannan Venkatesan, Ross Callon, Alia Atlas, 2016-03-21,
<draft-hegde-rtgwg-virtual-multi-instance-01.txt,.pdf>
In networks with routers of different capabilities, some routers may
not be able to participate fully in supporting new features or
handling large databases and the associated flooding. In some cases,
these restrictions can cause severe scalability issues for the
network in general. This document proposes virtual multi-instances,
a generic mechanism for OSPF and IS-IS, that allows groups of routers
in specific topologies to have a reduced database and reduces the
topology changes that are seen. The virtual multi-instances are
specified so that no software or protocol changes are required in the
restricted routers. Due to the potential number of virtual multiinstances in a network, the configuration is limited and is not
specified per virtual instance.
"Implications of Randomized Link Layers Addresses for IPv6 Address
Assignment", Christian Huitema, 2016-03-02,
<draft-huitema-6man-random-addresses-03.txt>
Hosts may assign random link-layer addresses to network interfaces in
an attempt to increase privacy and reduce trackability. Careless
assignment of IPv6 addresses may negate the privacy advantages of
random link-layer addresses. We propose simple solutions to ensure
that IPv6 addresses do change whenever the link layer addresses
change.
"Operational Implications of IPv6 Packets with Extension Headers",
Fernando Gont, Nick Hilliard, Gert Doering, Shucheng LIU, Warren Kumari,
2016-03-11, <draft-gont-v6ops-ipv6-ehs-packet-drops-03.txt>
This document summarizes the security and operational implications of
IPv6 extension headers, and attempts to analyze reasons why packets
with IPv6 extension headers may be dropped in the public Internet.
"Yang Data Model for Generic Routing Encapsulation (GRE)", Lianshu
Zheng, Carlos Pignataro, Reinaldo Penno, Zishun Wang, 2016-01-20,
<draft-zheng-intarea-gre-yang-01.txt>
This document defines a YANG data model that can be used to configure
and manage Generic Routing Encapsulation (GRE).
"DHCP Options for Network-Assisted Multipath TCP (MPTCP)", Mohamed
Boucadair, Christian Jacquenet, Tirumaleswar Reddy, 2015-11-17,
<draft-boucadair-mptcp-dhc-04.txt>
One of the promising deployment scenarios for Multipath TCP (MPTCP)
is to enable a Customer Premises Equipment (CPE) that is connected to
multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its

network attachments. Because of the lack of MPTCP support at the

server side, some service providers consider a network-assisted model
that relies upon the activation of a dedicated function called: MPTCP
Concentrator.
This document focuses on the explicit deployment scheme where the
identity of the MPTCP Concentrator(s) is explicitly configured on
connected hosts. This document specifies DHCP (IPv4 and IPv6)
options to configure hosts with Multipath TCP (MPTCP) parameters.
"Information Model for Abstraction and Control of TE Networks (ACTN)",
Young Lee, Sergio Belotti, Daniele Ceccarelli, Bin-Yeong Yoon,
2016-03-09, <draft-leebelotti-teas-actn-info-02.txt>
This draft provides an information model for abstraction and control
of Traffic Engineered (TE) networks (ACTN).
"RFC 4960 Errata and Issues", Randall Stewart, Michael Tuexen, Karen E.
E. Nielsen, Maksim Proshin, 2016-03-18,
<draft-tuexen-tsvwg-rfc4960-errata-02.txt>
This document is a compilation of issues found since the publication
of RFC4960 in September 2007 based on experience with implementing,
testing, and using SCTP along with the suggested fixes. This
document provides deltas to RFC4960 and is organized in a time based
way. The issues are listed in the order they were brought up.
Because some text is changed several times the last delta in the text
is the one which should be applied. In addition to the delta a
description of the problem and the details of the solution are also
provided.
"Extensions to PCEP for Temporal LSP", Huaimo Chen, Xufeng Liu, Mehmet
Toy, Vic Liu, Lei Liu, Khuzema Pithewan, 2016-03-18,
<draft-chen-pce-tts-03.txt>
For existing MPLS LSP tunnel services, it is hard for LSP tunnels to
be booked in advance. In addition, once an LSP tunnel is set up, it
is assumed to consume a certain amount of resources such as link
bandwidth forever.
Temporal LSP tunnel services (TTS) provides an easy way for us to
book temporal LSP tunnels in advance. More importantly, a temporal
LSP is an LSP with one or more time intervals and it is assumed to
consume the resources and carry traffic only in these time intervals.
This document specifies extensions to PCEP for computing a path for a
temporal LSP, initiating and maintaining a temporal LSP with a
sequence of time intervals, during each of which the LSP carries
traffic.
"An IPv6 Extension Header for Service Function Chaining (SFC)",
Christian Jacquenet, Mohamed Boucadair, 2016-01-07,
<draft-jacquenet-sfc-ipv6-eh-01.txt>
This document specifies an IPv6 extension header for Service Function
Chaining (SFC) purposes. This extension header is used by SFC data
plane elements to make forwarding decisions in an IPv6-enabled SFC
domain and it conveys metadata that are processed by SFC-aware nodes.
This extension is intended to be used within a single administrative

domain.
"Guidelines for Translation of UML Information Model to YANG Data
Model", Scott Mansfield, Bernd Zeuner, Nigel Davis, Xiang Yun, Yuji
Tochio, Hing-Kam Lam, Eve Varma, 2016-03-18,
<draft-mansfield-netmod-uml-to-yang-02.txt,.pdf>
This document defines guidelines for translation of data modeled with
UML to YANG including mapping of object classes, attributes, data
types, associations, interfaces, operations and operation parameters,
notifications, and lifecycle.
"Use Cases for a Substrate Protocol for User Datagrams (SPUD)", Mirja
Khlewind, Brian Trammell, 2016-03-18,
<draft-kuehlewind-spud-use-cases-01.txt>
This document identifies use cases for explicit cooperation between
endpoints and middleboxes in the Internet under endpoint control.
These use cases range from relatively low level applications
(improving the ability for UDP-based protocols to traverse firewalls)
through support for new transport services (in-flow prioritization
for graceful in-network degradation of media streams). They are
intended to provide background for deriving the requirements for a
Substrate Protocol for User Datagrams (SPUD), as discussed at the IAB
Stack Evolution in a Middlebox Internet (SEMI) workshop in January
2015 and the SPUD BoF session at IETF 92 in March 2015.
"VNF Pool Orchestration For Automated Resiliency in Service Chains",
Giacomo Bernini, Giada Landi, Diego Lopez, Pedro Aranda, 2016-04-03,
<draft-bernini-nfvrg-vnf-orchestration-02.txt>
Network Function Virtualisation (NFV) aims at evolving the way
network operators design, deploy and provision their networks by
leveraging on standard IT virtualisation technologies to move and
consolidate a wide range of network functions and services onto
industry standard high volume servers, switches and storage. The
primary area of impact for operators is the network edge, being
stimulated by the recent updates on NFV and SDN. In fact, operators
are looking at their future datacentres and Points of Presence (PoPs)
as increasingly dynamic infrastructures to deploy Virtualised Network
Functions (VNFs) and on-demand chained services with high elasticity.
This document presents an orchestration framework for automated
deployment of highly available VNF chains. Resiliency of VNFs and
chained services is a key requirement for operators to improve, ease,
automate and speed up services lifecycle management. The proposed
VNFs orchestration framework is also positioned with respect to
current NFV and Service Function Chaining (SFC) architectures and
solutions.
"Benchmarking Virtual Switches in OPNFV", Maryam Tahhan, Billy O'Mahony,
Al Morton, 2016-03-21, <draft-vsperf-bmwg-vswitch-opnfv-02.txt>
This memo describes the progress of the Open Platform for NFV (OPNFV)
project on virtual switch performance "VSWITCHPERF". This project
intends to build on the current and completed work of the
Benchmarking Methodology Working Group in IETF, by referencing
existing literature. The Benchmarking Methodology Working Group has
traditionally conducted laboratory characterization of dedicated
physical implementations of internetworking functions. Therefore,

this memo begins to describe the additional considerations when

virtual switches are implemented in general-purpose hardware. The
expanded tests and benchmarks are also influenced by the OPNFV
mission to support virtualization of the "telco" infrastructure.
"IP/ICMP Translation Algorithm (rfc6145bis)", Congxiao Bao, Xing Li,
Fred Baker, Tore Anderson, Fernando Gont, 2016-04-27,
<draft-bao-v6ops-rfc6145bis-07.txt>
This document describes the Stateless IP/ICMP Translation Algorithm
(SIIT), which translates between IPv4 and IPv6 packet headers
(including ICMP headers). This document obsoletes RFC 6145.
"Constrained Signaling Over LP-WAN", Alexander Pelov, Laurent Toutain,
Yannick Delibie, 2016-02-17, <draft-pelov-core-cosol-01.txt>
This document presents a new type of long-range, low-rate radio
technologies and an extensible mechanism to operate these networks
based on CoAP. The emerging Low-Power Wide-Area Networks (LP-WAN)
present a particular set of constraints, which places them at the
intersection of infrastructure networks, ultra-dense networks, delaytolerant networks and low-power and lossy networks. The main
objectives of LP-WAN signaling is to minimize the number of exchanged
messages, minimize the size of each message in a secure and
extensible manner, all with keeping the fundamental principle of
technology-independence (L2-independence). This document describes
the use of the Constrained Application Protocol (CoAP) as the main
signaling protocol for LP-WAN, over which minimal messages are
exchanged allowing the full operation of the network, such as
authentication, authorization, and management. The use of CoAP
signaling provides a generic mechanism that can be applied to
different LP-WAN technologies.
"VXLAN DCI Using EVPN", Sami Boutros, Ali Sajassi, Samer Salam, Dennis
Cai, Samir Thoria, Tapraj Singh, John Drake, Jeff Tantsura, 2016-03-16,
<draft-boutros-bess-vxlan-evpn-01.txt>
This document describes how Ethernet VPN (E-VPN) technology can be
used to interconnect VXLAN or NVGRE networks over an MPLS/IP network.
This is to provide intra-subnet connectivity at Layer 2 and controlplane separation among the interconnected VXLAN or NVGRE networks.
The scope of the learning of host MAC addresses in VXLAN or NVGRE
network is limited to data plane learning in this document.
"CERNET deployment of IVI/MAP-T in an IPv6-only network", Xing Li,
Congxiao Bao, Guoliang Han, Maojia Sheng, 2016-01-03,
<draft-xli-v6ops-cernet-deployment-01.txt>
This document presents the China Education and Research Network
(CERNET)'s IPv4 as a Service (IPv4aaS) design, deployment and
operation experience.
The techniques used are IPv4/IPv6 stateless translation both in the
forms of single translation (IVI, for IPv6-only servers) and double
translation (MAP-T, for dual-stack clients).
"Refresh Interval Independent FRR Facility Protection", Chandra R, Ina
Minei, Dante Pacella, Tarek Saad, 2016-05-07,
<draft-chandra-mpls-ri-rsvp-frr-04.txt>

RSVP-TE relies on periodic refresh of RSVP messages to synchronize

and maintain the LSP related states along the reserved path. In the
absence of refresh messages, the LSP related states are
automatically deleted. Reliance on periodic refreshes and refresh
timeouts are problematic from the scalability point of view. The
number of RSVP-TE LSPs that a router needs to maintain has been
growing in service provider networks and the implementations should
be capable of handling increase in LSP scale.
RFC 2961 specifies mechanisms to eliminate the reliance on periodic
refresh and refresh timeout of RSVP messages, and enables a router
to increase the message refresh interval to values much larger than
the default 30 seconds defined in RFC 2205. However, the protocol
extensions defined in RFC 4090 for supporting fast reroute (FRR)
using bypass tunnels implicitly rely on short refresh timeouts to
cleanup stale states.
In order to eliminate the reliance on refresh timeouts, the routers
should unambiguously determine when a particular LSP state should be
deleted. Coupling LSP state with the corresponding RSVP-TE signaling
adjacencies as recommended in RSVP-TE Scaling Recommendations
(draft-ietf-teas-rsvp-te-scaling-rec) will apply in scenarios other
than RFC 4090 FRR using bypass tunnels. In scenarios involving RFC
4090 FRR using bypass tunnels, additional explicit tear down
messages are necessary. Refresh-interval Independent RSVP FRR (RIRSVP-FRR) extensions specified in this document consists of
procedures to enable LSP state cleanup that are essential in
scenarios not covered by procedures defined in RSVP-TE Scaling
Recommendations.
"Yang Data Model for Unified Tunnel", Zhenbin Li, Xia Chen, 2015-12-16,
<draft-li-rtgwg-utunnel-yang-01.txt>
This document defines a YANG data model for the unified tunnel. The
data model includes the operational state of tunnels.
"Advanced Resource Directory Features", Akbar Rahman, Chonggang Wang,
2016-03-18, <draft-rahman-core-advanced-rd-features-02.txt>
The Resource Directory (RD) is a key element for successful
deployments of constrained networks. Similar to the HTTP web search
engines (e.g. Google, Bing), the RD for CoAP should also support
useful search query responses beyond a basic listing of relevant
links. This document proposes several new features to be considered
for the RD. The only goal of this document is to trigger discussion
in the CoRE WG so that all relevant features for RD evolution are
taken into account during CoRE re-charter activities.
"IPv6 Service function Chain", Cui Wang, Wei Meng, 2016-01-06,
<draft-wang-6man-ipv6-service-function-chain-01.txt>
Service function chain is the definition of an ordered set of service
functions. After instantiated, the service function path is created
and the classified traffic is steered through the corresponding
service function path and then forwarded to the final destination.
This document tries to describe how to use IPv6 data plane and IPv6
extension headers to realize service function chain in IPv6 network.
"Multicast Anchoring in DMM", gomjae@dcn.ssu.ac.kr, Young-Han Kim,
2016-04-14, <draft-kjsun-dmm-multicast-anchoring-02.txt>

In this draft, we define multicast support functions in a

Distributed Mobility Management (DMM) environment. Based on the
decomposed mobility management functions in [RFC7429], each defined
multicast support function can be located and operated with DMM
functions.
"YANG Data Model for BIER Protocol", Ran Chen, fangwei hu, Zheng Zhang,
dai.xianxian@zte.com.cn, Mahesh Sivakumar, 2016-03-18,
<draft-chh-bier-bier-yang-03.txt>
This document defines a YANG data model for BIER configuration and
operation.
"Optimal Ate Pairing", Akihiro Kato, Michael Scott, Tetsutaro Kobayashi,
Yuto Kawahara, 2016-03-24, <draft-kato-optimal-ate-pairings-01.txt>
Pairing is a special map from two elliptic curve that called Pairingfriend curves to a finite field and is useful mathematical tools for
constructing cryptographic primitives. It allows us to construct
powerful primitives. (e.g. [3] and [4])
There are some types of pairing and its choice has an impact on the
performance of the primitive. For example, Tate Pairing [3] and Ate
Pairing [4] are specified in IETF. This memo focuses on Optimal Ate
Pairing [2] which is an improvement of Ate Pairing.
This memo defines Optimal Ate Pairing for any pairing-friendly curve.
We can obtain concrete algorithm by deciding parameters and building
blocks based on the form of a curve and the description in this memo.
It enables us to reduce the cost for specifying Optimal Ate Pairing
over additional curves. Furthermore, this memo provides concrete
algorithm for Optimal Ate Pairing over BN-curves [7] and its test
vectors.
"FSU Key Exchange", Akihiro Kato, Thomas Hardjono, Tetsutaro Kobayashi,
Tsunekazu Saito, Koutarou Suzuki, 2016-04-25,
<draft-kato-fsu-key-exchange-01.txt>
This draft proposes an identity-based authenticated key exchange
protocol following the extended Canetti-Krawczyk (id-eCK) model. The
protocol is currently the most efficient among the id-eCK protocols.
"MAP-T Trail in ChinaTelecom", Chongfeng Xie, Chen Li, Congxiao Bao,
Guoliang Han, Xing Li, 2016-01-03,
<draft-xcf-v6ops-chinatelecom-deployment-01.txt>
With the depletion of the IPv4 address space, large-scale SPs are now
faced with the real option to deploy IPv6 in a timely manner. In
order to achieve smooth transition to IPv6, migration tools should be
introduced for different deployment models. Among different IPv6
transition mechanisms, MAP-T is a stateless translation method which
can directly translate IPv4 packet to IPv6 packet. This document
describes the challenges and requirements for large SP to deploy IPv6
in operational network, the experimental results of MAP-T in our
laboratory and the field trials in large SP operational network.
"GRE Tunnel Bonding", Nicolai Leymann, Cornelius Heidemann, Mingui
Zhang, Behcet Sarikaya, Margaret Cullen, 2016-05-05,
<draft-zhang-gre-tunnel-bonding-02.txt>

There is an emerging demand for solutions that provide redundancy and

load-sharing across wired and cellular links from a single service
provider, so that a single subscriber is provided with hybrid access
to multiple heterogeneous connections at the same time.
In this document, GRE (Generic Routing Encapsulation) Tunnel Bonding
is specified as an enabling approach for Hybrid Access to a wired and
a wireless network in customer premises, e.g. homes. In GRE Tunnel
Bonding, two GRE tunnels, one per network connection, are set up and
bonded together to form a single GRE tunnel for a subscriber.
Compared with each composing connection, the bonding connection
promises increased access capacity and improved reliability. The
solution described in this document is currently implemented by
Huawei and deployed by Deutsche Telekom AG.
"Autonomic Functions Coordination", Laurent Ciavaglia, Pierre Peloso,
2016-03-21, <draft-ciavaglia-anima-coordination-01.txt,.pdf>
This document describes a management solution capable of avoiding
conflicts between autonomic functions. The objective of such a
solution is to avoid network instabilities, by insuring that the
autonomic functions pursuing different goals will cooperate instead
of antagonize each other. This document provides both requirements
and specifications for such a solution.
"Updates on EVPN BUM Procedures", Jeffrey Zhang, Wen Lin, Jorge Rabadan,
Keyur Patel, 2016-04-21,
<draft-zzhang-bess-evpn-bum-procedure-updates-03.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.
"Dynamic IPv4 Provisioning for Lightweight 4over6", Cong Liu, Qi Sun,
Jianping Wu, Ian Farrer, 2016-03-21,
<draft-liu-softwire-lw4over6-dynamic-provisioning-01.txt>
Lightweight 4over6 [RFC7596] is an IPv4 over IPv6 hub-and-spoke
mechanism that provides overlay IPv4 services in an IPv6-only access
network. It uses a deterministic, DHCPv6 based method for the
provisioning of IPv4 addresses and port sets to customer CE devices.
This document describes how existing specifications can be used for
the dynamic IPv4 provisioning of Lightweight 4over6, based on DHCPv4
over DHCPv6 [RFC7341].
"YANG Data Model for SAVI", Wei Meng, Cui Wang, 2015-12-25,
<draft-meng-savi-yang-01.txt>
This document defines a YANG data model for SAVI.
"Firewall Traversal for WebRTC", Pradeep Patel, Cullen Jennings, Suhas
Nandakumar, Jonathan Rosenberg, Dan Wing, 2016-03-20,
<draft-jennings-behave-rtcweb-firewall-04.txt>
Traversal of RTP through corporate firewalls has traditionally been
complex, requiring the deployment of Session Border Controllers
(SBCs) or wide open pinholes. This draft proposes a simple technique
that allows WebRTC based RTP traffic to traverse firewalls without
complex firewall configuration and without deployment of SBCs or

other middleboxes.
"Network Device YANG Organizational Models", Acee Lindem, Lou Berger,
Dean Bogdanovic, Christian Hopps, 2016-02-23,
<draft-rtgyangdt-rtgwg-device-model-03.txt>
This document presents an approach for organizing YANG models in a
comprehensive structure that may be used to configure and operate
network devices. The structure is itself represented as a YANG
model, with all of the related component models logically organized
in a way that is operationally intuitive, but this model is not
expected to be implemented. The identified component modules are
expected to be defined and implemented on common network devices.
This document also defines two modules that can be used to model the
logical and virtual resource representations that may be present on a
network device. Examples of common industry terms for logical
resource representations are Logical Systems or Routers. Examples of
of common industry terms for virtual resource representations are
Virtual Routing and Forwarding (VRF) instances and Virtual Switch
Instances (VSIs).
This document is derived from work submitted to the IETF by members
of the informal OpenConfig working group of network operators and is
a product of the Routing Area YANG Architecture design team.
"Delay Tolerant Network (DTN) Numeric Node IDs", Fred Templin, Scott
Burleigh, 2016-04-06, <draft-templin-dtn-numid-01.txt>
The Delay Tolerant Network (DTN) Bundle Protocol (BP) uses Uniform
Resource Identifiers (URIs) as the basis for Endpoint and Node IDs.
IDs that are encoded as alphanumeric strings can consume excessive
precious bandwidth over constrained links, leading to a desire for a
short numeric ID format. This document discusses alternatives for a
DTN numeric node ID format.
"Anycast Segments in MPLS based Segment Routing", P. Sarkar, Hannes
Gredler, Clarence Filsfils, Stefano Previdi, Bruno Decraene, Martin
Horneffer, 2016-04-12,
<draft-psarkar-spring-mpls-anycast-segments-02.txt,.pdf>
Instead of forwarding to a specific device or to all devices in a
group, anycast addresses, let network devices forward a packet to (or
steer it through) one or more topologically nearest devices in a
specific group of network devices. The use of anycast addresses has
been extended to the Segment Routing (SR) network, wherein a group of
SR-capable devices can represent a anycast address, by having the
same Segment Routing Global Block (SRGB) provisioned on all the
devices and each one of them advertising the same anycast prefix
segment (or Anycast SID).
This document describes a proposal for implementing anycast prefix
segments in a MPLS-based SR network, without the need to have the
same SRGB block (label ranges) provisioned across all the member
devices in the group. Each node can be provisioned with a separate
SRGB from the label range supported by the specfic hardware platform.
"Address Protected Neighbor Discovery for Low-power and Lossy Networks",
Behcet Sarikaya, Pascal Thubert, 2016-03-10,
<draft-sarikaya-6lo-ap-nd-02.txt>

This document defines an extension of 6LoWPAN Neighbor Discovery for

application in low-power and lossy networks. The protocol is
specified to be protected and to support multi-hop operation. A node
computes its Cryptographic, Unique Interface ID, and associates one
or more of its Registered Addresses with that Cryptographic ID in
place of the EUI-64 that is used in RFC 6775 to uniquely identify the
interface of the Registered Address. Once an address is registered
with a Cryptographic ID, only the owner of that ID can modify the
state in the 6LR and 6LBR regarding the Registered Address.
"Interface VLAN YANG Data Models", Robert Wilton, David Ball, Tapraj
Singh, Selvakumar Sivaraj, 2016-04-21,
<draft-wilton-netmod-intf-vlan-yang-02.txt>
This document defines YANG models to add support for classifying
traffic received on interfaces as Ethernet/VLAN framed packets to
sub-interfaces based on the fields available in the Ethernet/VLAN
frame headers. Primarily the classification is based on VLAN
identifiers in the 802.1Q VLAN tags, but the model also has support
for matching on some other layer 2 frame header fields and is
designed to be easily extensible to match on other arbitrary header
fields.
The model differs from an IEEE 802.1Q bridge model in that the
configuration is interface/sub-interface based as opposed to being
based on membership of a 802.1Q VLAN bridge.
"Security for Low-Latency Group Communication", Abhinav Somaraju,
Sandeep Kumar, Hannes Tschofenig, Walter Werner, 2016-01-15,
<draft-somaraju-ace-multicast-01.txt>
Some Internet of Things application domains, such as lighting, have
strict requirements on latency for group communication. From a user
experience point of view latency less than 200 ms is necessary from
an action triggered by a user to the visible effects. This draft
describes procedures for authorization, key management, and securing
group messages within a low latency application domain with a special
emphasis on lighting systems. We specify the usage of object
security at the application layer for group communication and assume
that CoAP is used as the application layer protocol.
"An Opportunistic Approach for Secure Real-time Transport Protocol
(OSRTP)", Alan Johnston, Bernard Aboba, Andrew Hutton, Laura Liess,
Thomas, 2016-02-29, <draft-johnston-dispatch-osrtp-02.txt>
Opportunistic Secure Real-time Transport Protocol (OSRTP) allows
encrypted media to be used in environments where support for
encryption is not known in advance, and not required. OSRTP is an
implementation of Opportunistic Security, as defined in RFC 7435.
OSRTP does not require advanced SDP extensions or features and is
fully backwards compatible with existing secure and insecure
implementations. OSRTP is not specific to any key management
technique for SRTP. OSRTP is a transitional approach useful for
migrating existing deployments of real-time communications to a fully
encrypted and authenticated state.
"Two-Way Active Measurement Protocol (TWAMP) Light Data Model", Greg
Mirsky, Tamas Elteto, 2016-03-07,
<draft-mirsky-ippm-twamp-light-yang-02.txt>

This document specifies the data model for implementations of

Session-Sender and Session-Reflector for Two-Way Active Measurement
Protocol (TWAMP) Light mode using YANG.
"IS-IS LSP lifetime corruption - Problem Statement", Bruno Decraene,
Christof Schmitz, 2016-01-12,
<draft-decraene-isis-lsp-lifetime-problem-statement-01.txt>
The IS-IS protocol exchanges Link State Packet (LSP) to exchange
routing information. The lifetime of this LSP is located in the LSP
header and is neither protected from corruption by the Fletcher
checksum nor by cryptographic authentication. So the LSP lifetime
may be altered, either accidentally or maliciously any time.
The lifetime field of the LSP is an important field for the correct
operation of IS-IS. Corruption of this LSP lifetime may cause
flooding storm with severe impact in the network.
This draft documents the problem statement and calls for a solution.
"A Solution Framework for Private Media in Privacy Enhanced RTP
Conferencing", Paul Jones, David Benham, 2016-03-21,
<draft-jones-perc-private-media-framework-02.txt>
This document describes a solution framework for ensuring that media
confidentiality and integrity are maintained end-to-end within the
context of a switched conferencing environment where media
distribution devices are not trusted with the end-to-end media
encryption keys. The solution aims to build upon existing security
mechanisms defined for the real-time transport protocol (RTP).
"LISP support for Multi-Tuple EIDs", Alberto Rodriguez-Natal, Albert
Cabellos-Aparicio, Sharon Barkai, Vina Ermagan, Darrel Lewis, Fabio
Maino, Dino Farinacci, 2016-01-07,
<draft-rodrigueznatal-lisp-multi-tuple-eids-01.txt>
This document describes extensions for LISP to support EIDs based on
tuples of multiple elements.
"Thor Video Codec", Arild Fuldseth, Gisle Bjontegaard, S. Midtskogen,
Thomas Davies, Mo Zanaty, 2016-03-18, <draft-fuldseth-netvc-thor-02.txt>
This document provides a high-level description of the Thor video
codec. Thor is designed to achieve high compression efficiency with
moderate complexity, using the well-known hybrid video coding
approach of motion-compensated prediction and transform coding.
"SACM ECP Mapping", Chris Coffin, Daniel Haynes, Charles Schmidt,
Jessica Fitzgerald-McKay, 2016-01-05,
<draft-haynes-sacm-ecp-mapping-01.txt,.pdf>
This document builds upon
[I-D.fitzgeraldmckay-sacm-endpointcompliance] to demonstrate how
published IETF, ISO, and TCG standards, available today, can be used
to accomplish the use cases outlined in [RFC7632].
"Requirements for the design of a Substrate Protocol for User Datagrams
(SPUD)", Brian Trammell, Mirja Khlewind, 2016-04-29,
<draft-trammell-spud-req-03.txt>

We have identified the potential need for a UDP-based encapsulation

protocol to allow explicit cooperation with middleboxes while using
new, encrypted transport protocols. This document proposes an
initial set of requirements for such a protocol, and discusses
tradeoffs to be made in further refining these requirements.
"Support for Notifications in CCN", Ravi Ravindran, Asit Chakraborti,
Syed Amin, marc.mosko@parc.com, Ignacio Solis, 2016-03-21,
<draft-ravi-ccn-notification-01.txt>
This draft proposes a new packet primitive called Notification for
CCN. Notification is a PUSH primitive and can be unicast or
multicast to multiple listening points. Notifications do not expect
a Content Object response hence only requires the use of FIB state in
the CCN forwarder. Emulating Notification as a PULL has performance
and forwarding implications. The draft proposes a new fixed header
primitive called Notification and a CCN message encoding using
Content Object primitive to transport Notifications. These
discussions are presented in the context of CCNx1.0 [1] proposal.
"LISP Map Server Reliable Transport", Christian Cassar, Isidor Kouvelas,
Darrel Lewis, Jesus Arango, Johnson Leong, 2016-02-19,
<draft-kouvelas-lisp-map-server-reliable-transport-01.txt>
The communication between LISP ETRs and Map-Servers is based on
unreliable UDP message exchange coupled with periodic message
transmission in order to maintain soft state. The drawback of
periodic messaging is the constant load imposed on both the ETR and
the Map-Server. New use cases for LISP have increased the amount of
state that needs to be communicated with requirements that are not
satisfied by the current mechanism. This document introduces the use
of a reliable transport for ETR to Map-Server communication in order
to eliminate the periodic messaging overhead, while providing
reliability, flow-control and endpoint liveness detection.
This document has been renamed to avoid ambiguity. It is an update
to [I-D.kouvelas-lisp-reliable-transport].
"IS-IS Point-to-Multipoint operation", C. Franke, David Lamparter,
Christian Hopps, 2016-04-17, <draft-lamparter-isis-p2mp-02.txt>
This document describes a new mode operation for IS-IS. In addition
to the existing LAN and point-to-point modes of operation, a pointto-multipoint mode is defined. This mode is useful for operation
both on networks with more than two routers where multicast is
expensive in comparison to unicast, as well on networks where
creating a LAN pseudonode cannot adequately reflect metrics.
"ALTO Extension: A Routing State Abstraction Service Using Declarative
Equivalence", Kai Gao, xinwang2014@hotmail.com, Yang Yang, G.Robert
Chen, 2016-04-26, <draft-gao-alto-routing-state-abstraction-02.txt>
The Application-Layer Traffic Optimization (ALTO) protocol has
defined multiple services (e.g., network maps, cost maps, filtered
maps, the endpoint cost service, and the endpoint property service)
to provide network state information to network applications. In a
higher-level view, both the cost maps and the endpoint cost service
can be considered as providing views into the routing state of a
network (i.e., the path properties). A drawback of these existing

services, however, is that they are static, application-oblivious

views, without guidance from network applications. This document
designs a new ALTO service named Routing State Abstraction using
Declarative Equivalence (RSADE). Allowing applications to provide
declarative guidance on the intended use of the network routing
state, RSADE allows a network to compute compact, customized routing
state abstraction beyond the existing services.
"Deployment Models for Distributed Mobility Management", Seil Jeon,
Young-Han Kim, 2016-03-21, <draft-sijeon-dmm-deployment-models-02.txt>
This document presents available deployment models for distributed
mobility management networks, consisted of mobility management
functions: anchoring function, location management, and forwarding
management functions defined in RFC7429. Some of the functions are
modified on a need to allow potential deployment scenarios support.
"Signaling Maximum SID Depth using Border Gateway Protocol Link-State",
Jeff Tantsura, Greg Mirsky, Siva Sivabalan, Uma Chunduri, 2016-01-11,
<draft-tantsura-bgp-ls-segment-routing-msd-02.txt>
This document discusses use of BGP-LS to expose node and/or link on a
node MSD "Maximum SID Depth" to a centralized controller (PCE/SDN).
"HTTPS and delegation of encrypted traffic between interconnected CDNs",
Frederic Fieau, 2016-03-21,
<draft-fieau-https-delivery-delegation-02.txt>
This document discusses approaches to the issue of correct delegation
of the encrypted TLS-based traffic requests between CDNs in inter CDN
networks and during interactions between client User Agents (UA), and
Content Delivery Networks (CDNs).
"A Yang model for I2RS service topology", Susan Hares, Linda Dunbar,
2016-02-12, <draft-hares-i2rs-service-topo-dm-06.txt,.pdf>
This document defines I2RS protocol-independent service layer virtual
topology data model. This data model utilizes the concepts in the
generic I2RS topology model of virtual networks (node, links,
termination points) and cross-layer topologies. This virtual service
topology may be a composite layer created from the combination of
protocol-dependent service layers. Protocol-dependent services
layers include: L3VPN, L2VPN, EVPN, E-Tree, and others.
"Analysis of the SFC scalability", Ting Ao, 2016-03-21,
<draft-ao-sfc-scalability-analysis-01.txt>
SFC as a chain of a set of service function, should be scalable to
meet all kinds of requirements. The scalability of SFC means the SFC
could be elastic to accomodate one or more SFs join the SFC , or
leave the SFC. The document presents four cases for the scalability
of SFC, and analysis the data plane and the control plane to
implement the scalable SFC.
"PIM DR Improvement", Zheng Zhang, fangwei hu, BenChong Xu, 2016-01-21,
<draft-zhang-pim-dr-improvement-01.txt>
PIM is worldly deployed multicast protocol. This document will
improve the stability of PIM protocol, decrease the lost of multicast
packets when the PIM DR (Designed Router) is down.

"Interconnecting Millions Of Endpoints With Segment Routing", Clarence

Filsfils, Dennis Cai, Stefano Previdi, Wim Henderickx, Rob Shakir, Dave
Cooper, Francis Ferguson, Steven Lin, Tim Laberge, Bruno Decraene, Luay
Jalil, Jeff Tantsura, 2016-04-04,
<draft-filsfils-spring-large-scale-interconnect-02.txt>
This document describes an application of Segment Routing to scale
the network to support hundreds of thousands of network nodes, and
tens of millions of physical underlay endpoints. This use-case can be
applied to the interconnection of massive-scale DC's and/or large
aggregation networks. Forwarding tables of midpoint and leaf nodes
only require a few tens of thousands of entries.
"Ethernet MAC Chaining", P. Bottorff, don.fedyk@hpe.com, Hamid
Assarpour, 2016-01-20, <draft-fedyk-sfc-mac-chain-01.txt>
This document introduces and describes a simple and highly scalable
service function chaining mechanism called MAC chaining which is
built largely on existing Ethernet frame and forwarding capabilities.
MAC chaining uses IEEE 802 Media Access Control (MAC) addresses to
provide flexible and complete service function chains. It is largely
transparent to layers above Ethernet and designed to augment and
coexist with existing virtual and physical network forwarding. MAC
chaining is achievable in some devices and virtual switches today
using existing protocols.
"Transport Options for UDP", Joseph Touch, 2016-01-19,
<draft-touch-tsvwg-udp-options-02.txt>
Transport protocols are extended through the use of transport header
options. This document experimentally extends UDP to provide a
location, syntax, and semantics for transport layer options.
"Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer Security
(TLS) version 1.2", John Schanck, William Whyte, Zhenfei Zhang,
2016-01-20, <draft-whyte-qsh-tls12-01.txt>
This document describes the Quantum-Safe Hybrid ciphersuite, a new
cipher suite providing modular design for quantum-safe cryptography
to be adopted in the handshake for the Transport Layer Security (TLS)
protocol version 1.2. In particular, it specifies the use of the
NTRUEncrypt encryption scheme in a TLS handshake.
"Quantum-Safe Hybrid (QSH) Ciphersuite for Transport Layer Security
(TLS) version 1.3", John Schanck, William Whyte, Zhenfei Zhang,
2016-04-04, <draft-whyte-qsh-tls13-02.txt>
This document describes the Quantum-Safe Hybrid ciphersuite, a new
cipher suite providing modular design for quantum-safe cryptography
to be adopted in the handshake for the Transport Layer Security (TLS)
protocol version 1.3. In particular, it specifies the use of the
NTRUEncrypt encryption scheme in a TLS handshake.
"Homenet IS-IS Profile", David Lamparter, 2016-04-17,
<draft-lamparter-homenet-isis-profile-02.txt>
This (pointer) document describes the neccessary bits and pieces of
IS-IS that a homenet targeted implementation would need to implement.

"Applicability of SUPA", Narasimha Vadrevu, Dacheng Zhang, Alibaba

Group, Ying Cheng, 2016-03-17, <draft-vadrevu-supa-applicability-06.txt>
SUPA will define a generic policy model, an imperative ECA (Event
Condition Action) policy information model and a declarative (intentbased) policy information model which is the extension of the generic
model, and a set of policy data models which will make use of the
common concepts defined in the generic model. This memo will explore
some typical use cases and demonstrate the applicability of SUPA
policy models.
"OSPFv2 Link Traffic Engineering (TE) Attribute Reuse", Peter Psenak,
Acee Lindem, Wim Henderickx, Jeff Tantsura, Hannes Gredler, 2016-01-22,
<draft-ppsenak-ospf-te-link-attr-reuse-01.txt>
Various link attributes have been defined in OSPFv2 in the context of
the MPLS Traffic Engineering (TE) and GMPLS. Many of these link
attributes can be used for purposes other than MPLS Traffic
Engineering or GMPLS. This documents defines how to distribute such
attributes in OSPFv2 for applications other than MPLS Traffic
Engineering or GMPLS purposes.
"RPKI Deployment Considerations: Problem Analysis and Alternative
Solutions", XiaoDong Lee, Xiaowei Liu, Zhiwei Yan, Guanggang Geng, Yu
Fu, 2016-01-28, <draft-lee-sidr-rpki-deployment-01.txt>
With the global deployment of RPKI, a lot of concerns about technical
problems have been and will be raised. In this draft, we collect and
analyze the problems that have appeared or that seem likely to appear
during the process of RPKI deployment, and suggest some solutions to
address or mitigate these problems.
"Alternative Challenge Password Attributes for Enrollment over Secure
Transport", Max Pritikin, Carl Wallace, 2016-04-13,
<draft-wallace-est-alt-challenge-08.txt>
This document defines a set of new Certificate Signing Request
attributes for use with the Enrollment over Secure Transport (EST)
protocol. These attributes provide disambiguation of the existing
overloaded uses for the challengePassword attribute defined in PKCS
(Public-Key Cryptography Standards) #9 (RFC2985). Uses include the
original certificate revocation password, common authentication
password uses, and EST-defined linking of transport security
identity.
"The Sunset HTTP Header", Erik Wilde, 2016-02-03,
<draft-wilde-sunset-header-01.txt>
This specification defines the Sunset HTTP response header field,
which indicates that a URI is likely to become unresponsive at a
specified point in the future.
Note to Readers
This draft should be discussed on the apps-discuss mailing list [1].
Online access to all versions and files is available on GitHub [2].
"IP Options and IPv6 Updates for IPPM's Active Metric Framework: Packets
of Type-P and Standard-Formed Packets", Al Morton, Joachim Fabini,

Nalini Elkins, mackermann@bcbsm.com, Vinayak Hegde, 2015-12-11,

<draft-morton-ippm-2330-stdform-typep-02.txt>
This memo updates the IP Performance Metrics (IPPM) Framework RFC
2330 with new considerations for measurement methodology and testing.
The memo updates the definition of standard-formed packets in RFC
2330 to include IPv6 packets. It also augments distinguishing
aspects of packets, referred to as Type-P for test packets in RFC
2330.
Two points (at least) are worthwhile discussing further: extent of
coverage for 6LO and IPv6 Header Compression, and the continued need
to define a "minimal standard-formed packet".
"YANG Data Models for the Port Control Protocol (PCP)", Mohamed
Boucadair, Christian Jacquenet, Senthil Sivakumar, Suresh Vinapamula,
2015-12-09, <draft-boucadair-pcp-yang-01.txt>
This document defines YANG data models for the Port Control Protocol
(PCP).
"DualQ Coupled AQM for Low Latency, Low Loss and Scalable Throughput",
Koen De Schepper, Bob Briscoe, Olga Bondarenko, I J Tsang, 2016-03-21,
<draft-briscoe-aqm-dualq-coupled-01.txt>
Data Centre TCP (DCTCP) was designed to provide predictably low
queuing latency, near-zero loss, and throughput scalability using
explicit congestion notification (ECN) and an extremely simple
marking behaviour on switches. However, DCTCP does not co-exist with
existing TCP traffic---throughput starves. So, until now, DCTCP
could only be deployed where a clean-slate environment could be
arranged, such as in private data centres. This specification
defines `DualQ Coupled Active Queue Management (AQM)' to allow
scalable congestion controls like DCTCP to safely co-exist with
classic Internet traffic. The Coupled AQM ensures that a flow runs
at about the same rate whether it uses DCTCP or TCP Reno/Cubic, but
without inspecting transport layer flow identifiers. When tested in
a residential broadband setting, DCTCP achieved sub-millisecond
average queuing delay and zero congestion loss under a wide range of
mixes of DCTCP and `Classic' broadband Internet traffic, without
compromising the performance of the Classic traffic. The solution
also reduces network complexity and eliminates network configuration.
"iPRP: Parallel Redundancy Protocol for IP Networks", Miroslav Popovic,
Maaz Mohiuddin, Jean-Yves Le Boudec, Dan-Cristian Tomozei, 2016-02-01,
<draft-popovic-iprp-01.txt,.pdf>
Reliable packet delivery within stringent delay-constraints is of
paramount importance to mission-critical computer applications with
hard real-time constraints. Because retransmission and coding
techniques counteract the delay requirements, reliability may be
achieved through replication over multiple fail-independent paths.
Existing solutions, such as the parallel redundancy protocol (PRP),
replicate all packets at the MAC layer over parallel paths. PRP works
best in local area networks. However, it is not viable for IP
networks that are a key element of emerging mission-critical systems.
This limitation, coupled with diagnostic inability and lack of
security, renders PRP unsuitable for reliable data-delivery in these
IP networks. To address this issue, we present a transport-layer
solution: the IP parallel redundancy protocol (iPRP). Designing iPRP

poses non-trivial challenges in the form of selective packetreplication, soft-state and multicast support. iPRP replicates only
time-critical unicast or multicast UDP traffic. iPRP requires no
modifications to the existing monitoring application, end-device
operating system or to the intermediate network devices. It only
requires a simple software installation on the end-devices. iPRP has
a set of diagnostic tools for network debugging. With our
implementation of iPRP in Linux, we show that iPRP supports multiple
flows with minimal processing-and-delay overhead. It is being
installed in our campus smart-grid network and is publicly available.
"T.140 Text Conversation over Data Channels", Keith Drage, Juergen
Stoetzer-Bradler, Albrecht Schwarz, 2016-04-04,
<draft-schwarz-mmusic-t140-usage-data-channel-03.txt>
This document specifies how the ITU-T Protocol for multimedia
application text conversation (Recommendation ITU-T T.140) can be
instantiated as a data channel sub-protocol, using the SDP
offer/answer exchange-based external negotiation defined in [ID.ietf-mmusic-data-channel-sdpneg]. Two network configurations are
documented: a WebRTC end-to-end configuration (connecting two T.140
over data channel endpoints), and a gateway configuration
(connecting an T.140 over data channel endpoint with an T.140 over
RTP/UDP endpoint).
"URI Signing for HTTP Adaptive Streaming (HAS)", Ray van Brandenburg,
2016-03-09, <draft-brandenburg-cdni-uri-signing-for-has-02.txt>
This document defines an extension to the URI Signing mechanism
specified in [I-D.ietf-cdni-uri-signing] that allows for URI Signing
of content delivered via HTTP Adaptive Streaming protocols such as
MPEG DASH or HLS.
The proposed mechanism is applicable to both CDNI as well as singleCDN environments.
"RTP Payload Format for VC-2 HQ Profile Video", James Weaver,
2015-12-16, <draft-weaver-payload-rtp-vc2hq-01.txt>
This memo describes an RTP Payload format for the High Quality (HQ)
profile of SMPTE Standard ST 2042-1 known as VC-2. This document
describes the transport of HQ Profile VC-2 in RTP packets and has
applications for low-complexity, high-bandwidth streaming of both
lossless and lossy compressed video.
The HQ profile of VC-2 is intended for low latency video compression
(with latency potentially on the order of lines of video) at high
data rates (with compression ratios on the order of 2:1 or 4:1).
"IPv6 Backbone Router", Pascal Thubert, 2015-11-09,
<draft-thubert-6lo-backbone-router-03.txt>
This specification proposes an update to IPv6 Neighbor Discovery, to
enhance the operation of IPv6 over wireless links that exhibit lossy
multicast support, and enable a large degree of scalability by
splitting the broadcast domains. A higher speed backbone federates
multiple wireless links to form a large MultiLink Subnet. Backbone
Routers acting as Layer-3 Access Point route packets to registered
nodes, where an classical Layer-2 Access Point would bridge.
Conversely, wireless nodes register to the Backbone Router to setup

routing services in a fashion that is essentially similar to a

classical Layer-2 association.
"SMTP Service Extension for Client Identity", William Storey,
2016-02-01, <draft-storey-smtp-client-id-01.txt>
This document defines an extension for the Simple Mail Transfer
Protocol (SMTP) called "CID" to provide a method for clients to
indicate an identity to the server.
This identity is an additional token that may be used for security
and/or informational purposes, and with it a server may optionally
apply heuristics using this token.
"Asynchronous Management Architecture", Edward Birrane, 2016-03-10,
<draft-birrane-dtn-ama-02.txt>
This document describes the motivation, desirable properties, system
model, roles/responsibilities, and component models associated with
an asynchronous management architecture (AMA) suitable for providing
application-level network management services in a challenged
networking environment. Challenged networks are those that require
fault protection, configuration, and performance reporting while
unable to provide human-in-the-loop operations centers with
synchronous feedback in the context of administrative sessions. In
such a context, networks must exhibit behavior that is both
deterministic and autonomous while maintaining compatibility with
existing network management protocols and operational concepts.
"Asynchronous Management Protocol", Edward Birrane, Jeremy Pierce-Mayer,
2016-03-20, <draft-birrane-dtn-amp-02.txt>
This document describes an Asynchronous Management Protocol (AMP)
conformant with an Asynchronous Management Architecture (AMA). The
AMP provides monitoring and configuration services between managing
devices (Managers) and managed devices (Agents), some of which may
operate on the far side of high-delay or high-disruption links. The
AMP minimizes the number of transmitted bytes, operates without
sessions or (concurrent) two-way links, and functions autonomously
when there is no timely contact with a network operator. The AMP
accomplishes this without requiring mobile code and generally reduces
the processor, memory, and storage requirements of implementing
Managers and Agents.
"YANG Data Model for the DS-Lite Address Family Transition Router
(AFTR)", Mohamed Boucadair, Christian Jacquenet, Senthil Sivakumar,
2015-12-16, <draft-boucadair-softwire-dslite-yang-03.txt>
This document defines a YANG data model for the DS-Lite Address
Family Transition Router (AFTR).
"OWE: Opportunistic Wireless Encryption", Warren Kumari, Wesley George,
2016-02-21, <draft-wkumari-owe-02.txt>
This document describes a method to incrementally increase the
security of wireless networks against passive attackers / pervasive
monitors through unauthenticated encryption.
[ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings,

etc. They will be removed before publication.]

[ This document is being collaborated on in Github at:
https://github.com/wkumari/draft-wkumari-owe. The most recent
version of the document, open issues, etc should all be available
here. The authors (gratefully) accept pull requests. ]
"Asynchronous Management Protocol Agent Application Data Model", Edward
Birrane, 2016-03-21, <draft-birrane-dtn-adm-agent-01.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 ADM identifies the Primitive Values, Computed
values, Reports, Controls, Macros, Literals, Operators, and meta-data
associated with an Agent. The information outlined in this document
MUST be supported by any software claiming to act as a managed device
within the AMP.
"A Framework for Defining Network Complexity", Michael Behringer, Alvaro
Retana, Russ White, Geoff Huston, 2016-04-25,
<draft-behringer-ncrg-complexity-framework-02.txt>
Complexity is a widely used parameter in network design, yet there is
no generally accepted definition of the term. Complexity metrics
exist in a wide range of research papers, but most of these address
only a particular aspect of a network, for example the complexity of
a graph or software. While it may be impossible to define a metric
for overall network complexity, there is a desire to better
understand the complexity of a network as a whole, as deployed today
to provide Internet services. This document provides a framework to
guide research on the topic of network complexity, as well as some
practical examples for trade-offs in networking.
This document summarizes the work of the IRTF's Network Complexity
Research Group (NCRG) at the time of its closure. It does not
present final results, but a snapshot of an ongoing activity, as a
basis for future work.
"Scalable DNS-SD (SSD) Threats", Douglas Otis, Hosnieh Rafiee,
2016-03-17, <draft-otis-dnssd-scalable-dns-sd-threats-03.txt>
mDNS combined with Service Discovery (DNS-SD) extends network
resource distribution beyond the reach of multicast normally limited
by the MAC Bridge. Since related resources are often not
authenticated, either local resources are inherently trustworthy or
are subsequently verified by associated services. Resource
distribution becomes complex when a hybrid scheme combines adjacent
network resources into a common unicast DNS-SD structure. This
document explores related security considerations.
"mPlane Protocol Specification", Brian Trammell, Mirja Khlewind,
2016-03-16, <draft-trammell-mplane-protocol-01.txt>
This document defines the mPlane architecture for coordination of
heterogeneous network measurement components: probes and repositories
that measure, analyze, and store network measurements, data derived
from measurements, and other ancillary data about elements of the
network. The architecture is defined in terms of relationships
between components and clients which communicate using the mPlane

protocol defined in this document.

This revision of the document describes Version 2 of the mPlane
protocol.
"Operational State Enhancements for YANG, NETCONF, and RESTCONF", Kent
Watsen, Andy Bierman, Martin Bjorklund, Jrgen Schnwlder, 2016-02-02,
<draft-kwatsen-netmod-opstate-02.txt>
This document presents enhancements to YANG, NETCONF, and RESTCONF
satisfying the requirements set forth in Terminology and Requirements
for Enhanced Handling of Operational State.
"YANG Data Model for Network Address Translation (NAT)", Senthil
Sivakumar, Mohamed Boucadair, Suresh <>, 2016-03-10,
<draft-sivakumar-yang-nat-04.txt>
For the sake of network automation and the need for programming NAT
function in particular, a data model for configuring and managing the
NAT device is essential. This document defines a YANG data model for
the NAT function. Both the NAT44 and NAT64 are covered in this
document.
""With-config-state" Capability for NETCONF/RESTCONF", Robert Wilton,
2015-12-21, <draft-wilton-netmod-opstate-yang-02.txt>
This document proposes a possible alternative solution for handling
applied configuration state in YANG as described in draft-openconfignetmod-opstate-01. The proposed solution, roughly modelled on the
with-defaults NETCONF/RESTCONF capability, aims to meet the key
requirements set out in draft-ietf-netmod-opstate-reqs-01 without the
need for YANG module authors to explicitly duplicate configuration
nodes in both configuration and operational containers. This draft
does not address the issue of co-location of configuration and
operational state for interfaces, nor does it provide a NETCONF
mechanism to retrieve operational data separately from configuration
data.
"Tunnel Segment in Segment Routing", Zhenbin Li, Nan Wu, 2016-03-12,
<draft-li-spring-tunnel-segment-01.txt>
This document introduces a new type of segment, Tunnel Segment, for
the segment routing (SR). Tunnel segment can be used to reduce SID
stack depth of SR path, span the non-SR domain or provide
differentiated services. Forwarding mechanisms and requirements of
control plane and data models for tunnel segments are also defined.
"PCEP Extensions for Tunnel Segment", Zhenbin Li, Xia Chen, 2016-03-12,
<draft-li-pce-tunnel-segment-01.txt>
[I-D.li-spring-tunnel-segment] introduces a new type of segment,
Tunnel Segment, for the segment routing. Tunnel segment can be used
to reduce SID stack depth of SR path, span the non-SR domain or
provide differentiated services. A binding label can be assigned to
tunnel segment. An upstream node can use such a binding label for
steering traffic into the appropriate tunnel. This document
specifies a set of extensions to PCEP to support that PCC reports
binding label of tunnel to PCE and that PCE allocates label for
tunnel and updates label binding of tunnel to PCC.

"Symmetry for Transport Layer Security", Rick van Rein, 2016-03-11,

<draft-vanrein-tls-symmetry-01.txt>
TLS connections can be run over various transports, and can in turn
carry many application protocols. All current transports and at
least some application protocols are capable of running between
symmetric end points, in what could be called peer-to-peer mode, but
the use of TLS introduces a requirement to always assign a client and
server role. This specification defines a TLS Extension to remedy
that stringency of TLS.
"Scenarios of unexpected resource assignment in RPKI", Yu Fu, Zhiwei
Yan, Xiaowei Liu, Cuicui Wang, 2016-03-10,
<draft-fu-sidr-unexpected-scenarios-01.txt>
There are some unexpected scenarios where a CA allocates resources to
the sub-node caused by misoperation or malicious operation of CA in
RPKI. Then some mechanisms may be needed to avoid these scenarios to
happen. This document describes these scenarios and related
experiments are presented.
"A Method for Generating Semantically Opaque Interface Identifiers with
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", Fernando Gont,
Shucheng LIU, 2016-03-11,
<draft-gont-dhcpv6-stable-privacy-addresses-01.txt>
This document describes a method for selecting IPv6 Interface
Identifiers that can be employed by Dynamic Host Configuration
Protocol for IPv6 (DHCPv6) servers when leasing non-temporary IPv6
addresses to DHCPv6 clients. This method is a DHCPv6 server side
algorithm, that does not require any updates to the existing DHCPv6
specifications. The aforementioned method results in stable
addresses within each subnet, even in the presence of multiple DHCPv6
servers or DHCPv6 server reinstallments. It is a DHCPv6-variant of
the method specified in RFC 7217 for IPv6 Stateless Address
Autoconfiguration.
"Service Function Chaining (SFC): Subscriber and Host Identification
Considerations", Behcet Sarikaya, DH, Mohamed Boucadair, 2016-03-21,
<draft-sarikaya-sfc-hostid-serviceheader-01.txt>
This document discusses considerations related to passing host- and
subscriber-related information to upstream Service Functions for the
sake of policy enforcement and appropriate SFC-inferred forwarding.
Once the information is consumed by SFC-aware functional elements,
the information is stripped from packets so that privacy-sensitive
information is not leaked outside an SFC-enabled domain.
"TCP Encapsulation of IKEv2 and IPSec Packets", tpauly, Samy Touati,
Ravi Mantha, 2016-04-25, <draft-pauly-ipsecme-tcp-encaps-04.txt>
This document describes a method to transport IKEv2 and IPSec packets
over a TCP connection for traversing network middleboxes that may
block IKEv2 negotiation over UDP. This method, referred to as TCP
encapsulation, involves sending all packets for tunnel establishment
as well as tunneled packets over a TCP connection. This method is
intended to be used as a fallback option when IKE cannot be
negotiated over UDP.
"Postquantum Preshared Keys for IKEv2", Scott Fluhrer, David McGrew,

Panos Kampanakis, 2016-02-05, <draft-fluhrer-qr-ikev2-01.txt>

This document describes an extension of IKEv2 to allow it to be
resistant to a Quantum Computer, by using preshared keys
"On Firewalls in Network Security", Fernando Gont, Fred Baker,
2016-02-04, <draft-gont-opsawg-firewalls-analysis-02.txt>
This document analyzes the role of firewalls in network security, and
recognizes their role in the internet architecture. It suggests a
line of reasoning about their usage, and analyzes common kinds of
firewalls and the claims made for them.
"LISP Mapping Bulk Retrieval", Mohamed Boucadair, Christian Jacquenet,
2016-03-09, <draft-boucadair-lisp-bulk-01.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. In addition, this document allows to request mappings
that match destination IP prefixes, names, or AS numbers.
This document updates RFC6830.
"Improving Mapping Services in LISP Networks", Mohamed Boucadair,
Christian Jacquenet, 2016-03-15, <draft-boucadair-lisp-subscribe-02.txt>
Mapping Services in Locator/ID Separation Protocol (LISP) networks
are key to proper LISP forwarding operation. When considering the
deployment of LISP at large scale, these Mapping Services are even
more crucial for the sake of the LISP forwarding efficiency. This
document introduces two additional LISP messages that are meant to
facilitate the dynamic discovery of Mapping Systems, improve Ingress
Tunnel Routers (ITR) recovery times and optimize the solicitation of
the LISP Mapping System as a function of the ITR location, in
particular.
"DPRIVE TLS/DTLS Message Flows", Dan Wing, Tirumaleswar Reddy,
2016-03-15, <draft-wing-dprive-profile-and-msg-flows-01.txt>
Message flows for DNS-over-TLS and DNS-over-DTLS are discussed and
compared.
"LISP Mapping Service Discovery at Large", Mohamed Boucadair, Christian
Jacquenet, 2016-03-09, <draft-boucadair-lisp-idr-ms-discovery-01.txt>
Locator/ID Separation Protocol (LISP) operation relies upon a mapping
mechanism that is used by ingress/egress Tunnel Routers (xTR) to
forward traffic over the LISP network. The ability of dynamically
discovering the Map-Resolver and Map-Server entities that provide
such mapping services is meant to facilitate global LISP operation
(automatic discovery of Map-Resolvers and Map-Servers).
This document specifies a BGP Extended Communities attribute that can
be used to dynamically discover LISP Mapping Systems of different
domains.
"LISP Mapping Service Functions Discovery (LMSFD) using OSPF", Mohamed
Boucadair, Christian Jacquenet, 2016-03-09,

<draft-boucadair-lisp-function-discovery-01.txt>
This document specifies extensions to the Open Shortest Path First
(OSPF) protocol for the discovery of Locator/ID Separation Protocol
(LISP) Mapping Service functions, especially the Map-Resolver (MR)
and Map-Server (MS) LISP components.
"A Compact LISP Encapsulation Scheme to Transport IPv4 Packets over an
IPv6 Network", Mohamed Boucadair, Christian Jacquenet, 2015-12-01,
<draft-boucadair-lisp-v6-compact-header-01.txt>
The encapsulation scheme used by the Locator/ID Separation Protocol
(LISP) may sometimes raise MTU issues at the cost of possibly
degrading the overall performance of the LISP network, especially in
IPv6 migration contexts. This document proposes a new, more compact,
encapsulation scheme that aims to accommodate such issues and
facilitate LISP deployment for IPv6 migration purposes, in
particular.
"Improving ITR Resiliency in Locator/ID Separation Protocol (LISP)
Networks", Mohamed Boucadair, Christian Jacquenet, 2016-03-15,
<draft-boucadair-lisp-itr-failure-01.txt>
This document defines an extension to the Locator/ID Separation
Protocol (LISP) to minimize LISP service disruption during Ingress
Tunnel Routers (ITRs) failure events.
"Domain Names", Edward Lewis, 2016-01-28,
<draft-lewis-domain-names-02.txt>
This document states a definition of Domain Name beyond the use of
the term within the Domain Name System. The document includes a
survey of the diverse ways Domain Names have been interpreted within
various protocols over time. The purpose of this is to give a solid
foundation for work on Domain Names across all protocols making use
of Domain Names.
"Architecture for Scheduled Use of Resources", Zhuangyan, Qin Wu, Adrian
Farrel, 2016-03-17, <draft-zhuang-teas-scheduled-resources-01.txt>
Time-Scheduled reservation of traffic engineering (TE) resources can
be used to provide resource booking for TE Label Switched Paths so as
to better guarantee services for customers and to improve the
efficiency of network resource usage into the future. This document
provides a framework that describes and discusses the architecture
for the scheduled reservation of TE resources. This document does
not describe specific protocols or protocol extensions needed to
realize this service.
"Problem Statement for IP in ITS use cases C-ACC and Platooning",
Alexandre Petrescu, Dapeng Liu, Charles Perkins, 2016-04-19,
<draft-petrescu-its-problem-02.txt>
Two vehicle-to-vehicle communications use cases are discussed, namely
Cooperative Adaptive Cruise Control (C-ACC) and Platooning. For
these two use cases, the problems are identified that pertain to
development with Internet protocols and connectivity.
"Criteria for selection of public-key cryptographic algorithms for
quantum-safe hybrid cryptography", John Schanck, William Whyte, Zhenfei

Zhang, 2016-04-04, <draft-whyte-select-pkc-qsh-01.txt>

Authenticated key exchange mechanisms instantiated with cryptosystems
based on integer factorization, finite field discrete log, or
elliptic curve discrete log, are believed to be secure now but are
vulnerable to a harvest-then-decrypt attack where an attacker who
cannot currently break the mechanism records the traffic anyway, then
decrypts it at some point in the future when quantum computers become
available. The Quantum-safe Hybrid approach is a modular design,
allowing any authenticated key exchange mechanism to be protected
against the harvest-then-decrypt attack by exchanging additional
secret material protected with an ephemeral key for a quantum-safe
public key cryptographic algorithm and including that secret material
in the Key Derivation Function (KDF) run at the end of the key
exchange. This approach has been proposed in TLS as the Quantum-safe
Hybrid handshake mechanism for Transport Layer Security protocol
(QSH_TLS). This document provides a guideline to criteria for
selecting public key encryption algorithms approved for experimental
use in the quantum safe hybrid setting.
"Metadata Type Issues", Cui Wang, Wei Meng, 2016-04-19,
<draft-wang-sfc-md-type-issues-01.txt>
Service function chain is the definition of an ordered set of service
functions. After instantiated, the service function path is created
and the classified traffic is steered through the corresponding
service function path and then forwarded to the final destination.
Metadata (MD) is conveyed in SFC data plane which provides the
ability to exchange context information between classifiers and SFs,
among SFs, and between external systems and SFs. This document is
motivated to state an issue when MD Type = 0x1 and discuss which
Metadata Type in more appropriate to be mandate in SFC data plane.
"An MPTCP Option for Network-Assisted MPTCP Deployments: Plain Transport
Mode", Mohamed Boucadair, Christian Jacquenet, Denis Behaghel, stesecci,
Wim Henderickx, Robert Skog, 2015-12-08,
<draft-boucadair-mptcp-plain-mode-06.txt>
One of the promising deployment scenarios for Multipath TCP (MPTCP)
is to enable a Customer Premises Equipment (CPE) that is connected to
multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its
network attachments. Because of the lack of MPTCP support at the
server side, some service providers now consider a network-assisted
model that relies upon the activation of a dedicated function called
MPTCP Concentrator. This document focuses on a deployment scheme
where the identity of the MPTCP Concentrator(s) is explicitly
configured on connected hosts.
This document specifies an MPTCP option that is used to avoid an
encapsulation scheme between the CPE and the MPTCP Concentrator.
Also, this document specifies how UDP traffic can be distributed
among available paths without requiring any encapsulation scheme.
"Packet Generation in Service Function Chains", Reinaldo Penno, Carlos
Pignataro, Chui-Tin Yen, Eric Wang, Kent Leung, David Dolson,
2016-04-29, <draft-penno-sfc-packet-03.txt>
Service Functions (e.g., Firewall, NAT, Proxies and Intrusion
Prevention Systems) generate packets in the reverse flow direction to
the source of the current in-process packet/flow. In this document

we discuss and propose how to support this required functionality

within the SFC framework.
"Performance Measurement (PM) with Marking Method in Bit Index Explicit
Replication (BIER) Layer", Greg Mirsky, Lianshu Zheng, Mach Chen,
Giuseppe Fioccola, 2016-03-16, <draft-mirsky-bier-pmmm-oam-01.txt>
This document describes a passive performance measurement method for
multicast service over Bit Index Explicit Replication (BIER) domain.
"PCEP Extension for Distribution of Link-State and TE Information.",
Dhruv Dhody, Young Lee, Daniele Ceccarelli, 2016-03-15,
<draft-dhodylee-pce-pcep-ls-03.txt>
In order to compute and provide optimal paths, Path Computation
Elements (PCEs) require an accurate and timely Traffic Engineering
Database (TED). Traditionally this TED has been obtained from a link
state (LS) routing protocol supporting traffic engineering
extensions.
This document extends the Path Computation Element Communication
Protocol (PCEP) with Link-State and TE Information.
"An SDN Framework with Software-Defined Pricing (SDP)", Bin Zhuge,
Yining Wang, Hua Zhu, Weiming Wang, 2016-05-04,
<draft-zhuge-sdnrg-sdn-sdp-02.txt>
This document defines a notion called Software-Defined Pricing (SDP)
and introduces it into a Software-Defined Networks (SDN) framework.
The SDN system with SDP inside is expected to promote the efficiency
on SDN resources usage and ease management for service providers.
"BGP Link-State extensions for Segment Routing", Stefano Previdi, Peter
Psenak, Clarence Filsfils, Hannes Gredler, Mach Chen, Jeff Tantsura,
2015-12-14, <draft-gredler-idr-bgp-ls-segment-routing-ext-01.txt>
Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS, OSPF and
OSPFv3).
This draft defines extensions to the BGP Link-state address-family in
order to carry segment information via BGP.
"Service Function Chaining Use Cases for Network Security", Eric Wang,
Kent Leung, Jeremy Felix, Jay Iyer, 2016-03-17,
<draft-wang-sfc-ns-use-cases-01.txt>
Enterprise networks deploy a variety of security devices to protect
the network, hosts and endpoints. Network security devices, both
hardware and virtual, operate at all OSI layers with scanning and
analysis capabilities for application content. Multiple specific
devices are often deployed together for breadth and depth of defense.
This document describes use cases of Service Function Chaining (SFC)
when deploying network security devices in the manner described above
and also puts forth requirements for their effective operation.
"Resource Record for DNS Administrative Boundaries", Jiankang Yao, Ning,
XiaoDong Lee, 2016-01-26, <draft-yao-dbound-dns-solution-02.txt>

Two or more DNS names may have the same DNS administrative
boundaries. This document adds the function of lookup of domain name
administrative boundary to domain name system, which describes a new
method for using dbound resource record for judging domain name
administrative boundaries.
"Examples of LMAP Objects using IPPM Metrics and Protocols", Al Morton,
2016-03-21, <draft-morton-lmap-examples-01.txt>
In order to examine the completeness and coverage of the LMAP info
and data models, we present examples expressing information from IP
Performance Metric working group metrics and protocols, and the
Performance Metrics Registry. The main update in the version
provides a more realistic and useful example of the Cycle_ID in
measurement instruction and reporting.
"TLS/DTLS PSK Identity Extension", Jayaraghavendran K, Raja K,
2016-01-20, <draft-jay-tls-psk-identity-extension-01.txt>
Pre-Shared Key (PSK) based Key Exchange Mechanism is primarily used
in constrained environments where resource intensive Asymmetric
Cryptography cannot be used. In the Internet of Things (IoT)
deployments, constrained devices are commonly used for collecting
data via sensors for use in home automation, smart energy etc. In
this context, DTLS is being considered as the primary protocol for
communication security at the application layer and in some cases, it
is also being considered for network access authentication.
This document provides a specification for a new extension for
Optimizing DTLS and TLS Handshake when the Pre-Shared Key (PSK) based
Key Exchange is used. This extension is aimed at reducing the number
of messages exchanged and the RTT of the TLS & DTLS Handshakes.
"MS-originated SMRs", Alberto Rodriguez-Natal, Albert Cabellos-Aparicio,
Vina Ermagan, Fabio Maino, Sharon Barkai, 2016-04-04,
<draft-rodrigueznatal-lisp-ms-smr-01.txt>
This document extends [RFC6830] to allow Map Servers to send SMR
messages.
This extension is intended to be used in some SDN deployments that
use LISP as a southbound protocol with (P)ITRs that are compliant
with [RFC6830]. In this use-case mapping updates do not come from
ETRs, but rather from a centralized controller that pushes the
updates directly to the Mapping System. In such deployments, Map
Servers will benefit from having a mechanism to inform directly
(P)ITRs about updates in the mappings they are serving.
"Verification Code Extension for the Extensible Provisioning Protocol
(EPP)", James Gould, 2016-03-10,
<draft-gould-eppext-verificationcode-03.txt>
This document describes an Extensible Provisioning Protocol (EPP)
extension for including a verification code for marking the data for
a transform command as being verified by a 3rd party, which is
referred to as the Verification Service Provider (VSP). The
verification code is digitally signed by the VSP using XML Signature
and is "base64" encoded. The XML Signature includes the VSP signer
certificate, so the server can verify that the verification code

originated from the VSP.

"BFCP floor control signalling over Data Channels", Keith Drage, Juergen
Stoetzer-Bradler, Albrecht Schwarz, 2016-04-04,
<draft-schwarz-mmusic-bfcp-usage-data-channel-02.txt>
This document specifies how the Binary Floor Control Protocol (BFCP)
can be instantiated as a data channel sub-protocol, using the SDP
offer/answer exchange-based external negotiation defined in [ID.ietf-mmusic-data-channel-sdpneg]. Two network configurations are
documented: a WebRTC end-to-end configuration (connecting two BFCP
over data channel endpoints), and a gateway configuration
(connecting an BFCP over data channel endpoint with an BFCP over
(TLS)/TCP/IP (or over (DTLS)/UDP/IP) endpoint).
"TLS-KDH: Kerberos + Diffie-Hellman in TLS", Rick van Rein, 2016-04-03,
<draft-vanrein-tls-kdh-03.txt>
This specification defines a TLS message flow with Kerberos-based
(mutual) authentication, binding in Elliptic-Curve Diffie-Hellman to
achieve Forward Secrecy for the session.
"LISP Control Plane integration with NSH", Vina Ermagan, Paul Quinn,
Darrel Lewis, Fabio Maino, Florin Coras, 2016-04-04,
<draft-ermagan-lisp-nsh-01.txt>
This document defines extensions to the LISP control plane protocol
to enable support for Network Service Header(NSH) based Service
Function Chaining (SFC).
"Certificate Transparency (CT) System Architecture", Stephen Kent, David
Mandelberg, Karen Seo, 2016-02-01,
<draft-kent-trans-architecture-02.txt>
This document describes the architecture for Certificate Transparency
(CT) focusing on the Web PKI context. It defines the goals of CT and
the elements that comprise the CT system. It also describes the major
features of these elements. Other documents, cited in the References,
establish requirements for these CT system elements and describe
their operation in greater detail.
"Believing NSEC records in the DNS root.", Warren Kumari, Geoff Huston,
2016-02-23, <draft-wkumari-dnsop-cheese-shop-01.txt>
This document describes a method to generate negative answers from
NSEC records for the special case of the DNS root. This improves
performance; the resolver can answer immediatly, and does not need to
query the root. It also cuts down on the so-called "junk" queries.
[ Ed note: Text inside square brackets ([]) is additional background
information, answers to frequently asked questions, general musings,
etc. They will be removed before publication.]
[ This document is being collaborated on in Github at:
https://github.com/wkumari/draft-wkumari-dnsop-cheese-shop. The most
recent version of the document, open issues, etc should all be
available here. The authors (gratefully) accept pull requests ]
"Deprecated Network Prefix Provision", Jong-Hyouk Lee, Zhiwei Yan,
2016-04-05, <draft-jhlee-dmm-dnpp-01.txt>

This document introduces new extensions to router advertisement and

router solicitation messages. The extensions are used to provide a
mobile node's deprecated network prefix information to an access
router. This document updates [RFC4861].
"Path Maximum Transmission Unit Discovery (PMTUD) for Bit Index Explicit
Replication (BIER) Layer", Greg Mirsky, A. Przygienda, Andrew Dolganow,
2016-04-05, <draft-mirsky-bier-path-mtu-discovery-01.txt>
This document describes Path Maximum Transmission Unit Discovery
(PMTUD) in Bit Indexed Explicit Replication (BIER) layer.
"Extensible Provisioning Protocol (EPP) China Name Verification
Mapping", Xie Jiagui, James Gould, Liu Hongyan, 2016-05-04,
<draft-xie-eppext-nv-mapping-02.txt>
This document describes an Extensible Provisioning Protocol (EPP) for
the provisioning and management of Name Verification (NV) stored in a
shared central repository in China. Specified in XML, the mapping
defines EPP command syntax and semantics as applied to name
verification.
"Pseudonymity Support for Kerberos", Rick van Rein, 2016-04-22,
<draft-vanrein-kitten-krb-pseudonymity-01.txt>
Kerberos either retains client identity in all its ticket
transformations, or it applies rigorous anonymity. When crossing
over to another realm, an intermediate privacy measure is often
desired, namely pseudonymity, as described in this specification.
"TLS Server Identity Pinning with Tickets", Yaron Sheffer, 2016-02-06,
<draft-sheffer-tls-pinning-ticket-01.txt>
Fake public-key certificates are an ongoing problem for users of TLS.
Several solutions have been proposed, but none is currently in wide
use. This document proposes to extend TLS with opaque tickets,
similar to those being used for TLS session resumption, as a way to
pin the server's identity. That is, to ensure the client that it is
connecting to the right server even in the presence of corrupt
certificate authorities and fake certificates. The main advantage of
this solution is that no manual management actions are required.
"BIER Use Case in Data Centers", Cui Wang, Zheng Zhang, fangwei hu,
2016-01-18, <draft-wang-bier-vxlan-use-case-01.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 perflow 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 tries to describe the drawbacks of how BUM services are

deployed in current data centers, and proposes how to take full

advantage of BIER to implement BUM services in data centers.
"Node Potential Oriented Multi-NextHop Routing Protocol", Julong Lan,
Jianhui Zhang, Bin Wang, Wenfen Liu, Y.J. Bu, Li Xin, 2016-04-20,
<draft-lanzhangwang-rtgwg-npmnrp-01.txt>
The Node Potential Oriented Multi-Nexthop Routing Protocol (NP-MNRP)
bases on the idea of "hop-by-hop routing forwarding, multi-backup
next hop" and combines with the phenomena that water flows from
higher place to lower. NP-MNRP defines a metric named as node
potential, which is based on hop count and the actual link bandwidth,
and calculates multiple next-hops through the potential difference
between the nodes.
"Design considerations for Metadata Insertion", Ted Hardie, 2016-03-20,
<draft-hardie-privsec-metadata-insertion-02.txt>
The IAB has published [RFC7624] in response to several revelations of
pervasive attack on Internet communications. In this document we
consider the implications of protocol designs which associate
metadata with encrypted flows.
In particular, we assert that designs which do so by explicit actions
of the end system are preferable to designs in which middleboxes
insert them.
"Guidelines for DiffServ to IEEE 802.11 Mapping", szigeti, Fred Baker,
2016-03-15, <draft-szigeti-tsvwg-ieee-802-11-01.txt>
As internet traffic is increasingly sourced-from and destined-to
wireless endpoints, it is crucial that Quality of Service be aligned
between wired and wireless networks; however, this is not always the
case by default. This is due to the fact that two independent
standards bodies provide QoS guidance on wired and wireless networks:
specifically, the IETF specifies standards and design recommendations
for wired IP networks, while a separate and autonomous standardsbody, the IEEE, administers the standards for wireless 802.11
networks. The purpose of this document is to propose a set
Differentiated Services Code Point (DSCP) to IEEE 802.11 User
Priority (UP) mappings to reconcile the marking recommendations
offered by these two standards bodies, and, as such, to optimize
wired-and-wireless interconnect QoS.
"Organizational Domains and Use Policies for Domain Names", Casey
Deccio, 2016-04-04,
<draft-deccio-dbound-organizational-domain-policy-02.txt>
Various Internet protocols and applications require some mechanism
for identifying policy surrounding the use Domain Name System (DNS)
names. In this document we describe an extensible system in which
domain name policies can be discovered at various levels in the DNS
tree.
"Network Service Header TLVs", Paul Quinn, Uri Elzur, Sumandra Majee,
Joel Halpern, 2016-04-15, <draft-quinn-sfc-nsh-tlv-01.txt>
This draft describes Network Service Header (NSH) MD-Type 2 metadata
TLVs that can be used within a service function path.
"A Hybrid Integrity Assurance Strategy for Bundle Protocol", Taixin Li,

Guanwen Li, Bo-Hao Feng, Hua-chun Zhou, 2016-04-03,

<draft-li-dtn-hybrid-integrity-01.txt>
Delay/Disruption Tolerant Networking (DTN) is designed for a severe
environment where communication quality is not guaranteed. It works
as an overlay network associated with Bundle Protocol (BP) and some
convergence layer protocols like Licklider Transmission Protocol
(LTP). However, there is no mechanism in both BP and LTP Protocol to
ensure integrity of a packet with the granularity of bit. Since the
integrity is crucial for packet transmission and necessary metadata
consumes extra costs, there should be a strategy to decide which
packets and how the packets are required to conduct integrity
assurance based on network resources and user requirements. Hence, in
this document, a hybrid integrity assurance strategy is proposed to
ensure the different levels of integrity of bundles based on the
status of network resources and the need of users.
"Architecture and Requirement for Distribution of Link-State and TE
Information via PCEP.", Young Lee, Dhruv Dhody, Daniele Ceccarelli,
2016-03-13, <draft-leedhody-teas-pcep-ls-02.txt>
In order to compute and provide optimal
Elements (PCEs) require an accurate and
Database (TED). Traditionally this Link
been obtained from a link state routing
engineering extensions).

paths, Path Computation

timely Traffic Engineering
State and TE information has
protocol (supporting traffic

This document provides possible architectural alternatives for linkstate and TE information distribution and their potential impacts on
PCE, network nodes, routing protocols etc.
"Congestion control for 4G and 5G access", Ingemar Johansson,
2016-04-12, <draft-johansson-cc-for-4g-5g-01.txt>
This memo outlines the challenge that 4G and 5G access brings for
transport protocol congestion control and also outlines a few simple
examples that can improve transport protocol congestion control
performance in 4G and 5G access.
"A Mechanism Coping with Unexpected Disruption in Space Delay Tolerant
Networks", Wenfeng Shi, Qi Xu, Bo-Hao Feng, Hua-chun Zhou, 2016-04-04,
<draft-shi-dtn-amcud-01.txt>
This document proposes a coping mechanism used to deal with the
unpredictable disruption problem in Space Delay Tolerant Networks
(DTN) [RFC4838]. Since Licklider Transmission Protocol (LTP)
[RFC5326] provides retransmission-based reliability for bundles,
several times of retransmissions can be seen as a failure occurred
over links. The proposed mechanism is used to direct the following
packets to other nodes and probes the availability of the links
which has disrupted unexpectedly.
"Yang Data Model for IPIPv4 Tunnel", Ying Liu, Adam Foldes, Guangying
Zheng, Zitao Wang, Zhuangyan, 2016-03-21,
<draft-liu-intarea-ipipv4-tunnel-yang-01.txt>
This document defines a YANG data model for the management of IPv4
or IPv6 over IPv4 tunnels. The data model covers configuration data,
operational state data and RPC execution commands.

"Problems in and among industries for the prompt realization of IoT and
safety considerations", Hiroyuki BABA, yoshiki, Takayuki Amatsu, Koichi
KUNITAKE, Kaoru Maeda, 2016-03-10, <draft-baba-iot-problems-01.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.
"Recursive Monitoring Language in Network Function Virtualization (NFV)
Infrastructures", Xuejun Cai, Catalin Meirosu, Greg Mirsky, 2016-03-21,
<draft-cai-nfvrg-recursive-monitor-01.txt>
Network Function Virtualization (NFV) poses a number of monitoring
challenges; one potential solution to these challenges is a recursive
monitoring language. This document presents a set of requirements
for such a recursive monitoring language.
"PCEP Extensions for BIER", Ran Chen, Zheng Zhang, 2015-12-25,
<draft-chen-pce-bier-01.txt>
Bit Index Explicit Replication (BIER)-TE shares architecture and
packet formats with BIER as described in
([I-D.ietf-bier-architecture]). BIER-TE forwards and replicates
packets based on a BitString in the packet header, but every
BitPosition of the BitString of a BIER-TE packet indicates one or
more adjacencies.BIER-TE Path can be derived from a Path Computation
Element (PCE).
This document specifies extensions to the Path Computation Element
Protocol (PCEP) to handle requests and responses for the computation
of paths for BIER-TE.
"A YANG Data Model for Static Route", LQD, Gang Yan, Shunwan Zhuang,
2015-12-16, <draft-liang-rtgwg-staticrt-yang-cfg-01.txt>
This document defines a YANG data model for static routes. The data
model includes configuration data and state data.
"Authenticated Received Chain (ARC)", None, Kurt Andersen, JohnRG,
Brandon Long, J. Adams, Steven Jones, 2016-04-28,
<draft-andersen-arc-04.txt>
Authenticated Received Chain (ARC) permits an organization which is
creating or handling email to indicate its involvement with the

handling process. It defines a set of cryptographically signed

header fields in a manner analagous to that of DKIM. Assertion of
responsibility is validated through a cryptographic signature and by
querying the Signer's domain directly to retrieve the appropriate
public key. Changes in the message that might break DKIM can be
identified through the ARC set of header fields.
"Recommended Usage of the Authenticated Received Chain (ARC)", None,
Steven Jones, JohnRG, J. Adams, Kurt Andersen, 2016-04-04,
<draft-jones-arc-usage-01.txt>
The Authentication Received Chain (ARC) provides a means to preserve
email authentication results and verify the identity of email message
handlers, each of which participates by inserting certain header
fields before passing the message on. But the specification does not
indicate how intermediaries and receivers should interpret or utilize
ARC. This document will provide guidance in these areas.
"Grammar for Enterprise YANG Module Namespace", I. Chen, 2016-04-14,
<draft-chen-netmod-enterprise-yang-namespace-01.txt>
This document defines the grammar to create enterprise YANG module
namespaces that are globally unique, as required by the YANG modeling
language.
"Accept-Push-Policy Header Field", Herve Ruellan, Youenn Fablet, Romain
Bellessort, Franck Denoual, Frederic Maze, 2016-04-13,
<draft-ruellan-http-accept-push-policy-01.txt>
The "Accept-Push-Policy" and "Push-Policy" header fields enable a
client and a server to negotiate the behaviour of the server
regarding the usage of push on a per-request basis.
"YANG Data Model for MPLS-based L2VPN", Himanshu Shah, Patrice
Brissette, Reshad Rahman, Kamran Raza, Zhenbin Li, Shunwan Zhuang, Haibo
Wang, I. Chen, Sajjad Ahmed, Mathew Bocci, Jonathan Hardwick, Santosh
Esale, Kishore Tiruveedhula, Tapraj Singh, Iftekhar Hussain, Bin Wen,
Jason Walker, Nick Delregno, Luay Jalil, Maria Joecylyn, 2016-03-14,
<draft-shah-bess-l2vpn-yang-01.txt>
This document describes a YANG data model for Layer 2 VPN services
over MPLS networks. These services include Virtual Private Wire
Service (VPWS) and Virtual Private LAN service (VPLS) that uses LDP
and BGP signaled Pseudowires. The current version of the document
expands the L2VPN object model to include VPLS services in addition
to the VPWS services described in the last revision. This is a
living document and contains aspects of object models that have been
discussed extensively in the working group with consensus. The
intention is to continue to seek input from larger audience during
evolution of the L2VPN service model through this document.
"Yang Data Model for EVPN", Patrice Brissette, Himanshu Shah, Zhenbin
Li, Kishore Tiruveedhula, Tapraj Singh, Iftekhar Hussain, 2015-12-02,
<draft-brissette-bess-evpn-yang-01.txt>
This document describes a YANG data model for Ethernet VPN services.
The model is agnostic of the underlay. It apply to MPLS as well as to
VxLAN encapsulation. The model is also agnostic of the services
including E-LAN, E-LINE and E-TREE services. The merging of this
model with L2 services model is for future investigation. Any "add-

on" features such as EVPN IRB, EVPN overlay, etc. are for future
investigation. This document mainly focuses on EVPN instance
framework.
"Framework for Temporal Tunnel Services", Huaimo Chen, Mehmet Toy, Lei
Liu, Khuzema Pithewan, 2016-03-21, <draft-chen-teas-frmwk-tts-01.txt>
For existing MPLS LSP tunnel services, it is hard for LSP tunnels to
be booked in advance. In addition, once an LSP tunnel is set up, it
is assumed to consume a certain amount of resources such as link
bandwidth forever.
Temporal LSP tunnel services (TTS) provides an easy way for us to
book temporal LSP tunnels in advance. More importantly, a temporal
LSP is an LSP with one or more time intervals and it is assumed to
consume the resources and carry traffic only in these time intervals.
This document specifies a framework for temporal LSP tunnel services
and provides a few of reference models along with logical components
required to design a solution for TTS.
"RIB YANG Data Model", Acee Lindem, Yingzhen Qu, 2016-03-21,
<draft-acee-rtgwg-yang-rib-extend-01.txt>
The Routing Information Base (RIB) is a list of routes and their
corresponding administrative data and operational state.
The document [ROUTING-CFG] defines the basic building blocks for RIB,
and this model augments it to support multiple next-hops (aka, paths)
for each route as well as additional attributes.
"NFVI PoP Network Topology: Problem Statement", Marcelo Bagnulo, David
Dolson, 2016-03-17, <draft-bagnulo-nfvrg-topology-01.txt>
This documents describes considerations for the design of the
interconnection network of an NFVI PoP.
"Use cases for IPv6 over Networks of Resource-constrained Nodes",
Yong-Geun Hong, Carles Gomez, 2016-03-21,
<draft-hong-6lo-use-cases-01.txt>
This document describes the characteristics of link layer
technologies that are used at constrained node networks and typical
use cases of IPv6 over networks of resource-constrained nodes. In
addition to IEEE 802.15.4, various link layer technologies such as
BLE, ITU-T G.9959 (Z-Wave), DECT-ULE, MS/TP, NFC, and LTE MTC are
widely used at constrained node networks for typical services. Based
on these link layer technologies, IPv6 over networks of resourceconstrained nodes has various and practical use cases. To
efficiently implement typical services, the applicability and
consideration of several design spaces are described.
"CBOR Encoded Message Syntax: Additional Algorithms", Jim Schaad,
2016-03-21, <draft-schaad-cose-alg-01.txt>
This document defines the identifiers and usage for a set of
additional cryptographic algorithms in the CBOR Encoded Message
(COSE) Syntax.
The algorithms setup in this docment are: RSA-PSS, RSA-OAEP, ....

!!TBD!!
"Multiple Ethernet - IPv6 address mapping encapsulation - fixed prefix",
Naoki Matsuhira, 2016-04-18, <draft-matsuhira-me6e-fp-01.txt>
This document specifies Multiple Ethernet - IPv6 address mapping
encapsulation - fixed prefix (ME6E-FP) base specification. ME6E-FP
makes expantion ethernet network over IPv6 backbone network with
encapsuation technoogy. And also, E6ME-FP can stack multiple
Ethernet networks. ME6E-FP work on own routing domain.
"Multiple Ethernet - IPv6 address mapping encapsulation - prefix
resolution", Naoki Matsuhira, 2016-04-18,
<draft-matsuhira-me6e-pr-01.txt>
This document specifies Multiple Ethernet - IPv6 address mapping
encapsulation - Prefix Resolution (ME6E-PR) specification. ME6E-PR
makes expantion ethernet network over IPv6 backbone network with
encapsuation technoogy. And also, E6ME-PR can stack multiple
Ethernet networks. ME6E-PR work on non own routing domain.
"Yang Data Model for Resource Management", Xia Chen, Zhenbin Li,
2015-12-16, <draft-chen-rtgwg-resource-management-yang-01.txt>
This document describes a YANG data model for resource management.
The resource includes mpls label etc. The data model defines the
configuration and operational state for resource management.
"Yang Data Model for BGP/MPLS IP VPN", Zhenbin Li, Shunwan Zhuang,
Xufeng Liu, Jeffrey Haas, Santosh Esale, Bin Wen, 2015-12-20,
<draft-li-bess-l3vpn-yang-01.txt>
This document defines a YANG data model that can be used to configure
and manage L3VPN (BGP/MPLS IP VPN).
"Address Pool Management Yang Data Model", Qiong, Chongfeng Xie,
Mohammed Boucadair, Shucheng LIU, Yiu Lee, 2015-12-11,
<draft-sun-i2apm-address-pool-management-yang-01.txt>
This document describes a YANG data model for address pool
management. It can be used to automatically allocate, update and
delete address pools in different devices of an underlying network.
"HRPC - Report", Avri Doria, 2016-03-21,
<draft-doria-hrpc-report-01.txt>
This document presents an overview snapshot of the HRPC project to
map engineering concepts at the protocol level that may be related to
human rights, with a focus on the promotion and protection of the
freedom of expression and of association.
It provides a framework while reporting on the study including:
theoretical background, results and basic considerations. It will
reference the detailed work being done on terminlogy and case studies
documented in the research draft. It also folds in discussions from
the research literature. The documents, [HRPC-Research] and this
document, form an interrelated set that may later be combined into a
single document.
This draft is still in very early stages and welcomes further

contribution. Text is solicited.

Discussion on this draft at: hrpc@irtf.org //
https://www.irtf.org/mailman/admindb/hrpc
"P-Access-Network-Info ABNF Update", Christer Holmberg, 2016-04-08,
<draft-holmberg-dispatch-pani-abnf-03.txt>
This document updates RFC 7315, by modifying the extension-accessinfo part of the P-Access-Network-Info header field Augmented BackusNaur Form (ABNF), and by adding the following 'access-info' header
field parameter values to the list of 'access-info' header field
parameter values in the ABNF: 'operator-specific-GI' and 'utran-sai3gpp'. The values are defined in the ABNF, but are not included in
the list.
"Constrain Attribute announcement within BGP", Keyur Patel, Jim Uttaro,
Bruno Decraene, Wim Henderickx, Jeffrey Haas, 2016-03-16,
<draft-keyupate-idr-bgp-attribute-announcement-01.txt>
[RFC4271] defines four different categories of BGP Path attributes.
The different Path attribute categories can be identified by the
attribute flag values. These flags help identify if an attribute is
optional or well-known, Transitive or non-Transitive, Partial, or of
an Extended length type. BGP attribute announcement depends on
whether an attribute is a well-known or optional, and whether an
attribute is a transitive or non-transitive. BGP implementations
MUST recognize all well-known attributes. The well-known attributes
are always Transitive. It is not required for BGP implementations to
recognise all the Optional attributes. The Optional attributes could
be Transitive or Non-Transitive. BGP implementations MUST store and
forward any Unknown Optional Transitive attributes and ignore and
drop any Unknown Optional Non-Transitive attributes.
Currently, there is no way to confine the scope of Path attributes
within a given Autonomous System (AS) or a given BGP member-AS in
Confederation. This draft defines attribute extensions that help
confine the scope of Optional attributes within a given AS or a given
BGP member-AS in Confederation
"SRTP Double Encryption Procedures", Cullen Jennings, Paul Jones, Adam
Roach, 2016-03-21, <draft-jennings-perc-double-01.txt>
In some conferencing scenarios, it is desirable for an intermediary
to be able to manipulate some RTP parameters, while still providing
strong end-to-end security guarantees. This document defines SRTP
procedures that use two separate but related cryptographic contexts
to provide "hop-by-hop" and "end-to-end" security guarantees. Both
the end-to-end and hop-by-hop cryptographic transforms can utilize an
authenticated encryption with associated data scheme or take
advantage of future SRTP transforms with different properties.
"Micro-loop avoidance using SPRING", Shraddha Hegde, 2016-01-06,
<draft-hegde-rtgwg-microloop-avoidance-using-spring-01.txt,.pdf>
When there is a change in network topology either due to a link going
down or due to a new link addition, all the nodes in the network need
to get the complete view of the network and re-compute the routes.
There will generally be a small time window when the forwarding state
of each of the nodes is not synchronized. This can result in

transient loops in the network, leading to dropped traffic due to

over-subscription of links. Micro-looping is generally more harmful
than simply dropping traffic on failed links, because it can cause
control traffic to be dropped on an otherwise healthy link involved
in micro-loop. This can lead to cascading adjacency failures or
network meltdown.
"User-group-based Security Policy for Service Layer", Jianjie You, Myo
Zarny, Christian Jacquenet, Mohamed Boucadair, Li Yizhou, John
Strassner, Sumandra Majee, 2016-03-09,
<draft-you-i2nsf-user-group-based-policy-01.txt>
This draft defines the User-group Aware Policy Control (UAPC)
framework, which facilitates consistent enforcement of security
policies based on user group identity. Policies are used to control
security policy enforcement using a policy server and a security
controller. Northbound APIs are also discussed.
"Segment Routing Recursive Information", Clarence Filsfils, Stefano
Previdi, Peter Psenak, Les Ginsberg, 2016-04-25,
<draft-filsfils-spring-sr-recursing-info-02.txt>
Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS and OSPF).
There are use cases where it is desirable to utilize a SID associated
with a given node in order to transport traffic destined to different
local services supported by such node. This document defines the
mechanism to do so and illustrates it.
"A YANG Data Model for Layer 1 Network Topology", Xian Zhang, Baoquan
Rao, Xufeng Liu, 2015-12-22, <draft-zhang-ccamp-l1-topo-yang-02.txt>
This draft describes a YANG data model to manipulate the topologies
of a layer 1 Optical Transport Network (OTN). It is independent of
control plane protocols and captures topology related information
pertaining to OTN and also enables manipulation of an OTN network
via the I2RS interface.
"Information Distribution over GRASP", Bing Liu, Sheng Jiang,
2016-03-21, <draft-liu-anima-grasp-distribution-01.txt>
This document discusses the requirement of information distribution
capability in autonomic networks. Ideally, the autonomic network
should support distributing some information which is generated/
injected at an arbitrary autonomic node and be distributed among the
whole autonomic domain. This docuemnt specifically proposes to
achive this goal based on the GRASP (A Generic Autonomic Signaling
Protocol), and specifies additional node behavior.
"Yang Data Model for Service Function Chaining Control Plane", Myung-Ki
Shin, Mi-Jung Choi, Seungik Lee, 2016-04-04,
<draft-shin-sfc-control-plane-yang-01.txt>
This document defines Yang data model for control plane management of
service function chaining based on [I-D.ietf-sfc-control-plane],
which describes components and requirements of SFC control plane.

"An SNMP MIB extension to RFC3591 to manage optical interface parameters

of "G.698.2 single channel" in DWDM applications", Gabriele Galimberti,
Ruediger Kunze, Dharini Hiremagalur, Luyuan Fang, Gary Ratterree,
2016-03-17, <draft-galikunze-ccamp-dwdm-if-snmp-mib-01.txt>
This memo defines a module of the Management Information Base (MIB)
used by Simple Network Management Protocol (SNMP) in TCP/IP- based
internet. In particular, it defines objects for managing single
channel optical interface parameters of DWDM applications, using the
approach specified in G.698.2 [ITU.G698.2] . This interface,
described in ITU-T G.872, G.709 and G.798, is one type of OTN multivendor Intra-Domain Interface (IaDI). This RFC is an extension of
RFC3591 to support the optical parameters specified in ITU-T G.698.2
and application identifiers specified in ITU-T G.874.1 [ITU.G874.1].
Note that G.874.1 encompasses vendor-specific codes, which if used
would make the interface a single vendor IaDI and could still be
managed.
The MIB module defined in this memo can be used for Optical
Parameters monitoring and/or configuration of the endpoints of the
multi-vendor IaDI based on the Black Link approach.
"Improving IGMPv3 and MLDv2 Resilience", Hermin Anggawijaya, 2016-02-23,
<draft-anggawijaya-pim-resilient-gmp-01.txt>
Host devices send IGMP or MLD group membership report messages to
tell the designated router (DR) which multicast groups they want to
receive.
These messages are sent repeatedly up to maximum number of times
determined by the 'Robustness Variable' setting. However, in certain
situations, those messages could get lost.
This draft proposes a mechanism whereby host devices attached to a
local area network where the querier and the DR are the same device,
can request the querier to acknowledge each report message it
receives, ensuring report messages reception by the DR.
"Layer 3 VPN Service deployment in ONOS", Yiyong Zha, Dacheng Zhang,
Ying Cheng, Maxim Klyus, 2015-12-20,
<draft-zha-l3sm-l3vpn-onos-deployment-03.txt>
This document defines a YANG model that is used to deliver layer 3 VPN
service
in ONOS project which is on the controller level. L3SM is
focused on the
service model which is on the orchestration level to help
interaction
between
customers and network operators and also can be
input to automated control
and
configuration applications. ONOS runs
as an open source project for fast
deployment. Use L3VPN service model
defined in L3SM and deploy L3VPN service
in
ONOS project can be one
step further. On the other hand, push real deployment
in ONOS back to
IETF is also beneficial.
"Network Machine Learning", Sheng Jiang, 2016-04-22,
<draft-jiang-nmlrg-network-machine-learning-01.txt>
This document introduces background information of machine learning

briefly, then explores the potential of machine learning techniques

for networks. This document is serving as a white paper of the
(proposed) IRTF Network Machine Learning Research Group.
"SPRING Use cases for Mobile Network", Jeong Kim, Gyu Lee, 2015-12-28,
<draft-kim-spring-mobile-network-use-cases-01.txt,.pdf>
The ability for a node to specify a forwarding path, other than the
normal shortest path, that a particular packet will traverse,
benefits a number of network functions. Source-based routing
mechanisms have previously been specified for network protocols, but
have not seen widespread adoption. In this context, the term
'source' means 'the point at which the explicit route is imposed'.
The objective of this document is to illustrate some use cases that
provide the traffic engineering and the load balancing for mobile
and transport network, applying segment routing.
"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", Dharini Hiremagalur, Gert Grammel, Gabriele Galimberti,
Zafar Ali, Ruediger Kunze, Dieter Beller, 2016-03-17,
<draft-dharinigert-ccamp-dwdm-if-lmp-01.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.
"YANG Data Model for Value Added Service (VAS)", Gu Rong, Chen Li,
Zhuangyan, Zitao Wang, 2015-12-11,
<draft-gu-l3sm-vas-service-model-01.txt>
L3SM defines a YANG data model for L3VPN service model that can be
used to configure and manage L3VPN network. This document discusses
generic VAS model that can be applied to L3VPN network and other
Cloud VPN networks. The YANG model provides common structure for
various VAS service components.
"SFC environment Security requirements", Daniel Migault, Carlos
Pignataro, Tirumaleswar Reddy, Christopher Inacio, 2016-04-04,
<draft-mglt-sfc-security-environment-req-01.txt>
This document provides environment security requirements for the SFC
architecture. Environment security requirements are independent of
the protocols used for SFC - such as NSH for example. As a result,
the requirements provided in this document are intended to provide
good security practices so SFC can be securely deployed and operated.
These security requirements are designated as environment security
requirements as opposed to the protocol security requirements.
"ALTO Extension: Endpoint Cost Service for Flows", Xvdong Shen, J.
Zhang, Junzhuo Wang, Qiao Xiang, 2016-04-20,
<draft-wang-alto-ecs-flows-01.txt>
The Endpoint Cost Service (ECS) has limitations to illustrate the
network condition and to work with the OpenFlow protocol. This
document extends ECS to improve the Application-Layer Traffic

Optimization (ALTO) protocol by (1) defining more types of endpoint

address such as port number, protocol type, domain and etc; (2)
adding flow constraints.
"Federated Multi-Tenant Service Architecture for an Internet of Things",
Jerome Marcon, Herb Wildfeuer, 2016-04-20,
<draft-burgess-promise-iot-arch-01.txt>
This draft describes architectural recommendations for a unified
concept of Cloud Computing and Internet of Things, based on tried and
tested principles from infrastructure science. We describe a
functional service architecture that may be applied in the manner of
a platform, from the smallest scale to the largest scale, using
vendor agnostic principles. The current draft is rooted in the
principles of Promise Theory[Bergstra1] and voluntary cooperation.
"Alternate Marking Extension to Cisco SLA Protocol RFC6812", Giuseppe
Fioccola, Alex Clemm, Mauro Cociglio, Mouli Chandramouli, Alessandro
Capello, 2016-03-21, <draft-fioccola-ippm-rfc6812-alt-mark-ext-01.txt>
Cisco's Service-Level Assurance Protocol (Cisco's SLA Protocol) RFC
6812 [RFC6812] is a Performance Measurement protocol that has been
widely deployed. The protocol is used to measure service-level
parameters such as network latency, delay variation, and packet/frame
loss. This document describes an extension to the Cisco SLA Protocol
Measurement-Type UDP-Measurement, in order to implement alternate
marking methodology detailed in [I-D.tempia-ippm-p3m]. The extension
is used to measure service level parameters by marking test traffic.
"Considerations for Benchmarking High Availability of NFV
Infrastructure", Taekhee Kim, EunKyoung Paik, 2016-03-21,
<draft-kim-bmwg-ha-nfvi-01.txt>
This documents lists additional considerations and strategies for
benchmarking high availability of NFV infrastructure when network
functions are virtualized and performed in NFV infrastructure.
"URN Namespace for IEEE", Angela Thomas, 2016-03-08,
<draft-ieee-urn-01.txt>
This document describes the Namespace Identifier (NID) 'ieee' for
Uniform Resource Names (URNs) used to identify resources published by
the Institute of Electrical and Electronics Engineers (IEEE). IEEE
specifies and manages resources that utilize this URN identification
model. Management activities for these and other resources types are
handled by the manager of the IEEE Registration Authority.
"SFC Trace Issue Analysis and Solutions", Xu Yang, Lei Zhu, Georgios
Karagiannis, 2016-02-04, <draft-yang-sfc-trace-issue-analysis-01.txt>
This document analyzes and provides solutions for some unaddressed
SFC Traceroute issues.
"Controlling Actuators with CoAP", John Mattsson, John Fornehed, Goran
Selander, Francesca Palombini, 2016-03-21,
<draft-mattsson-core-coap-actuators-01.txt>
Being able to trust information from sensors and to securely control
actuators is essential in a world of connected and networking things
interacting with the physical world. In this memo we show that just

using COAP with a security protocol like DTLS, TLS, or OSCOAP is not
enough. We describe several serious attacks any on-path attacker can
do, and discusses tougher requirements and mechanisms to mitigate the
attacks. While this document is focused on actuators, one of the
attacks applies equally well to sensors using DTLS.
"Inter-Domain DOTS Use Cases", Kaname Nishizuka, 2016-03-20,
<draft-nishizuka-dots-inter-domain-usecases-01.txt>
This document describes inter-domain use cases of the DDoS Open
Threat Signaling(DOTS).
"Yang Data Model for Internet Protocol Security (IPsec)", Khanh Tran,
Honglei Wang, Vijay Nagaraj, Xia Chen, 2016-03-18,
<draft-tran-ipsecme-yang-01.txt>
This document defines a YANG data model that can be used to
configure and manage Internet Protocol Security (IPsec). The model
covers the IPsec protocol operational state, remote procedural
calls, and event notifications data.
"Remote Attestation Procedures for virtualized NSFs (vNSFs) through the
I2NSF Security Controller", Antonio Pastor, Diego Lopez, Adrian Shaw,
2016-03-21, <draft-pastor-i2nsf-vnsf-attestation-02.txt>
This document describes the procedures a user can follow to assess
the trust on a virtualized NSF and its user-defined configuration
through the I2NSF Security Controller. The procedure to assess
trustworthiness is based on a remote attestation of the
virtualization platform and the vNSFs running on it performed through
a Trusted Platform Module (TPM) invoked by the Security Controller.
"Experiences of Implementing ALTO in OpenDaylight", J. Zhang, Kai Gao,
Yang Yang, 2016-04-20, <draft-zhang-alto-opendaylight-impl-01.txt>
This text introduces some experiences of implementing ALTO in
OpenDaylight (ODL). The main key issues about design and
implementation are discussed. Some of these issues have been figured
out in the current implementation, the others have not. This text
also gives some possible designs to discuss.
"RESTful Design for Internet of Things Systems", Ari Keranen, Matthias
Kovatsch, Klaus Hartke, 2016-03-14,
<draft-keranen-t2trg-rest-iot-01.txt>
This document gives guidance for designing Internet of Things (IoT)
systems that follow the principles of the Representational State
Transfer (REST) architectural style.
"A Description of RDAP JSON Messages Using JSON Content Rules", Andrew
Newton, 2016-03-21, <draft-newton-rdap-jcr-01.txt>
This document describes the JSON responses in the Registration Data
Access Protocol with the formal notation of JSON Content Rules.
"Time-Based Uni-Directional Attestation", Andreas Fuchs, Henk Birkholz,
Ira McDonald, Carsten Bormann, 2016-03-21, <draft-birkholz-tuda-01.txt>
This memo documents the method and bindings used to conduct timebased uni-directional attestation between distinguishable endpoints

over the network.

"Directional Deringing Filter", Jean-Marc Valin, 2016-03-21,
<draft-valin-netvc-deringing-01.txt>
This document describes a deringing filter that takes into account
the direction of edges and patterns being filtered. The filter works
by identifying the direction of each block and then adaptively
filtering along the identified direction. In a second pass, the
blocks are also filtered in a different direction, with more
conservative thresholds to avoid blurring edges. The proposed
deringing filter is shown to improve the quality of both Daala and
the Alliance for Open Media (AOM) video codec.
"6TiSCH 6top Scheduling Function Zero (SF0)", Diego Dujovne, Luigi
Grieco, Maria Palattella, Nicola Accettura, 2016-03-21,
<draft-dujovne-6tisch-6top-sf0-01.txt>
This document defines a 6top Scheduling Function called "Scheduling
Function Zero" (SF0). SF0 dynamically adapts the number of reserved
cells between neighbor nodes, based on the currently allocated
bandwidth and the neighbour nodes' requirements. Neighbor nodes
negotiate in a distributed neighbor-to-neighbor basis the cell(s) to
be added/deleted. SF0 uses the 6P signaling messages to add/delete
cells in the schedule. Some basic rules for deciding when to add/
delete cells and for selecting the cells to be added/deleted within
the schedule are also provided.
"Interim Meeting Management", Robert Sparks, 2015-10-19,
<draft-sparks-genarea-interim-management-00.txt>
This memo discusses requirements for improvements to the datatracker
related to tracking interim meetings.
"Tracking Manual I-D Post Requests", Robert Sparks, 2015-10-19,
<draft-sparks-genarea-manualpost-tracking-00.txt>
This memo discusses requirements for improvements to the datatracker
related to tracking manual post requests.
"A Day in the Life of an Autonomic Function", Peloso Pierre, Laurent
Ciavaglia, 2016-03-21,
<draft-peloso-anima-autonomic-function-01.txt,.pdf>
While autonomic functions are often pre-installed and integrated with
the network elements they manage, this is not a mandatory condition.
Allowing autonomic functions to be dynamically installed and to
control resources remotely enables more versatile deployment
approaches and enlarges the application scope to virtually any legacy
equipment. The analysis of autonomic functions deployment schemes
through the installation, instantiation and operation phases allows
constructing a unified life-cycle and identifying new required
functionality. Thus, the introduction of autonomic technologies will
be facilitated, the adoption much more rapid and broad. Operators
will benefit from multi-vendor, inter-operable autonomic functions
with homogeneous operations and superior quality, and will have more
freedom in their deployment scenarios.
"TRILL: Address Flush Message", Hao Weiguo, Donald Eastlake, Li Yizhou,
2016-03-21, <draft-hao-trill-address-flush-01.txt>

The TRILL (TRansparent Interconnection of Lots of Links) protocol, by

default, learns end station addresses from observing the data plane.
This document specifies a message by which an originating TRILL
switch can explicitly request other TRILL switches to flush certain
MAC reachability learned through the egress of TRILL Data packets.
This is a supplement to the TRILL automatic address forgetting and
can assist in achieving more rapid convergence in case of topoogy or
configuration change.
"Identifying Modified Explicit Congestion Notification (ECN) Semantics
for Ultra-Low Queuing Delay", Koen De Schepper, Bob Briscoe, I J Tsang,
2016-03-21, <draft-briscoe-tsvwg-ecn-l4s-id-01.txt>
This specification defines the identifier to be used on IP packets
for a new network service called low latency, low loss and scalable
throughput (L4S). It is similar to the original (or 'Classic')
Explicit Congestion Notification (ECN). 'Classic' ECN marking was
required to be equivalent to a drop, both when applied in the network
and when responded to by a transport. Unlike 'Classic' ECN marking,
for packets carrying the L4S identifier, the network applies marking
more immediately and more aggressively than drop, and the transport
response to each mark is reduced and smoothed relative to that for
drop. The two changes counterbalance each other so that the
throughput of an L4S flow will be roughly the same as a 'Classic'
flow under the same conditions. However, the much more frequent
control signals and the finer responses to them result in ultra-low
queuing delay without compromising link utilization, even during high
load. Examples of new active queue management (AQM) marking
algorithms and examples of new transports (whether TCP-like or realtime) are specified separately. The new L4S identifier is the key
piece that enables them to interwork and distinguishes them from
'Classic' traffic. It gives an incremental migration path so that
existing 'Classic' TCP traffic will be no worse off, but it can be
prevented from degrading the ultra-low delay and loss of the new
scalable transports.
"Problem Statement for the Reservation of Top-Level Domains in the
Special-Use Domain Names Registry", Joe Abley, Peter Koch, Alain Durand,
Warren Kumari, 2016-03-21,
<draft-adpkja-dnsop-special-names-problem-02.txt>
The dominant protocol for name resolution on the Internet is the
Domain Name System (DNS). However, other protocols exist that are
fundamentally different from the DNS, and may or may not share the
same namespace.
When an end-user triggers resolution of a name on a system which
supports multiple, different protocols (or resolution mechanisms) for
name resolution, it is desirable that the protocol used is
unambiguous, and that requests intended for one protocol are not
inadvertently answered using another.
RFC 6761 introduced a framework by which, under certain
circumstances, a particular domain name could be acknowledged as
being special. This framework has been used twice to reserve toplevel domains (.local and .onion) that should not be used within the
DNS, to avoid the possibility of namespace collisions in parallel use
of non-DNS name resolution protocols.

Various challenges have become apparent with this application of the

guidance provided in RFC 6761. This document aims to document those
challenges in the form of a problem statement, to facilitate further
discussion of potential solutions.
"Multi-homed L3VPN Service with Single IP peer to CE", Ali Sajassi,
Samer Salam, Dennis Cai, John Drake, Luay Jalil, 2016-03-21,
<draft-sajassi-bess-evpn-l3vpn-multihoming-01.txt>
This document describes how EVPN can be used to offer a multi-homed
L3VPN service leveraging EVPN Layer 2 access redundancy. The solution
offers single IP peering to the Customer Edge (CE) nodes, rapid
failure detection, minimal fail-over time and make-before-break
paradigm for maintenance.
"Constrained Low Pass Filter", S. Midtskogen, Arild Fuldseth, Mo Zanaty,
2016-04-05, <draft-midtskogen-netvc-clpf-02.txt>
This document describes a low complexity filtering technique which is
being used as a low pass loop filter in the Thor video codec.
"Inter-Cloud DDoS Mitigation API", Luyuan Fang, Deepak Bansal,
2016-03-21, <draft-fang-i2nsf-inter-cloud-ddos-mitigation-api-01.txt>
This document defines an Inter-Cloud DDoS Mitigation Abstract Layer
and corresponding standardized APIs to enable the exchange of real
time automated information to enable DDoS mitigation across Cloud
Service Providers and Network Service Providers.
"The Use of Control Loops in Autonomic Networking", John Strassner, Joel
Halpern, Michael Behringer, 2016-04-19,
<draft-strassner-anima-control-loops-01.txt>
This document defines the requirements for an autonomic control
loop, describes different types of control loops, and explains how
control loops are used in an Autonomic System. Control loops are
used to enable Autonomic Network Management systems to adapt the
behavior of the systems that they manage to respond to changes in
user needs, business goals, and/or environmental conditions.
"Constrained Objects Language", Michel Veillette, Alexander Pelov,
Abhinav Somaraju, Randy Turner, Ana Minaburo, 2016-03-11,
<draft-veillette-core-cool-01.txt>
This document describes a management function set adapted to
constrained devices and constrained networks (e.g., low-power,
lossy). CoOL objects (datastores, RPCs, actions and notifications)
are defined using the YANG modelling language
[I-D.ietf-netmod-rfc6020bis]. Interactions with these objects are
performed using the CoAP web transfer protocol [RFC7252]. Payloads
are encoded using the CBOR data format [RFC7049]. The mapping
between YANG data models and the CBOR data format is defined in [ID.veillette-core-yang-cbor-mapping].
"IS-IS Routing for Spine-Leaf Topology", Naiming Shen, Sanjay
Thyamagundalu, 2016-04-25, <draft-shen-isis-spine-leaf-ext-01.txt>
This document describes a mechanism for routers and switches in
Spine-Leaf type topology to have non-reciprocal Intermediate System
to Intermediate System (IS-IS) routing relationships between the

leafs and spines. The leaf nodes do not need to have the topology
information of other nodes and exact prefixes in the network. This
extension also has application in the Internet of Things (IoT).
"Internationalized Electronic Mail Addresses in RFC5280 / X.509
Certificates", Laetitia Baudoin, Wei Chuang, Nicolas Lidzborkski,
2016-02-04, <draft-lbaudoin-iemax-02.txt>
Specifies support for email address internationalization in RFC5280 /
X.509 certificates. This defines an encoding for Unicode email
local-part characters in certificate Subject Alternative Names and
Issuer Alternative rfc822Names. The encoding is backwards compatible
with existing practices with rfc822Name.
"OpenPGP Message Format", Werner Koch, 2016-03-17,
<draft-koch-openpgp-rfc4880bis-02.txt>
{ Work in progress to update OpenPGP }
This document is maintained in order to publish all necessary
information needed to develop interoperable applications based on the
OpenPGP format. It is not a step-by-step cookbook for writing an
application. It describes only the format and methods needed to
read, check, generate, and write conforming packets crossing any
network. It does not deal with storage and implementation questions.
It does, however, discuss implementation issues necessary to avoid
security flaws.
OpenPGP software uses a combination of strong public-key and
symmetric cryptography to provide security services for electronic
communications and data storage. These services include
confidentiality, key management, authentication, and digital
signatures. This document specifies the message formats used in
OpenPGP.
"Connecting IPv4 Islands over IPv6 MPLS Using IPv4 Provider Edge Routers
(4PE)", Zhenqiang Li, 2016-03-08, <draft-li-bess-4pe-01.txt>
This document explains how to interconnect IPv4 islands over a
Multiprotocol Label Switching (MPLS)-enabled IPv6-only core. This
approach relies on IPv4 Provider Edge routers (4PE), which are Dual
Stacks in order to connect to IPv4 islands and to the MPLS core. The
4PE routers exchange the IPv4 reachability information transparently
over the core using the Multiprotocol Border Gateway Protocol (MPBGP). MP-BGP is extended to do this. A new Subsequence Address
Family Identifier (SAFI) with corresponding new format Network Layer
Reachability Information (NLRI), is introduced. The BGP Next Hop
field is used to convey the IPv4 address of the 4PE router, a field
is added in Network Layer Reachability Information (NLRI) to convey
the IPv6 address of the 4PE router, so that dynamically established
IPv6-signaled MPLS Label Switched Paths (LSPs) can be used without
explicit tunnel configuration.
"Requirements and Challenges for IoT over ICN", Yanyong Zhang, Dipankar
Raychadhuri, Luigi Grieco, Emmanuel Baccelli, Jeff Burke, Ravi
Ravindran, Guoqiang Wang, Bengt Ahlgren, Olov Schelen, 2016-04-22,
<draft-zhang-icnrg-icniot-requirements-01.txt>
The Internet of Things (IoT) promises to connect billions of objects
to the Internet. After deploying many stand-alone IoT systems in

different domains, the current trend is to develop a common, "thin

waist" of protocols forming a horizontal unified, defragmented IoT
platform. Such a platform will make objects accessible to
applications across organizations and domains. Towards this goal,
quite a few proposals have been made to build a unified host-centric
IoT platform as an overlay on top of today's host-centric Internet.
However, there is a fundamental mismatch between the host-centric
nature of todays Internet and the information-centric nature of the
IoT system. To address this mismatch, we propose to build a common
set of protocols and services, which form an IoT platform, based on
the Information Centric Network (ICN) architecture, which we call
ICN-IoT. ICN-IoT leverages the salient features of ICN, and thus
provides seamless mobility support, security, scalability, and
efficient content and service delivery.
This draft describes representative IoT requirements and ICN
challenges to realize a unified ICN-IoT framework. Towards this, we
first identify a list of important requirements which a unified IoT
architecture should have to support tens of billions of objects, then
we discuss how the current IP-IoT overlay fails to meet these
requirements, followed by discussion on suitability of ICN for IoT.
Though we see most of the IoT requirements can be met by ICN, we
discuss specific challenges ICN has to address to satisfy them. Then
we provide discussion of popular IoT scenarios including the "smart"
home, campus, grid, transportation infrastructure, healthcare,
Education, and Entertainment for completeness, as specific scenarios
requires appropriate design choices and architectural considerations
towards developing an ICN-IoT solution.
"Web Linking", Mark Nottingham, 2016-05-02,
<draft-nottingham-rfc5988bis-01.txt>
This specification defines a way to indicate the relationships
between resources on the Web ("links") and the type of those
relationships ("link relation types").
It also defines the use of such links in HTTP headers with the Link
header field.
"Declarative Policy Model", Jun Bi, Qiong, Chongfeng Xie, Yiyong Zha,
2015-12-15, <draft-bi-declarative-policy-03.txt>
This document describes a declarative policy model to describe the
user's
declarative on network policy. The declarative policy model is a
specific data
model specifies the desired state of the network system.
It helps the service
management to model the policy (a set of states
described by constraints) that
defines the final results of a VPN
service without specifying how it is
monitored and managed during its
lifecycle. One application for Distributed
Data Center (DDC) scenarios
with policy enforcement is provided with details of
how to convert high
level declarative policy into lower level configurations.

"Delegating a Prefix to a Host for Multi-addressing Purposes", Fred

Templin, 2016-01-05, <draft-templin-v6ops-pdhost-01.txt>
IPv6 prefixes are typically delegated to requesting routers which
then use them to number their downstream-attached links and networks.
The requesting router then acts as a router between the downstreamattached hosts and the upstream provider network. The router could
also act as a host under the weak end system model, and otherwise
behaves as a standard router. This document considers the case when
the "requesting router" is actually a host, and receives a prefix
that it can use for multi-addressing purposes. The host does not
connect any downstream-attached networks, and uses the prefix solely
for its own multi-addressing purposes.
"TCP Tuning for HTTP", Daniel Stenberg, 2015-12-22,
<draft-stenberg-httpbis-tcp-01.txt>
This document records current best practice for using all versions of
HTTP over TCP.
"Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448",
Aris Adamantiadis, Simon Josefsson, 2016-03-01,
<draft-josefsson-ssh-curves-04.txt>
How to implement the Curve25519 and Curve448 key exchange methods in
the Secure Shell (SSH) protocol is described.
"RADIUS Extended Identifier Attribute", Sanal Kariyezhath, Aravind
Sridharan, 2015-11-06,
<draft-aravind-radext-extended-identifier-attribute-00.txt>
This document proposes solution to alleviate the limitation of
limited size (8 bits) of RADIUS Identifier field by proposing a new
Extended Identifier attribute.
"Dynamic Routed Network for Interconnection of Firewalls at Multiple
Geographic Locations", Chirag Sheth, Rajesh Thakker, 2015-11-10,
<draft-shet-opsawg-firewalls-interconn-00.txt>
Firewall performs resource intensive filtering of traffic based on
set of rules. A single firewall becomes a traffic bottleneck
depending on network expansion, number of connections and the
throughput required. This document describes a method of
interconnecting the firewalls at multiple geographic locations
through standalone network. It will enable firewall to dedicate its
full processing capacity to perform task of packet filtering. The
tasks of encryption, dynamic routing and anti-spoofing of traffic are
taken care outside firewall function. The placement of firewall and
routing device along with protocols to be used will form the proposed
system to improve overall network security and scalability.
"Selective route refresh for BGP", Anant, 2015-11-10,
<draft-utgikar-serr-00.txt>
This document proposes a new Route Refresh mechanism which provides
ability to perform route refresh for a smaller subset of updates than
the entire Adj-RIB-Out. It is applicable to multiple deployment
scenarios like , BGP-LS [I-D.draft-ietf-idr-ls-distribution-11] ,
EVPN [RFC7432]. The suggested capability will help faster
convergence and minimize overhead for routing policy changes. This

document updates [RFC7313].

"Cloud Tunneling Protocol (CTP)", Piotr Romanczyk, Christopher Colicino,
Michael Landi, Tomas Brodsky, 2016-05-05, <draft-honeywell-ctp-01.txt>
This specification defines operating semantics of the Cloud
Tunneling Protocol (CTP). CTP enables a standardized mechanism for
connecting Internet-of-Things (IoT) devices to hosted cloud
services. CTP provides a network efficient means to facilitate
multiple concurrent data conversations over the same channel by
providing multiplexed virtual sockets. The protocol allows for
services on either endpoint to be advertised and accessible to each
endpoint of the CTP connection.
"Restconf, HTTP, and HTTP2 Transport for YANG Push", Eric Voit, Alex
Clemm, Ambika Tripathy, Einar, Alberto Prieto, 2016-03-17,
<draft-voit-netconf-restconf-yang-push-02.txt>
This document defines YANG Subscription and Push mechanisms for
Restconf, HTTP, and HTTP2 transports.
"Software-Defined Networking (SDN)-based AAA Infrastructures
Management", Rafael Lopez, Gabriel Lopez-Millan, 2015-11-12,
<draft-marin-sdnrg-sdn-aaa-mng-00.txt>
This document describes the management of Authentication,
Authorization and Accounting (AAA) infraesctrutures by means of a
Software-Defined Network (SDN) controller and raises the requirements
to support this service. It considers the management of AAA routing
and the establishment of security associations between AAA entities.
"Command Reversal Extension for the Extensible Provisioning Protocol
(EPP)", Gavin Brown, Jothan, 2015-11-13,
<draft-brown-epp-reverse-00.txt>
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for reversing previous EPP commands.
"ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and
GMPLS Traffic Engineering", Mach Chen, Les Ginsberg, Stefano Previdi,
Xiaodong Duan, 2015-11-16, <draft-chen-isis-rfc5316bis-00.txt>
This document describes extensions to the ISIS (ISIS) protocol to
support Multiprotocol Label Switching (MPLS) and Generalized MPLS
(GMPLS) Traffic Engineering (TE) for multiple Autonomous Systems
(ASes). It defines ISIS-TE extensions for the flooding of TE
information about inter-AS links, which can be used to perform interAS TE path computation.
No support for flooding information from within one AS to another AS
is proposed or defined in this document.
This document obsoletes [RFC5316]
"A Performance Layer Inboard Computing method to support active, passive
and hybrid measurements", Tiziano Ionta, Antonio Cappadona, 2015-11-16,
<draft-ionta-plic-00.txt>
This document describes an innovative frame, called PLIC,("Performance
Layer Inboard Computing") able to support active, passive or hybrid

performance measurements on any kind of unicast and multicast service

passing through a network. It is based on an algorithm which, through
a distributed computation, floods the performance measurements of each
node to the rest of the network, without necessity of any external
topology database or operation support system. It has been invented
and engineered in the Telecom Italia Core Network.
"The Flexible Transmission Control Protocol (FTCP)", Martin Rosenau,
2015-11-17, <draft-rosenau-flexible-tcp-00.txt>
This document describes a protocol that may be used as replacement
for the Transmission Control Protocol (TCP).
The protocol allows changing the lower-layer address (such as IP
address) or even a change or the lower-layer protocol (e.g. from IPv4
to IPv6) in the middle of the connection.
Use cases are private peer-to-peer applications (such as computer
games) or mobile communication.
"Network Function Virtualization: Resource Orchestration Challenges",
Gino Carrozzo, Robert Szabo, Kostas Pentikousis, 2015-11-17,
<draft-caszpe-nfvrg-orchestration-challenges-00.txt>
Network function virtualization (NFV) promises improved operations in
terms of flexibility, efficiency, and manageability, but
orchestration, in general, and recursive orchestration, in
particular, is still an item of ongoing research. We summarize the
current state of the art in open-source initiatives in this area and
present current directions of research and development in terms of
orchestration, resource decomposition and federation, policy-based
resource management, measurement and analytics, and virtual network
function (VNF) elasticity.
"Segment Routing IPv6 Prefix-SID", Stefano Previdi, Les Ginsberg,
Clarence Filsfils, 2015-12-14,
<draft-previdi-isis-ipv6-prefix-sid-01.txt>
This
This
by a
IPv6

document defines the Segment Routing IPv6 Prefix-SID sub-TLV.

new sub-TLV allows to specify which of the prefixes advertised
node are to be used as Segment Routing Identifiers (SID) for the
dataplane.

"DLEP Destination Service Announcement", Rick Taylor, 2015-11-19,

<draft-taylor-manet-dlep-dsa-00.txt>
When using the Dynamic Link Exchange Protocol (DLEP)
[I-D.ietf-manet-dlep] to bootstrap neighbour discovery for routing
protocols there is no indication in the core DLEP protocol of the
services of the router announced at a destination. This forces an
implementation to either rely on a priori configuration or use
heuristic probing of well-known ports to discover potential routing
peers.
This document defines an extension to DLEP to enable a router to
advertise its active services to its peer modem, allowing a connected
remote modem to announce the services of a router in a DLEP
destination message to its peer, removing the need for service
discovery between routing peers. The mechanism is designed to be
sufficiently generic to allow the advertisement of network services

beyond routing protocols, enabling the fast bootstrapping of other

protocols such as messaging protocols or header compression.
"Certificate Transparency (CT) Browser Requirements", David Mandelberg,
Stephen Kent, 2015-11-19, <draft-dseomn-trans-browsers-00.txt>
This document describes the requirements for browsers in the
Certificate Transparency (CT) system, focusing on the Web PKI
context.
"A Method for Verification of Domain Name Ownership", Ben Golightly,
2015-11-20, <draft-bsag-domain-ownership-00.txt>
This document defines a method for website administrators to verify
ownership of a domain name to third party service providers.
"Experiences from Root Testbed in the Yeti DNS Project", Davey Song,
Shane Kerr, Dong Liu, 2015-12-27,
<draft-song-yeti-testbed-experience-01.txt>
This document reports and discusses issues in DNS root services,
based on experiences from the experiments in the Yeti DNS project.
These issues include IPv6-only operation, the root DNS server naming
scheme, DNSSEC KSK rollover, root server renumbering, multiple root
zone signer, and so on. This project was founded in May 2015 and has
since built a live root DNS server system testbed with volunteer root
server and resolver operations.
"DHCP configuration in MIF and associated IPR claim", Stjepan Gros,
Leonardo Jelenkovic, Dejan Skvorc, 2015-11-23,
<draft-sgros-dhcp-and-ipr-claim-analysis-00.txt>
The purpose of this draft is to analyze different options on how DHCP
can be used to configure PvD aware client. This is done in light of
IPR claim made by Huawei and the necessity to find an option for
implementation. In order for an option to be selected it obviously
must not interfere with IPR, or, IPR has to be somehow invalidated.
"v-event URI: An URI scheme for events.", Raphael Menderico, Paulo
Schlup, Lucia Kristiansen, 2015-11-23,
<draft-menderico-v-event-uri-00.txt>
This document defines the format of Uniform Resource Identifiers
(URIs) for calendar events, allowing users to add these events to
their calendar application from any source that defines them, like
web sites and printed QR codes
"Voluntary Application Server Identification for Web Push", Martin
Thomson, Peter Beverloo, 2016-01-31,
<draft-thomson-webpush-vapid-02.txt>
An application server can voluntarily identify itself to a push
service using the described technique. This identification
information can be used by the push service to attribute requests
that are made by the same application server to a single entity.
This can used to reduce the secrecy for push subscription URLs by
being able to restrict subscriptions to a specific application
server. An application server is further able include additional
information the operator of a push service can use to contact the
operator of the application server.

"Removing TCP's Initial Congestion Window", Mark Allman, 2015-11-24,

<draft-allman-tcpm-no-initwin-00.txt>
This specification removes the specification of TCP's initial
congestion window.
Terminology
"Certificate Transparency (CT) Requirements for Monitors and Auditors",
Stephen Kent, David Mandelberg, Karen Seo, 2015-11-24,
<draft-kent-trans-monitor-auditor-00.txt>
This document establishes requirements for the Monitor and Auditor
elements of the Certificate Transparency (CT) system, focusing on
the Web PKI context. It defines the functions performed by these
system elements. This is a companion to the CT System Architecture
document (draft-kent-trans-architecture).
"Certificate Transparency (CT) Certification Authority and Subject
Requirements", Karen Seo, David Mandelberg, Stephen Kent, 2015-11-24,
<draft-kseo-trans-ca-subject-00.txt>
This document describes the requirements for Certification
Authorities (CAs) and Subjects that elect to participate as elements
of the Certificate Transparency (CT) system, focusing on the Web PKI
context.
"Ordered Metric Adjustment Implementation Report", Shiqi Yang, Hongfang
Yu, Xudong Zhang, Nan Wu, 2015-11-24,
<draft-yang-rtgwg-oma-impl-report-00.txt>
Ordered Metric Adjustment (OMA) as specified in
[I-D.zxd-rtgwg-ordered-metric-adjustment] has provided a mechanism
whereby global transient forwarding loops can be avoided through
graceful link metric adjustment. This document provides an
implementation report for OMA algorithm and mechanism on different
network topologies. What's more, it gives an analysis on efficiency
and performance of OMA, comparing with other well-known looppreventing algorithm.
"Preference-based EVPN DF Election", Jorge Rabadan, Senthil Sathappan,
A. Przygienda, Wen Lin, Tapraj Singh, Ali Sajassi, satyamoh@cisco.com,
2015-11-25, <draft-rabadan-bess-evpn-pref-df-00.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.
"The chacha20-poly1305@openssh.com authenticated encryption cipher",
Jerome Marcon, Simon Josefsson, 2015-11-26,
<draft-josefsson-ssh-chacha20-poly1305-openssh-00.txt>
This document describes the chacha20-poly1305@openssh.com
authenticated encryption cipher supported by OpenSSH
"Security for Ubiquitous Green Community Control Network", Fengmin Li,
Zhimin Zhou, Lianshan Jiang, Yang Song, 2015-11-26,
<draft-li-ugccnet-security-00.txt>
This document describes enhanced security management function for the
protocol defined in "Ubiquitous Green Community Control Network",
specifies security requirements, defines system security
architecture, gives a standardized description of authentication,
authorization, along with security procedures and protocols. This
standard can avoid unintended data disclosure to the public and
unauthorized access to resources, while providing enhanced integrity
and confidentiality of transmitted data in the ubiquitous green
community control network.
"The Architecture for Ubiquitous Green Community Control Network",
Fengmin Li, Juchen Pan, Lianshan Jiang, Yang Song, 2015-11-26,
<draft-li-ugccnet-architecture-00.txt>
In this document, it identifies gateways for field-bus networks, data
storages for archiving and developing data sharing platform, and
application units to be important system components for developing
digital communities: i.e., building-scale and city-wide ubiquitous
facility networking infrastructure. The standard defines a data
exchange protocol that generalizes and interconnects these components
(gateways, storages, application units) over the IPv4/v6-based
networks. This enables integration of multiple facilities, data
storages, application services such as central management, energy
saving, environmental monitoring and alarm notification systems.
"Block-wise transfers in CoAP: Extension for Reliable Transport (BERT)",
Carsten Bormann, 2015-11-26, <draft-bormann-core-block-bert-00.txt>
CoAP (RFC7252) is a RESTful transfer protocol for constrained nodes
and networks, originally using UDP or DTLS over UDP as its transport.
Basic CoAP messages work well for the small payloads we expect from
temperature sensors, light switches, and similar building-automation
devices. CoAP's Block protocol (draft-ietf-core-block) allows
transferring larger payloads over limited-size datagrams -- for
instance, for firmware updates.
CoAP over TCP and TLS (draft-ietf-core-tcp-tls) enables the use of
extended, but not unlimited, size messages. The present
specification, Block-wise transfers in CoAP: Extension for Reliable
Transport (BERT), extends the block protocol in a simple way to be
able to make use of these larger messages over a reliable transport.
"The Security Evaluated Standardized Password Authenticated Key Exchange

(SESPAKE) Protocol", Stanislav Smyshlyaev, Evgeny Alekseev, Igor Oshkin,

Vladimir Popov, 2016-05-05, <draft-smyshlyaev-sespake-04.txt,.pdf>
This document specifies the Security Evaluated Standardized Password
Authenticated Key Exchange (SESPAKE) protocol. The SESPAKE protocol
provides password authenticated key exchange for usage in the systems
for protection of sensitive information. The security proofs of the
protocol was made for the case of an active adversary in the channel,
including MitM attacks and attacks based on the impersonation of one
of the subjects.
"YANG Schema Dispatching Language", Ladislav Lhotka, 2015-11-30,
<draft-lhotka-netmod-ysdl-00.txt>
This document defines YANG Schema Dispatching Language (YSDL). It is
a meta-schema language that allows for combining YANG modules into
any number of schemas, and arranging these schemas in a hierarchical
structure.
"Introduction and Overview of the Omnics System", Jerome Marcon,
2015-11-30, <draft-romosan-omnics-intro-00.txt>
The transcendence of the user-operator dichotomy through interactive
computing greatly empowered the programmers of early time-sharing
systems and subsequent operating systems. Earth is examined in the
light of history as the largest known time-sharing system in
operation, and Omnics, a synergistic planet operating system, is
proposed.
"Considerations for establishing resolution contexts for Internet
Names", Ted Hardie, 2016-03-07,
<draft-hardie-resolution-contexts-02.txt>
If we model the system of Internet names as a set of directed graphs
in an absolute naming context, following RFC 819, an Internet name is
not necessarily a name in the domain name system, but is simply a
unique name associated with a particular directed graph. The
resolution of the name, in other words, is independent from it being
an "Internet name". The DNS is a common, but not the only,
resolution context for Internet names. This document discusses the
consequences of the need to select among multiple resolution
contexts.
"RADIUS Extensions for IPv4-Embedded Multicast and Unicast IPv6
Prefixes", Qian Wang, Wei Meng, Cui Wang, Mohamed Boucadair, 2015-12-02,
<draft-wang-radext-multicast-radius-ext-00.txt>
This document specifies a new Remote Authentication Dial-In User
Service (RADIUS) attribute to carry the Multicast-Prefixes-64
information, aiming to delivery the Multicast and Unicast IPv6
Prefixes to be used to build multicast and unicast IPv4-Embedded IPv6
addresses. this RADIUS attribute is defined based on the equivalent
DHCPv6 OPTION_v6_PREFIX64 option.
"M-PIN: Zero-Knowledge two-factor authentication for digital identity",
Michael Scott, Brian Spector, Go Yamamoto, 2015-12-03,
<draft-scott-mpin-00.txt>
In this document, the M-PIN protocol for authentication of digital
identity is described. This protocol identifies a Client to a Server.

M-PIN requires an external Trusted Authority to issue secrets to

participating Clients and Servers.
"Network Service Header Timestamping", Rory Browne, Andrey Chilikin,
Brendan Ryan, Tal Mizrahi, Yoram Moses, 2015-12-04,
<draft-browne-sfc-nsh-timestamp-00.txt>
This draft describes a method of timestamping Network Service Header
(NSH) encapsulated packets or frames on service chains in order to
measure accurately hop-by-hop performance delays of application flows
carried within the chain. This method may be used to monitor
performance and highlight problems with virtual links (vlinks),
Virtual Network Functions (VNFs) or Physical Network Functions (PNFs)
on the Rendered Service Path (RSP).
"CBOR Web Token (CWT)", Erik Wahlstroem, Michael Jones, Hannes
Tschofenig, 2015-12-04, <draft-wahlstroem-ace-cbor-web-token-00.txt>
CBOR Web Token (CWT) is a compact means of representing claims to be
transferred between two parties. CWT is a profile of the JSON Web
Token (JWT) that is optimized for constrained devices. The claims in
a CWT are encoded in the Concise Binary Object Representation (CBOR)
and CBOR Object Signing and Encryption (COSE) is used for added
application layer security protection. A claim is a piece of
information asserted about a subject and is represented as a name/
value pair consisting of a claim name and a claim value.
"A review of implementation DNS over port 80/443", Shane Kerr, Davey
Song, Runxia Wan, 2016-05-04, <draft-shane-review-dns-over-http-03.txt>
The default DNS transport uses UDP on port 53. There are many
motivations why users or operators may prefer to avoid sending DNS
traffic in this way. A common solution is to use port 80 or 443;
with plain TCP, TLS-encrypted TCP, or full HTTP(S). This memo
reviews the possible approaches and delivers some useful information
for developers.
"Updates to Private Header (P-Header) Extension Usage in Session
Initiation Protocol (SIP) Requests/Responses", Christer Holmberg,
Nevenka Biondic, Gonzalo Salgueiro, 2016-04-27,
<draft-holmberg-dispatch-rfc7315-updates-06.txt>
The 3rd-Generation Partnership Project 3GPP has identified cases
where different SIP private header extensions referred to as Pheader fields, defined in RFC 7315, need to be included in SIP
requests and responses currently not allowed according to RFC 7315.
This document updates RFC 7315, in order to allow inclusion of the
affected P- header fields in such requests and responses.
This document also makes updates for RFC 7315 in order to fix
misalignments that occurred when RFC 3455 was updated and obsoleted
by RFC 7315.
"Signature Link Relation for Cryptographic Resource Verification", Sean
Palmer, 2015-12-08, <draft-palmer-signature-link-relation-00.txt>
This document specifies a way to associate web resources with their
corresponding digital signatures. A signature can then be verified
automatically during the process of downloading a resource.
Infomation presented to the user about the verification results may

enable them to make wiser security decisions about downloaded

content.
"A YANG Data Model for Declarative Policy", Tianran Zhou, Yinben Xia,
Bert Wijnen, 2015-12-09,
<draft-bw-supa-declarative-policy-data-model-00.txt>
This document describes a base YANG data model for declarative
policies that can be used within the SUPA (Simplified Use of Policy
Abstractions) framework. The base model can be augmented by
additional YANG modules defining data models for intent related
policies and functions to support various network scenarios and
applications. The base declarative policy data model provides common
building blocks for extensions.
"Using Codec Control Messages in the RTP Audio-Visual Profile with
Feedback with Layered Codecs", Stephan Wenger, Jonathan Lennox, Bo
Burman, Magnus Westerlund, 2015-12-09,
<draft-wenger-avtext-avpf-ccm-layered-00.txt>
This document fixes a shortcoming in the specification language of
the Codec Control Message Full Intra Request (FIR) as defined in
RFC5104 when using with layered codecs. In particular, a Decoder
Refresh Point needs to be sent by a media sender when a FIR is
received on any layer of the layered bitstream, regardless on whether
those layers are being sent in a single or in multiple RTP flows.
The other payload-specific feedback messages defined in RFC 5104 and
RFC 4585 as updated by RFC 5506 have also been analyzed, and no
corresponding shortcomings have been found.
"Intended status: Experimental A.Eromenko February 2016", Alexey
Eromenko, 2016-02-07, <draft-eromenko-ipff-lara-03.txt>
This document describes how-to correlate between IEEE 802.3 Ethernet
addresses and Internet Protocol "Five Fields" (IP-FF) addresses,
including unicasts, multicasts and duplicate address detection
mechanism, and the procedure to boot-up IPFF stack on Ethernet links.
"Intended status: Experimental A.Eromenko December 2015", Alexey
Eromenko, 2015-12-28, <draft-eromenko-ipff-mops-01.txt>
This document describes a mechanism, that can be used to live-migrate
opened TCP/UDP/other transport sessions between a mobile server and
a mobile client. This can work even after a mobile node moved to
a different subnet or disconnected, as long as a session did
not timeout.
It also describes limitations and includes NAT traversal scenarios
and guidelines for "middlebox" vendors.
"Intended status: Standards Track A.Eromenko March 2016", Alexey
Eromenko, 2016-03-02, <draft-eromenko-ipff-04.txt>
This document specifies version 5 of the Internet Protocol (IPv5).
a.k.a Internet Protocol Five Fields, that started as a hybrid
between IPv4 and IPv6, but solved problems in innovative ways,
and significantly improved on both.
"Intended status: Standards Track A. Eromenko March 2016", Alexey
Eromenko, 2016-03-02, <draft-eromenko-ipff-addressing-04.txt>

This specification defines the addressing architecture of the IP

Version 5 (IPFF) protocol. The document includes the IPFF addressing
model, text representations of IPFF addresses, definition of IPFF
unicast addresses, anycast addresses, and multicast addresses.
"Intended status: Standards Track", Alexey Eromenko, 2016-01-18,
<draft-eromenko-ipff-icmp-03.txt>
This document describes the format of a set of control messages used
in ICMPv5 (Internet Control Message Protocol). ICMPv5 is the
Internet Control Message Protocol for Internet Protocol Five Fields
(IPFF).
"Intended status: Standards Track A.Eromenko January 2016", Alexey
Eromenko, 2016-01-02, <draft-eromenko-ipff-udp-02.txt>
Minor modification of the UDP protocol to reduce overhead by 2 bytes.
Intended to be used with Internet Protocol "Five Fields".
"Intended status: Standards Track", Alexey Eromenko, 2016-01-18,
<draft-eromenko-ipff-dns-01.txt>
This document defines the changes that need to be made to the Domain
Name System (DNS) to support hosts running IP version 5 (IPFF). The
changes include a resource record type to store an IPFF address, a
domain to support lookups based on an IPFF address, and updated
definitions of existing query types that return Internet addresses as
part of additional section processing. The extensions are designed
to be compatible with existing applications and, in particular, DNS
implementations themselves.
"Delay Limits for Real-Time Services", Mirko Suznjevic, Jose Saldana,
2015-12-11, <draft-suznjevic-dispatch-delay-limits-00.txt,.pdf>
Network delay is one of the main factors which can degrade the
Quality of Experience (QoE) of network services. This document
surveys a set of recommendations about the maximum latency tolerated
by the users of services with delay constraints. Some
recommendations already exist for e.g. VoIP, but emerging services
as e.g. online gaming, have different requirements. Different papers
in the literature reporting these constraints are surveyed, and a
summary of the latency limits for each service is provided.
"Clarification on IMAP CAPABILITY command behaviour", Alexey Melnikov,
2015-12-11, <draft-melnikov-imap-capabilities-00.txt>
This document clarifies how IMAP (RFC 3501) server implementations
should handle CAPABILITY command.
"Performance Measurement Architecture for SFC", Gaurav Agrawal,
2015-12-11, <draft-agv-sfc-performance-measurement-architecture-00.txt>
This document describes passive performance measurement(PM)
architecture for Service Function Chains (SFCs) in a network. It
includes architectural concepts and principles for composite services
performance measurement when deployed as SFCs, This document does not
propose solutions, protocols, or extensions to existing protocols.
"Packet Loss Measurement for SFC", Gaurav Agrawal, 2015-12-11,
<draft-agv-sfc-packet-loss-measurement-00.txt>

Service provider service level agreements (SLAs) depend on the

capability to measure and monitor performance metrics for packet
loss.
The common reasons for packet drop are Link Congestion, Device
(Router/Switch/Firewall/etc.) Performance, Software issues (bugs) on
a network device, Faulty Hardware or Cabling and Service Function
processing errors.
Packet Loss Measurement capability also provides operators with
greater visibility into the performance characteristics of their
networks, thereby facilitating planning, troubleshooting, and network
performance evaluation.
This document specifies best possible efficient and accurate
mechanism for passive packet loss measurement for Service Function
Chains (SFCs) for a SFC network domain.
"Packet Delay Measurement for SFC", Gaurav Agrawal, 2015-12-11,
<draft-agv-sfc-packet-delay-measurement-00.txt>
Service provider service level agreements (SLAs) depend on the
capability to measure and monitor performance metrics for packet
Delay.
The common reasons for packet delay are Nodal processing(Algorithmic,
Packetization etc...), Queuing, Transmission delay, Propagation delay
and Service Function processing delay.
Packet Delay Measurement capability also provides operators with
greater visibility into the performance characteristics of their
networks, thereby facilitating planning, troubleshooting, and network
performance evaluation.
This document specifies best possible efficient and accurate
mechanism for passive packet delay measurement for Service Function
Chains (SFCs) for a SFC network domain.
"An approach to improve recursion performance", XiaoDong Lee, Hongtao
Li, Haikuo Zhang, Peng Zuo, 2015-12-11,
<draft-lee-dnsop-recursion-performance-improvement-00.txt,.pdf>
A recursive DNS server generally uses random port numbers to send
outbound requests to protect against DNS spoofing attacks. Due to
the limitation of operation system, a process typically can only open
numerable file descriptors simultaneously. This limit reduces
recursion performance of resolvers. This draft offers an approach to
improve both recursion performance and security for recursive
servers.
"AEAD Encryption Types for Kerberos 5", Luke Howard, 2015-12-13,
<draft-howard-krb-aead-00.txt>
This document updates RFC3961 to support encryption mechanisms that
can authenticate associated data, such as Counter with CBC-MAC (CCM)
and Galois/Counter Mode (GCM). These mechanisms are often more
performant and need not expand the message as much as conventional
modes.

"AEAD Modes for Kerberos GSS-API", Luke Howard, 2015-12-13,

<draft-howard-gssapi-aead-00.txt>
This document updates RFC4121 with support for encryption mechanisms
that can authenticate associated data such as Counter with CBC-MAC
(CCM) and Galois/Counter Mode (GCM). These mechanisms are often more
performant and need not expand the message as much as conventional
modes.
"Signaling Prefix Origin Validation Results from a Route-Server to
Peers", Thomas King, Daniel Kopp, Aristidis Lambrianidis, afenioux,
2016-04-26, <draft-kklf-sidr-route-server-rpki-light-01.txt>
This document defines the usage of the BGP Prefix Origin Validation
State Extended Community [I-D.ietf-sidr-origin-validation-signaling]
to signal prefix origin validation results from a route-server to its
peers. Upon reception of prefix origin validation results peers can
use this information in their local routing decision process.
"Unwritten Rules and Values of the IETF", Nalini Elkins, 2015-12-15,
<draft-elkins-ietf-unwritten-rules-values-00.txt>
The intent of this document is to speed up the process by which
someone new to the IETF, can understand the objectives, fathom the
environment, comprehend the culture, learn to navigate the problems,
overcome the obstacles, and become a more productive IETF
participant, in a shorter amount of time. Further, this document is
intended to pass along the learning and experiences of people who
have absorbed these values, perhaps in a much longer amount of time
and with much greater effort and even hardship.
"YANG module for LoRa Networks", Alexander Pelov, Laurent Toutain,
Yannick Delibie, Ana Minaburo, 2016-03-02,
<draft-pelov-yang-lora-01.txt>
This document presents a YANG module definition for managing LoRabased devices.
"YANG Structural Mount", Martin Bjorklund, 2016-02-26,
<draft-bjorklund-netmod-structural-mount-02.txt>
This document defines a mechanism to combine YANG modules into the
schema defined in other YANG modules.
"Verification Extension for the Extensible Provisioning Protocol (EPP)
Domain Name Mapping", Wang Wei, Linlin Zhou, Di Ma, Ning, XiaoDong Lee,
Jim Galvin, 2015-12-23, <draft-wang-eppext-domain-verification-01.txt>
This mapping describes an verification extension to EPP domain name
mapping [RFC5731]. Specified in Extensible Markup Language (XML),
this extended mapping is applied to provide additional features
required for the provisioning of domain verification.
"Verification Extension for the Extensible Provisioning Protocol (EPP)
Contact Mapping", Linlin Zhou, Di Ma, Wang Wei, Ning, XiaoDong Lee, Jim
Galvin, 2015-12-23, <draft-zhou-eppext-contact-verification-01.txt>
This mapping describes an verification extension to EPP contact
mapping [RFC5733]. Specified in Extensible Markup Language (XML),
this extended mapping is applied to provide additional features

required for the provisioning of contact verification.

"Automatic Assignment of BIER BFR-ids in OSPF", Zheng Zhang, Cui Wang,
2015-12-21, <draft-zhang-bier-bfrid-assignment-00.txt>
[I-D.ietf-bier-architecture] has introduced a new method to forward
multicast flow, without explicit multicast states storing in every
node along the multicast paths. This document introduces a method to
allocate BFR-id automatically through OSPF extension.
"CONFORMANCE OF ACROSSING NON-BIER NODES", Zheng Zhang, fangwei hu,
2015-12-21, <draft-zhang-bier-across-non-bier-nodes-00.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. There may be
some routers which could not support BIER technology (We name them as
non-BIER node in this document) in the BIER domain when deployed.
This document specifies a solution for the BIER packet transiting the
non-BIER nodes.
"BIER Ethernet", Cui Wang, Zheng Zhang, Andrew Qu, 2016-03-15,
<draft-wang-bier-ethernet-01.txt>
Bit Index Explicit Replication (BIER) [I-D.ietf-bier-architecture] 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. When a multicast
data packet enters the BIER domain, the BFIR determines the BFERs to
which the packet needs to be sent. Then the BFIR encapsulates the
packet in a BIER header and forwards the packet according to the
BIFTs. Currently, there is a BIER-MPLS solution to transmit
multicast traffic using MPLS label indication. Alternatively, this
document tries to propose a solution named BIER Ethernet to support
BIER forwarding in Ethernet network.
"Path Autogeneration in BIER", Zheng Zhang, Wu Bo, Cui Wang, 2016-03-06,
<draft-zhang-bier-path-autogeneration-01.txt>
[I-D.ietf-bier-architecture] BIER introduces a method for multicast
flow forwarding, without storing states in every node along the
multicast path. This document introduces a method of establishing
multicast path automatically.
"DSR Extensions for the Resolution of Cached Route Reply Implosion",
Sanghyun Ahn, 2015-12-22, <draft-ahn-manet-dsr-crri-00.txt>
In DSR, a node can generate a route reply in response to a received
route request if it has a fresh route to the destination in its
route cache. However, this can incur the cached route reply problem
and DSR just tries to mitigate this problem by reducing the
possibility of cached route reply collisions. This document
describes how DSR can be extended for the resolution of the cached
route reply problem.
"Architecture of Multipath Routing Protocols for MANET", Sanghyun Ahn,
2015-12-22, <draft-ahn-manet-multipath-architecture-00.txt>

This document describes the architecture on the protocols providing

multiple routes between a given source and destination node pair
in a mobile ad hoc network (MANET).
"DSR Extensions for Multipath Routing", Sanghyun Ahn, 2015-12-22,
<draft-ahn-manet-multipath-dsr-00.txt>
This document describes how DSR [1] can be extended for the support
of MANET multipath routing. Since DSR uses the source routing
approach, it can be appropriate for multipath routing.
Therefore, in this draft, we describe how we can extend DSR for
finding multiple routes from the source to the destination.
"Requirements on Multipath Routing Protocols for MANET", Sanghyun Ahn,
2015-12-22, <draft-ahn-manet-multipath-requirement-00.txt>
This document describes the requirements on the protocols providing
multiple routes between a given source and destination node pair
in a mobile ad hoc network (MANET). For this, the conditions to be
considered in defining a MANET multipath routing protocol are
listed.
"DSR Extensions for Network Coding Capability", Sanghyun Ahn,
2015-12-22, <draft-ahn-manet-networkcoding-dsr-00.txt>
This document describes how DSR [1] can be extended for the support
of network coding capability in the MANET. Because the network coding
capability increases the wireless network capacity, in this draft,
we describe how we can extend DSR for the support of the network
coding capability.
"Requirements on Network Coding Support in MANET", Sanghyun Ahn,
2015-12-22, <draft-ahn-manet-networkcoding-requirement-00.txt>
This document describes the requirements on providing the network
coding capability in the mobile ad hoc network (MANET). For this,
the conditions to be considered in providing the network coding
capability in the MANET are listed.
"RTGWG PathID Engineering", Ting Liao, Ting Ao, 2015-12-24,
<draft-lt-rtgwg-pathid-engineering-00.txt,.pdf>
With the deployment of centralized control, the traffic scheduling
can be easier to accomplish with PathID carried in the data plane. A
PathID used to indicate a flow through a forwarding path which is not
the default shortest path. It is encapsulated in the packet at the
ingress node, carried to indicate the forwarding at the transit node
and decapsulated at the egress node.
This document describes how to accomplish flexible forwarding with
PathID in traffic scheduling.
"PCEP Extensions for BIER", Ran Chen, Zheng Zhang, 2015-12-25,
<draft-chen-bier-pce-bier-00.txt>
Bit Index Explicit Replication (BIER)-TE shares architecture and
packet formats with BIER as described in
([I-D.ietf-bier-architecture]). BIER-TE forwards and replicates
packets based on a BitString in the packet header, but every
BitPosition of the BitString of a BIER-TE packet indicates one or

more adjacencies.BIER-TE Path can be derived from a Path Computation

Element (PCE).
This document specifies extensions to the Path Computation Element
Protocol (PCEP) to handle requests and responses for the computation
of paths for BIER-TE.
"Compression in the Internet Key Exchange Protocol Version 2 (IKEv2)",
Valery Smyslov, 2016-03-14,
<draft-smyslov-ipsecme-ikev2-compression-01.txt>
This document describes a method for reducing the size of the IKEv2
messages by using lossless compression. Making IKEv2 messages
smaller is desirable for low power consumption battery powered
devices. It also helps to avoid IP fragmentation of IKEv2 messages.
This document describes how compression is negotiated maintaining
backward compatibility and how it is used in IKEv2.
"Intended status: Standards Track A.Eromenko January 2016", Alexey
Eromenko, 2016-01-02, <draft-eromenko-ipff-babysitter-01.txt>
Babysitter is a form of an advanced NAT, mostly for desktop clients.
It gives mixed IP-FF and IPv4 clients access to IPv4-only Internet.
It is somewhat resembling NAT64 + DNS64 combo, and will aid during
transition period.
Assumption: We work on IPv4-only Internet, but we want to implement
both IP-FF and IPv4 hosts inside our organization, so nodes can work
between themselves with, and take advantage of, IP-FF, but still
able to connect to the Internet.
If/when this assumption is invalid, and end-to-end IP-FF becomes
commonplace, other forms of connection should be used,
and babysitter may be disabled.
"Intended status: Standards Track", Alexey Eromenko, 2016-01-02,
<draft-eromenko-ipff-dhcp-01.txt>
This document describes the changes needed from DHCPv4, as defined in
RFC-2131, to bring DHCP to IP-FF.
"Intended status: Standards Track A.Eromenko March 2016", Alexey
Eromenko, 2016-03-02, <draft-eromenko-ipff-tcp64-03.txt>
This document attempts to modernize TCP protocol for new reality,
faster bandwidth, encryption-optimization and optional checksums,
which is required for Identity-Locator Network Protocol (ILNP)
compatibility.
This extension is backwards compatible with the original TCP
specification during session establishment, but not compatible
during the rest of the session nor with deployed middleboxes.
"Intended status: Standards Track A.Eromenko December 2015", Alexey
Eromenko, 2015-12-28, <draft-eromenko-ethernet-over-udp-tunnel-00.txt>
This technique is simple to implement, and provides an effective
tunnel between two LAN segments (Ethernet Broadcast Domains).
"Global NAT64 translation system (GlobalNAT64)", Martin Rosenau,
2015-12-29, <draft-rosenau-global-nat64-00.txt>

This document describes an idea of a IPv6-to-IPv4 translation method.

The advantage of the method is that the required public IPv4
addresses are shared between the internet providers (and even between
the RIRs) so there are less IPv4 addresses required for IPv6-to-IPv4
translation mechanisms (NAT64, DS-Lite, 464XLAT).
The main disadvantage is that an IPv4 address range would have to be
reserved for this method.
"DTN Security Best Practices", Edward Birrane, 2015-12-29,
<draft-birrane-dtn-sec-practices-00.txt>
This document describes best practices associated with achieving a
variety of security use cases with the set of DTN-related standards.
"NetInf Live Video Specification", Bengt Ahlgren, Borje Ohlman, Adeel
Malik, 2015-12-30, <draft-ahlgren-icnrg-netinf-live-video-00.txt>
This document specifies how the NetInf information-centric network
service can be used for transport of live video streaming. To
illustrate this it describes a prototype system that was developed to
be used at "events with large crowds", e.g., sports events. The
specification defines how the used video format is mapped to NetInf
named data objects (NDOs). It also describe how NetInf messages are
used to transfer the NDOs.
"Bundle Protocol Agent Application Data Model", Edward Birrane,
2015-12-31, <draft-birrane-dtn-adm-bp-00.txt>
This document describes an Application Data Model (ADM) for a Bundle
Protocol Agent (BPA). This ADM identifies the Primitive Values,
Computed values, Reports, Controls, Macros, Literals, Operators, and
meta-data associated with a BPA. The information outlined in this
document MUST be supported by any software claiming to act as a
managed BPA within the Asynchronous Management Protocol (AMP).
"Suite B Ciphersuites for Bundle Protocol Security (BPSec)", Edward
Birrane, 2015-12-31,
<draft-birrane-dtn-bpsec-suiteb-ciphersuites-00.txt>
This document proposes ciphersuites to be used for Bundle Protocol
Security (BPSec). These new ciphersuites provide compatibility with
the United States National Security Agency's Suite B specifications.
"Suite B Profile for Bundle Protocol Security (BPSec)", Edward Birrane,
2015-12-31, <draft-birrane-dtn-bpsec-suiteb-profile-00.txt>
The United States Government has published guidelines for "NSA Suite
B Cryptography" dated July, 2005, which defines cryptographic
algorithm policy for national security applications. This document
specifies the conventions for using Suite B cryptography with Bundle
Protocol Security (BPSec).
Since many of the Suite B algorithms enjoy uses in other environments
as well, the majority of the conventions needed for the Suite B
algorithms are already specified in other documents. This document
references the source of these conventions, with some relevant
details repeated to aid developers that choose to support Suite B
within BPSec.

"Nameserver objects sharing the same name, support for the Registration
Data Access Protocol (RDAP)", Gustavo Lozano, 2016-04-22,
<draft-lozano-rdap-nameservers-sharing-name-01.txt>
This document describes a Registration Data Access Protocol (RDAP)
extension that may be used to retrieve the registration information
of a particular nameserver object sharing the name with other
nameserver objects.
"Cache Digests for HTTP/2", Kazuho Oku, Mark Nottingham, 2016-01-06,
<draft-kazuho-h2-cache-digest-00.txt>
This specification defines a HTTP/2 frame type to allow clients to
inform the server of their cache's contents. Servers can then use
this to inform their choices of what to push to clients.
Note to Readers
The issues list for this draft can be found at
https://github.com/mnot/I-D/labels/h2-cache-digest .
The most recent (often, unpublished) draft is at
https://mnot.github.io/I-D/h2-cache-digest/ .
Recent changes are listed at https://github.com/mnot/I-D/commits/ghpages/h2-cache-digest .
"A MILP Model to Solve the Problem of Loading Balance of Routing and
Wavelength Assignment for Optical Transport Networks", Shan Yin, Shanguo
Huang, Dajiang Wang, Xuan Wang, Yu Zhang, 2016-04-19,
<draft-yin-milp-rwa-otn-02.txt>
The RWA problem can be formulated as a Mixed-Integer linear program.
Load balancing is a key factor for the optical transport networks.
However, the existed approaches using mixed-Integer linear program to
solve the RWA problem are not perfect enough without considering the
load balancing of the networks.
This documentary provides a model of Mixed-Integer Linear Programming
to solve the problem of load balancing needed by routing and
wavelength assignment (RWA) process in optical transport networks.
"TLS Extension for DANE Client Identity", Shumon Huque, Viktor Dukhovni,
2016-01-08, <draft-huque-tls-dane-clientid-00.txt>
This document specifies a TLS and DTLS extension to convey a DNSBased Authentication of Named Entities (DANE) Client Identity to a
TLS or DTLS server. This is useful for applications that perform TLS
client authentication via DANE TLSA records.
"SMTP Require TLS Option", Jim Fenton, 2016-02-13,
<draft-fenton-smtp-require-tls-01.txt>
The SMTP STARTTLS option, used in negotiating transport-level
encryption of SMTP connections, is not as useful from a security
standpoint as it might be because of its opportunistic nature;
message delivery is prioritized over security. This document
describes a complementary SMTP service extension, REQUIRETLS. If the
REQUIRETLS option is used when sending a message, it causes message

delivery to fail if a TLS connection with the required security

characteristics cannot be completed with the next hop MTA or if that
MTA does not also advertise that it supports REQUIRETLS. Message
originators may therefore expect transport security to be used for
messages sent with this option.
"BIER Split-horizon mechanism for active-active access", Hao Weiguo, Li
Yizhou, Shunwan Zhuang, 2016-01-10,
<draft-hao-bier-active-active-00.txt>
This document proposes a BIER split-horizon mechanism for activeactive access. Both data plane and control plane extension are
included.
"CalDAV Calendar Sharing", evert, Cyrus Daboo, Eric <>, 2016-01-11,
<draft-pot-caldav-sharing-00.txt>
This specification defines sharing calendars between users on a
CalDAV server.
"Updated DNSSEC-based TLS Server Identity Check Procedure for Email
Related Protocols", Alexey Melnikov, 2016-01-12,
<draft-melnikov-uta-dnssec-email-tls-certs-00.txt>
This document describes DNSSEC-based TLS server identity verification
procedure for SMTP Submission, IMAP, POP and ManageSieve clients.
"The Use of Non-ASCII Characters in RFCs", Heather Flanagan, 2016-04-27,
<draft-iab-rfc-nonascii-02.txt,.pdf>
In order to support the internationalization of protocols and a more
diverse Internet community, the RFC Series must evolve to allow for
the use of non-ASCII characters in RFCs. While English remains the
required language of the Series, the encoding of future RFCs will be
in UTF-8, allowing for a broader range of characters than typically
used in the English language. This document describes the RFC Editor
requirements and guidance regarding the use of non-ASCII characters
in RFCs.
This document updates RFC 7322. Please review the PDF version of
this draft.
"Using PPP as an LTP Convergence Layer", Brian Sipos, 2016-01-13,
<draft-bsipos-dtn-ppp-ltp-clayer-00.txt>
This document specifies a method for transporting Licklider
Transmission Protocol segments over a Point-to-Point Protocol data
link.
"JSON Web Service Binding Version 1.0", Phillip Hallam-Baker,
2016-03-07, <draft-hallambaker-json-web-service-02.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 version 2
is outside the scope of this document.
"Mathematical Mesh: Architecture", Phillip Hallam-Baker, 2016-03-07,
<draft-hallambaker-mesh-architecture-01.txt>
The Mathematical Mesh 'The Mesh' is an end-to-end secure
infrastructure that facilitates the exchange of configuration and
credential data between multiple user devices. The architecture of
the Mesh and examples of typical applications are described.
"Mathematical Mesh: Reference", Phillip Hallam-Baker, 2016-03-07,
<draft-hallambaker-mesh-reference-02.txt>
The Mathematical Mesh 'The Mesh' is an end-to-end secure
infrastructure that facilitates the exchange of configuration and
credential data between multiple user devices. The core protocols of
the Mesh are described with examples of common use cases and
reference data.
"Mathematical Mesh: Developer's Guide", Phillip Hallam-Baker,
2016-03-07, <draft-hallambaker-mesh-developer-01.txt>
The Mathematical Mesh 'The Mesh' is an end-to-end secure
infrastructure that facilitates the exchange of configuration and
credential data between multiple user devices.
This document describes how to install and run the Mesh reference
code and make use of the reference code in applications. It does not
form a part of the Mesh specifications and is not normative.
"DNS Extension to provide Default (Preferred) Protocol", Piotr
Kupisiewicz, 2016-02-01, <draft-pkupisie-dnsop-dprot-01.txt>
This document defines extension to the Domain Name System to support
Default Protocol. Default Protocol extension allows owners of the
resources to determine which are preferred protocols to be used with
their Services (i.e. https protocol to be preferred instead of http
for specific servers).
"Considerations for stateful vs stateless join router in ANIMA
bootstrap", Michael Richardson, 2016-01-16,
<draft-richardson-anima-state-for-joinrouter-00.txt>
This document explores a number of issues affecting the decision to
use a stateful or stateless forwarding mechanism by the join router
(aka join assistant) during the bootstrap process for ANIMA.
"Privacy considerations for IP broadcast and multicast protocol
designers", Rolf Winter, Michael Faath, Fabian Weisshaar, 2016-03-21,
<draft-winfaa-intarea-broadcast-consider-01.txt>
A number of application-layer protocols make use of IP broadcasts or
multicast messages for functions such as local service discovery or
name resolution. Some of these functions can only be implemented
efficiently using such mechanisms. When using broadcasts or
multicast messages, a passive observer in the same broadcast domain
can trivially record these messages and analyze their content.
Therefore, broadcast/multicast protocol designers need to take

special care when designing their protocols.

"Using DNS Names in the IETF ACL Model", Eliot Lear, 2016-01-19,
<draft-lear-ietf-netmod-acl-dnsname-00.txt>
End points are commonly referenced by higher level functions through
the DNS. This is especially the case in cloud-based functions, which
might have hundreds of IP addresses for the same name. This brief
memo extends the IETF-ACL model to allow access-control via domain
names.
"RADIUS Extensions for Network-Assisted Multipath TCP (MPTCP)", Mohamed
Boucadair, Christian Jacquenet, 2016-01-19,
<draft-boucadair-mptcp-radius-01.txt>
One of the promising deployment scenarios for Multipath TCP (MPTCP)
is to enable a Customer Premises Equipment (CPE) that is connected to
multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its
network attachments. Because of the lack of MPTCP support at the
server side, some service providers consider a network-assisted model
that relies upon the activation of a dedicated function called: MPTCP
Concentrator.
This document specifies a new Remote Authentication Dial-In User
Service (RADIUS) attributes that carry the IP addresses that allow
CPE devices to reach one or multiple MPTCP Concentrators.
"DMARC Extensions for DANE", Eric Osterweil, Glen Wiley, 2016-01-19,
<draft-osterweil-dmarc-dane-names-00.txt>
This document proposes additions to the Domain-based Message
Authentication, Reporting, and Conformance (DMARC) Tag Registry to
enable Mail administrators to specify the domain-wide policies for S/
MIME and PGP key usage in their mail domains, in conjunction with use
of the DANE SMIMEA and OPENPGPKEY resource records. This would mean
adding to the authentication mechanisms specified in RFC 7489, but it
would specify only the domain-wide policies for S/MIME and PGP, such
as what the policies are for signing and encrypting (does the sender
mandate it, not allow it, etc.). This document also suggests the
specification of the type of encoding of the left-hand sides used in
the DANE resource records.
"DNS message fragments", Mukund Sivaraman, Shane Kerr, Davey Song,
2016-01-19, <draft-muks-dnsop-dns-message-fragments-00.txt>
This document describes a method to transmit DNS messages over
multiple UDP datagrams by fragmenting them at the application layer.
The objective is to allow authoriative servers to successfully reply
to DNS queries via UDP using multiple smaller datagrams, where larger
datagrams may not pass through the network successfully.
"TLS/DTLS Content Provider Edge Server Split Use Case", Daniel Migault,
Kevin Ma, 2016-01-19, <draft-mglt-lurk-tls-use-cases-00.txt>
TLS as been designed to setup and authenticate transport layer
between endpoints.
A lot of applications are using TLS in order to set communications
between the applications end points.

As long as applications end points and transport end points were

combined into the same host, application authentication could be
combined with the transport authentication.
As the current internet is decoupling the transport and application
layers, such model may not be applicable anymore. In other words,
TLS authentication cannot be handled on behalf of the application
authentication.
This document describes use cases where the authentication of the
transport layer differs from the authentication performed at the
application layer.
"Authentication Model and Security Requirements for the TLS/DTLS Content
Provider Edge Server Split Use Case", Daniel Migault, Kevin Ma,
2016-01-19, <draft-mglt-lurk-tls-requirements-00.txt>
In the TLS/DTLS Content provider Edge Server Split use case, a TLS
Client uses TLS/DTLS to authenticates the Content Provider while
establishing a TLS/DTLS session with the Edge Server. Such
authentication scheme is designated as Split Authentication in this
document.
In most cases, the Edge Server does not even belong to the Content
Provider, but instead to a third party like, for example, a Content
Delivery Network. As a result, the Content Provider and the Edge
Server must be able to interact and/or share some information.
Interactions and shared information constitutes a split
authentication model varies with the authentication method involved
in the TLS session.
For each TLS/DTLS authentication method, the document provides the
associated split authentication model that makes possible a split
authentication. The split authentication model is associated to
security requirements and an analysis to show it does not introduce
any weakness compared to the standard TLS authentication model.
"Manufacturer Usage Description URI and DHCP Option", Eliot Lear, Ralph
Droms, 2016-03-01, <draft-lear-ietf-dhc-mud-option-01.txt>
The ability of smart objects to protect themselves will vary. A good
source of information about a device's capabilities is the
manufacturer. This document specifies a means by which devices can
communicate a URI that the network can use to retrieve simple
network-relevant information.
"Manufacturer Usage Description Framework", Eliot Lear, 2016-01-21,
<draft-lear-mud-framework-00.txt>
A key presumption of the Internet architecture has been that devices
are general purpose computers. By constraining the set of devices
that connect to the Internet to non-general purpose devices, we can
introduce a set of network capabilities that provides an additional
layer of protection to those devices. One such capability is the
Manufacturer Usage Description (MUD). This work builds on many
existing network capabilities so as to be easily deployable by all
involved. The focus of this work is primarily, but not exclusively,
in the realm of security; and again primarily, but not exclusively,
relating to smart objects.

"Registrar Registration Expiration Date Extension Mapping for the

Extensible Provisioning Protocol (EPP)", Gustavo Lozano, 2016-01-21,
<draft-lozano-ietf-eppext-registrar-expiration-date-00.txt>
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of the
registrar registration expiration date for domain names stored in a
shared central repository. Specified in XML, this mapping extends
the EPP domain name mapping.
"Manufacturer Usage Description YANG Model", Eliot Lear, 2016-03-04,
<draft-lear-ietf-netmod-mud-01.txt>
This memo specifies a YANG model to be used to generate and parse
manufacturer usage descriptions. These descriptions are retrieved by
network management systems in order to instantiate policies
associated with those devices. This memo also specifies a well known
URI suffix to indicate that a file contains XML derived from this
model.
"PCEP Extensions for Reporting MPLS-TE LSP Performance Measurements",
Rakesh Gandhi, Bin Wen, 2016-01-22, <draft-gandhi-pce-pm-00.txt>
In certain networks, network performance data such as packet loss,
delay and delay variation (jitter) is a critical measure for traffic
engineering. This data provides operators the characteristics of
their networks for performance evaluation that is required to ensure
the Service Level Agreements (SLAs). Performance measurement
mechanisms can be employed to measure these metrics for TE LSPs in
real-time. This document describes PCEP extensions for reporting
such performance measurements to an Active Stateful PCE.
"NSH Security and Privacy requirements", Tirumaleswar Reddy, Daniel
Migault, Carlos Pignataro, Paul Quinn, Christopher Inacio, 2016-01-22,
<draft-reddy-sfc-nsh-security-req-00.txt>
This document defines Network Service Header (NSH) security and
privacy requirements.
"A Model Based Approach to Dynamic Service Chaining",
jonachin@cisco.com, 2016-02-03,
<draft-chin-nfvrg-model-dynamic-service-chain-01.txt,.pdf>
In the context of Network Function Virtualization (NFV), a service
chain refers to a group of Virtual Network Functions (VNFs) deployed
in a virtual infrastructure manager (VIM) environment, such as
OpenStack, to apply a set of networking services to users' traffic
passing through it.
Depending on the service requirements, the service chain may consist
of a single VNF or multiple VNFs deployed serially, or in parallel,
and the Virtual Network Forwarding Graph (VNF-G) describes the
topologies of how these VNFs are interconnected together via virtual
links to provide different networking services.
After a service chain is deployed, its user may require to modify
the VNF-G from time to time, and on-demand, to meet changing service
requirements. Therefore, operators may require to support a high
degree of flexibility to orchestrate the provisioning and dynamic
modifications of VNFs in service chains.

This document presents a hierarchical model based approach to allow

the NFV Orchestrator (NFV-O) and the VNF Manager (VNF-M) to support
the dynamic provisioning and on-demand modifications of VNFs in
service chains.
"M-PIN FULL : Zero Knowledge two-Factor Authentication and Key
Exchange", Michael Scott, Brian Spector, Stanislav Mihaylov, 2016-01-26,
<draft-scott-mpinfull-00.txt>
In this document, the M-PIN FULL protocol for two factor
authentication and key exchange is described. This protocol mutually
identifies a Client to a Server and the Server to the Client, and
agrees between them a cryptographic strong encryption key for
subsequent communication. M-PIN FULL requires an external Trusted
Authority to issue secrets to participating Clients and Servers.
"Information Model for SFC Metadata", sunilvk@f5.com, David Dolson,
2016-01-28, <draft-vallamkonda-sfc-metadata-model-00.txt>
Various types of metadata are applicable to Service Function Chaining
(SFC). A Service Function (SF) needs information about all metadata
passing through it. The metadata could be used to convey
preprocessing information about the packet by other nodes and an SF
can attach post processing information as deemed necessary.
The purpose of this document is to rigorously define the classes of
metadata and provide a vocabulary and information model for metadata.
Each item of metadata refers to a subject, examples of which are IP
endpoint, flow or individual packet.
"Special Use Domain Name 'ipv4only.arpa'", Stuart Cheshire, David
Schinazi, 2016-01-28, <draft-cheshire-sudn-ipv4only-dot-arpa-00.txt>
The document "Discovery of the IPv6 Prefix Used for IPv6 Address
Synthesis" [RFC7050] specifies the Special Use Domain Name
'ipv4only.arpa', with certain precise special properties, but
neglected to include a Domain Name Reservation Considerations section
[RFC6761] formalizing those special properties. This document
updates RFC 7050 and formally specifies the Special Use Domain Name
rules for ipv4only.arpa.
"Merkle Integrity Content Encoding", Martin Thomson, 2016-01-28,
<draft-thomson-http-mice-00.txt>
This memo introduces a content-coding for HTTP that provides
progressive integrity for message contents. This integrity
protection can be evaluated on a partial representation, allowing a
recipient to process a message as it is delivered while retaining
strong integrity protection. The integrity protection can optionally
be authenticated with a digital signature.
"Need for Internet Applications to support pen interfaces", pradeep
xplorer, 2016-01-29, <draft-httpscribed-00.txt>
This document describes the need for internet applications to support
pen interfaces
"Benchmarking Performance Monitoring on a DUT", Praveen Ananthasankaran,

2016-01-29, <draft-jacpra-bmwg-pmtest-00.txt>
This draft is proposed for benchmarking the Y1731 performance
monitoring on DUT in various scenarios.
"Benchmarking Methodology for EVPN", Kishore Tiruveedhula, 2016-01-31,
<draft-kishjac-bmwg-evpntest-00.txt>
This document defines the methodologies for benchmarking performance
of EVPN. EVPN been implemented with many varying designs in order to
achieve their intended network functionality.
"Uniform Resource Name (URN) Namespaces for Broadband Forum", Barbara
Stark, David Sinicrope, William Lupton, 2016-04-04,
<draft-bbf-bbf-urn-01.txt>
This document describes the Namespace Identifiers (NIDs) 'bbf',
'broadband-forum-org', and 'dslforum-org' for Uniform Resource Names
(URNs) used to identify resources published by Broadband Forum (BBF).
BBF specifies and manages resources that utilize these three URN
identification models. Management activities for these and other
resource types are handled by BBF.
"The Use of Registries", Erik Wilde, 2016-02-03,
<draft-wilde-registries-01.txt>
Registries on the Internet and the Web fulfill a wide range of tasks,
ranging from low-level networking aspects such as packet type
identifiers, all the way to application-level protocols and
standards. This document summarizes some of the reasons of why and
how to use registries, and how some of them are operated. It serves
as a informative reference for specification writers considering
whether to create and manage a registry, allowing them to better
understand some of the issues associated with certain design
discussions.
"Updating the ex officio member of the IAB in the IAOC", Ted Hardie,
Andrew Sullivan, Russ Housley, 2016-02-18,
<draft-hardie-iaoc-iab-update-02.txt>
This document updates the way in which the ex officio member from the
IAB who serves on the IAOC is appointed in order to better match the
skills set out in RFC 4333.
"An X.509 Extension for Manufacturer Usage Description URI", Eliot Lear,
2016-02-02, <draft-lear-ietf-pkix-mud-extension-00.txt>
Manufacturer User Descriptions are used by device manufacturers to
provide indications to the network as to the intended use of a
particular device and with what end points it might communicate. A
URI points to those descriptions. This memo specifies an X.509
certificate extension to specify that URI in a device certificate to
be used with IEEE 802.1AR.
"PKCS #1 Version 2.2: RSA Cryptography Specifications", Kathleen
Moriarty, Burt Kaliski, Jakob Jonsson, A. Rusch, 2016-04-06,
<draft-moriarty-pkcs1-01.txt>
This memo represents a republication of PKCS #1 v2.2 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series. By

publishing this RFC, change control is transferred to the IETF.

"DOTS over GRE", Robert Moskowitz, Jinwei Xia, 2016-02-03,
<draft-moskowitz-dots-gre-00.txt>
This document describes using a GRE tunnel to deliver DOTS messages
between DOTS agents and compares it to other methods.
"IKEv2 Multihoming support", N. Kumar, 2016-02-03,
<draft-suresh-ipsecme-ikev2-multihoming-support-00.txt>
Multihoming provides devices the ability to connect to multiple
networks and thus, provide higher throughput and improved resilience
to network failure(s).
This document describes enhancement of Internet Key Exchange version
2 protocol [IKEv2] to support multihoming to avoid redundant IKE
negotiations to create and maintain tunnel for multiple connections
possible between the tunnel peers.
"System for Cross-Domain Identity Management: Discovery", Phil Hunt,
2016-02-03, <draft-hunt-scim-discovery-00.txt>
The System for Cross-Domain Identity Management (SCIM) specifications
are designed to enable identity provisioning in cloud based
applications and web services easier using HTTP protocol. This
specification defines a method for discovering a SCIM service
provider using the "/.well-known" mechanism and optional support for
WebFinger queries.
"Allowing inheritable NFSv4 ACLs to override the umask", J. Fields,
Andreas Gruenbacher, 2016-02-22, <draft-bfields-nfsv4-umask-01.txt>
In some environments, inheritable NFSv4 ACLs can be rendered
ineffective by the application of the per-process umask. This is
easily worked around by transmitting the umask and create mode
separately to allow servers to make more intelligent decisions about
the new mode on a file.
"A Uniform Resource Name (URN) Namespace for Enterprise YANG Modules",
I. Chen, 2016-03-18, <draft-chen-rdns-urn-06.txt>
This document describes the Namespace Identifier (NID) for Uniform
Resource Namespace (URN) resources to uniquely identify enterprise
YANG modules. This document defines a single top level "rdns"
Namespace identifier (NID), with which organizations and enterprises
can define Uniform Resource Name (URN) Namespaces to uniquely
identify enterprise YANG modules.
"PKCS #5: Password-Based Cryptography Specification Version 2.1",
Kathleen Moriarty, Burt Kaliski, A. Rusch, 2016-04-07,
<draft-moriarty-pkcs5-v2dot1-01.txt>
This document provides recommendations for the implementation of
password-based cryptography, covering key derivation functions,
encryption schemes, message-authentication schemes, and ASN.1 syntax
identifying the techniques.
The recommendations are intended for general application within
computer and communications systems, and as such include a fair

amount of flexibility. They are particularly intended for the

protection of sensitive information such as private keys, as in PKCS
#8. It is expected that application standards and implementation
profiles based on these specifications may include additional
constraints.
Other cryptographic techniques based on passwords, such as passwordbased-key entity authentication and key establishment protocols are
outside the scope of this document. Guidelines for the selection of
passwords are also outside the scope.
This document represents a republication of PKCS #5 v2.1 from RSA
Laboratories' Public-Key Cryptography Standards (PKCS) series. By
publishing this RFC, change control is transferred to the IETF.
"Multiple IPv4 - IPv6 mapped IPv6 address (M46A)", Naoki Matsuhira,
2016-02-03, <draft-matsuhira-m46a-00.txt>
This document specifies Multiple IPv4 - IPv6 mapped IPv6
address(M46A) spefification. M46A is IPv4 mapped IPv6 address with
plane ID. Unique allocation of plane id value enable IPv4 private
address unique in IPv6 address space. This address may use IPv4 over
IPv6 encapsulation and IPv4 - IPv6 translation.
"Multiple IPv4 - IPv6 address mapping encapsulation - fixed prefix
(M46E-FP)", Naoki Matsuhira, 2016-02-03,
<draft-matsuhira-m46e-fp-00.txt>
This document specifies Multiple IPv4 - IPv6 address mapping
encapsulation - fixed prefix (M46E-FP) specification. M46E-FP makes
backbone network to IPv6 only. And also, M46E-FP can stack many IPv4
networks, i.e. the networks using same IPv4 (private) addresses,
without interdependence.
"Multiple IPv4 - IPv6 address mapping encapsulation - prefix resolution
(M46E-PR)", Naoki Matsuhira, 2016-02-03,
<draft-matsuhira-m46e-pr-00.txt>
This document specifies M46E Prefix Resolution (M46E-PR)
specification. M46E-PR connect IPv4 stub networks between IPv6
backbone network. And also, M46E-PR can stack many IPv4 networks,
i.e. the nwtworks using same IPv4 private addresses without
interdependence.
"Multiple IPv4 - IPv6 address mapping encapsulation - prefix translator
(M46E-PT)", Naoki Matsuhira, 2016-02-03,
<draft-matsuhira-m46e-pt-00.txt>
This document specifies Multiple IPv4 - IPv6 mapping encapsulation Prefix Translator (M46E-PT) specification. M46E-PT expand IPv4
network plane by connecting M46E-FP domain and M46E-PR domain.
M46E-PT translate prefix part of M46E-FP address and M46E-PR address
both are IPv6 address. M46E-PT does not translate IPv4 packet which
is encapsulated, so transparency of IPv4 packet is not broken.
"Multiple IPv4 - IPv6 address mapping translator (M46T)", Naoki
Matsuhira, 2016-02-03, <draft-matsuhira-m46t-00.txt>
This document specifies Multiple IPv4 - IPv6 address mapping
Translator (M46T) specification. M46T enable access to IPv4 only

host from IPv6 host. IPv4 host is identified as M46 address in IPv6
address space. The address assigned to IPv4 host may be global IPv4
address or private IPv4 address. M46T does not support access to
IPv6 host from IPv4 only host.
"Multiple IPv4 address and port number - IPv6 address mapping
encapsulation (M4P6E)", Naoki Matsuhira, 2016-02-03,
<draft-matsuhira-m4p6e-00.txt>
This document specifies Multiple IPv4 address and port number - IPv6
address mapping encapulation (M4P6E) specification.
"Security and Privacy Implications of Numeric Identifiers Employed in
Network Protocols", Fernando Gont, Ivan Arce, 2016-02-04,
<draft-gont-predictable-protocol-ids-00.txt>
This document performs an analysis of the security and privacy
implications of different types of "numeric identifiers" used in IETF
protocols, and tries to categorize them based on their
interoperability requirements and the assoiated failure severity when
such requirements are not met. It describes a number of algorithms
that have been employed in real implementations to meet such
requirements and analyzes their security and privacy properties.
Additionally, it provides advice on possible algorithms that could be
employed to satisfy the interoperability requirements of each
identifier type, while minimizing the security and privacy
implications, thus providing guidance to protocol designers and
protocol implementers. Finally, it provides recommendations for
future protocol specifications regarding the specification of the
aforementioned numeric identifiers.
"Security and Privacy Implications of Numeric Identifiers Employed in
Network Protocols", Fernando Gont, Ivan Arce, 2016-02-04,
<draft-gont-predictable-numeric-ids-00.txt>
This document performs an analysis of the security and privacy
implications of different types of "numeric identifiers" used in IETF
protocols, and tries to categorize them based on their
interoperability requirements and the assoiated failure severity when
such requirements are not met. It describes a number of algorithms
that have been employed in real implementations to meet such
requirements and analyzes their security and privacy properties.
Additionally, it provides advice on possible algorithms that could be
employed to satisfy the interoperability requirements of each
identifier type, while minimizing the security and privacy
implications, thus providing guidance to protocol designers and
protocol implementers. Finally, it provides recommendations for
future protocol specifications regarding the specification of the
aforementioned numeric identifiers.
"DNS Delegation Requirements", Patrik Wallstrom, Jakob Schlyter,
2016-02-04, <draft-wallstrom-dnsop-dns-delegation-requirements-00.txt>
This document outlines a set of requirements on a well-behaved DNS
delegation of a domain name. A large number of tools have been
developed to test DNS delegations, but each tool uses a different set
of requirements for what is a correct setup for a delegated domain
name. However, there are few requirements on how to set up DNS in
order to just make the delegation work. In order to have a wellbehaved delegation that is robust to failures and also makes DNS

resolvers behave consistently, there are a large number of things to

consider.
Based on this document, it should be possible to set up a fully
functional DNS delegation for a domain name, but also to create a set
of test specifications for how to test a DNS delegation.
"IPv4-to-IPv6 translation mechanism with DynDNS", Martin Rosenau,
2016-02-04, <draft-rosenau-dyndns-nat46-00.txt>
Many devices in private homes can be controlled via Web browser from
another computer in the internet. This assumes that the IP address
of the device is known and that the private internet access has a
public IP address at all.
Due to the IPv4 address shortage many internet providers only provide
IPv6 internet access while many internet accesses (and therefore Web
browsers) are IPv4-only.
This document describes a method that allows an internet service
provider that also provides dynamic DNS to the customers to allow
accessing IPv6-only devices from IPv4-only Web browsers.
"Nimble out-of-band authentication for EAP (EAP-NOOB)", Tuomas Aura,
Mohit Sethi, 2016-02-08, <draft-aura-eap-noob-00.txt>
Extensible Authentication Protocol (EAP) [RFC3748] provides support
for multiple authentication methods. This document defines the EAPNOOB 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.
"IANA Registration of New Session Initiation Protocol (SIP) ResourcePriority Namespace for Mission Critical Push To Talk service", Christer
Holmberg, Jrgen Axell, 2016-02-09,
<draft-holmberg-dispatch-mcptt-rp-namespace-00.txt>
This document creates an additional Session Initiation Protocol (SIP)
Resource-Priority namespace to meet the requirements of the 3GPP
defined Mission Critical Push To Talk, and places this namespace in
the IANA registry.
"6LoWPAN Inner Compression", Pascal Thubert, Xavier Vilajosana, Simon
Duquennoy, 2016-02-10, <draft-thubert-6lo-inner-compression-00.txt>
This specification modifies 6LoWPAN stateless address compression to
enable the compression by 6LOWPAN_IPHC of non Link-Local addresses in
an IP header when a reference address can be found in an
encapsulation. .
"YANG Hash", Andy Bierman, Peter Van der Stok, 2016-02-10,
<draft-bierman-core-yang-hash-00.txt>
This document describes an encoding of YANG names to 30 bit hashes.
This document extends the CoMI draft to reduce payload and URI of
CoMI network requests. The technique can be applied to other YANG
based applications to reduce the payload by replacing the YANG names

with 30 bit numbers.

Note
Discussion and suggestions for improvement are requested, and should
be sent to core@ietf.org.
"Compressed Data Extension for SMTP", John Levine, 2016-02-11,
<draft-levine-smtp-compress-00.txt>
SMTP messages can be quite large. This extension specifies a method
to transfer SMTP messages in a compressed form.
"64bit body part and message sizes in IMAP4", Alexey Melnikov, Jay,
2016-02-12, <draft-melnikov-imap-64bit-00.txt>
This document defines an IMAPv4rev1 extension that extends the
existing IMAPv4rev1 32 Bit message and body part sizes to 63 bit.
"Carrying Geo Coordinates in BGP", Enke Chen, Naiming Shen, Robert
Raszuk, 2016-03-01, <draft-chen-idr-geo-coordinates-01.txt>
In this document we specify a new BGP capability - the Geo Coordinate
Capability, and a new BGP attribute - the Geo Coordinate Attribute,
for carrying the Geo Coordinate information in BGP.
"OSPF Extensions for Advertising/Signaling Geo Location Information",
Acee Lindem, Naiming Shen, Enke Chen, 2016-02-26,
<draft-acee-ospf-geo-location-01.txt>
This document specifies an OSPF Link-Local-Signaling (LLS) TLV to
signal the current Geo Coordinates of the OSPF router. For Point-toPoint (P2P)) and Point-to-Multi-Point (P2MP) networks, the Geo
Coordinates can be used to dynamically computing the cost to
neighbors. This is useful both from the standpoint of autoconfiguration and situations where the OSPF routers are moving. The
Geo Coordinates are also useful for other applications such as
Traffic Engineering (TE) and network management and can be advertised
in the OSPF Router Information (RI) LSA.
"Carrying Geo Coordinates Information In IS-IS", Naiming Shen, Enke
Chen, Acee Lindem, 2016-03-02, <draft-shen-isis-geo-coordinates-01.txt>
This document defines a new IS-IS TLV which carries the Geo
Coordinates information of the system. The Geo Coordinates
information can be used by IS-IS routing or by any applications.
"Publishing Organization Boundaries in the DNS", John Levine,
2016-02-12, <draft-levine-dbound-dns-00.txt>
The organization that manages a subtree in the DNS is often different
from the one that manages the tree above it. We describe an
architecture to publish in the DNS the boundaries between
organizations that can be adapted to various policy models and can be
queried with a small number of DNS lookups.
"The DNS Is Not Classy: DNS Classes Considered Useless", Andrew
Sullivan, 2016-03-21, <draft-sullivan-dns-class-useless-02.txt>
Domain Name System Resource Records are identified in part by their

class. The class field is not effective, and it is not used the way
it appears to have been intended. This memo closes the DNS class
registry and requires those defining new RRTYPEs to define them for
all classes.
"Software-Defined Storage Definition and Overview", Eui-Nam Huh, Gawon
Lee, Yunkon Kim, Jintaek Kim, 2016-02-14,
<draft-sds-definition-overview-00.txt,.pdf>
In accordance with rapid increase of data related to IoT and big
data, techniques to control high capacity data is currently active
and vibrant research field. Enterprises are trying to manage data on
the cloud because of flexibility and capability. However, there are
some limits to handle data intelligently in cloud. The SDS is
considered as a good technique regarding this manner. SDS improves
efficiency, scalability and flexibility in scale-out architecture,
as well as, provides a cost effective solution using the existing
storage resources efficiently.
"Software-Defined Storage Reference Model and Use-case", Eui-Nam Huh,
Gawon Lee, Yunkon Kim, Dongha Oh, 2016-02-14,
<draft-sds-reference-usecase-00.txt,.pdf>
In IoT, IoE era, the cloud needs to accommodate enormous requests,
and also the cloud has to provide unlimited scalability, real-time
analysis, and workload integration. Thus, inter-cloud storages
integration is required and a standard for complete integration
between cloud and legacy system is compulsory. Physical host and
storage integration from the perspective of bare metal provisioning
are also under the spotlight. The SDS is a proper technique to fulfil
this issue. According to the increasing demand for software defined
storage, it is required to develop software defined storage reference
model.
"Captive Portals Problem Statement", Mark Nottingham, 2016-04-04,
<draft-nottingham-capport-problem-01.txt>
This draft attempts to establish a problem statement for "Captive
Portals", in order to inform discussions of improving their
operation.
Note to Readers
The issues list for this draft can be found at
https://github.com/mnot/I-D/labels/capport-problem .
The most recent (often, unpublished) draft is at
https://mnot.github.io/I-D/capport-problem/ .
Recent changes are listed at https://github.com/mnot/I-D/commits/ghpages/capport-problem .
"Applicability of the Babel routing protocol", Juliusz Chroboczek,
2016-02-29, <draft-chroboczek-babel-applicability-01.txt>
This document describes some application areas where the Babel
routing protocol [RFC6126] has been found to be useful.
"Problem Statement for Vehicle-to-Infrastructure Networking", Jaehoon
Jeong, Tae Oh, 2016-02-15,

<draft-jeong-its-v2i-problem-statement-00.txt>
This document specifies the problem statement for IPv6-based vehicleto-infrastructure networking. Dedicated Short-Range Communications
(DSRC) is standardized as IEEE 802.11p for the wireless media access
in vehicular networks. This document addresses the extension of IPv6
as the network layer protocol in vehicular networks and is focused on
the networking issues in one-hop communication between a Road-Side
Unit (RSU) and vehicle. The RSU is connected to the Internet and
allows vehicles to have the Internet access if connected. The major
issues of including IPv6 in vehicular networks are neighbor discovery
protocol, stateless address autoconfiguration, and DNS configuration
for the Internet connectivity over DSRC. Also, when the vehicle and
the RSU have an internal network, respectively, the document
discusses the issues of internetworking between the vehicle's
internal network and the RSU's internal network.
"Infrastructure Service Forwarding For NSH", Surendra, Kent Leung, Peter
Bosch, Dongkee Lee, Rajeev Manur, Andrew Dolganow, Sumandra Majee, Joel
Halpern, 2016-02-15, <draft-kumar-sfc-nsh-forwarding-00.txt>
This draft describes the separation of service forwarding function
and service delivery function abstractions, along with the mechanics
of NSH encapsulated packet forwarding with such separation, in SFC
deployments.
This separation frees the service functions from making forwarding
decisions and the necessary control plane integration, thereby
keeping the service functions simple and focused on service delivery.
Further, this separation fully contains the forwarding decisions in
forwarding functions, thereby allowing implementations to enforce
integrity of the forwarding state carried in NSH which in turn is
required for correctly forwarding NSH encapsulated packets.
"BIER TE YANG module", Zheng Zhang, Cui Wang, Ran Chen, fangwei hu,
2016-02-29, <draft-zhang-bier-te-yang-01.txt>
This document defines a YANG data model for BIER TE configuration and
operation.
"Centralized EVPN DF Election", Hao Weiguo, Lili Wang, Li Yizhou,
Shunwan Zhuang, 2016-02-15, <draft-hao-bess-evpn-centralized-df-00.txt>
This document proposes a centralized DF Designated Forwarder
election mechanism to be used between the SDN(Software defined
network) controller and each PE(Provider Edge) in EVPN network. Such
a mechanism overcomes the issues of current standalone DF election
defined in RFC7432. A new BGP capability and an additional DF
Election Result Route Type are proposed to support the centralized
DF mechanism.
"DHCP option for NSH in Service Function Path (SFP)", Yogendra Pal,
Vikram Menon, venkat gorrepati, 2016-02-16,
<draft-ypal-sfc-dhcp-option-for-nsh-for-sfp-00.txt>
This draft specifies Dynamic Host Configuration Protocol option
(both DHCPv4 and DHCPv6) for NSH aware clients participating in
the service function path(SFP) of the service chaining. As part
of this proposal SFF and SF will receive the SFP information
containing Service Path Identifier(SPI), Transport protocol and

Nexthop(NH) address of subsequent SFF/SF.

"Hierarchical Stateful Path Computation Element (PCE).", Dhruv Dhody,
Young Lee, Daniele Ceccarelli, Jongyoon Shin, Daniel King, 2016-02-16,
<draft-dhodylee-pce-stateful-hpce-00.txt>
A Stateful Path Computation Element (PCE) maintains information on
the current network state, including: computed Label Switched Path
(LSPs), reserved resources within the network, and pending path
computation requests. This information may then be considered when
computing new traffic engineered LSPs, and for associated
and dependent LSPs, received from Path Computation Clients (PCCs).
The Hierarchical Path Computation Element (H-PCE) architecture,
provides an architecture to allow the optimum sequence of
inter-connected domains to be selected, and network policy to be
applied if applicable, via the use of a hierarchical relationship
between PCEs.
Combining the capabilities of Stateful PCE and the Hierarchical PCE
would be advantageous. This document describes general
considerations and use cases for the deployment of Stateful PCE(s)
using the Hierarchical PCE architecture.
"The application/proxy-explanation+json media type", Mark Nottingham,
2016-02-16, <draft-nottingham-proxy-explanation-00.txt>
This specification defines the application/proxy-explanation+json
media type, to allow HTTP proxies to explain to clients why a request
is unsuccessful.
Note to Readers
The issues list for this draft can be found at
https://github.com/mnot/I-D/labels/proxy-explanation .
The most recent (often, unpublished) draft is at
https://mnot.github.io/I-D/proxy-explanation/ .
Recent changes are listed at https://github.com/mnot/I-D/commits/ghpages/proxy-explanation .
"A Dynamic Service Class Mapping Scheme for Different QoS Domains Using
Flow Aggregation", Yu-ning Dong, Chun Liu, 2016-02-16,
<draft-dong-qms-fag-00.txt>
This document addresses the issue of provisioning end-to-end Quality
of Service (QoS) for multimedia services over heterogeneous networks
and introduces a parametric model by using network calculus theory
for QoS class mapping between different QoS domains. Then a QoS
Mapping Scheme based on Flow Aggregation (QMS-FAG) is proposed in
this document to mitigate the information loss problem due to mapping
between QoS domains with different granularity of QoS class and to
provide efficient network resources utilization by considering user's
Quality of Experience (QoE). In QMS-FAG, the QoS requirements of
service flows are indicated by a unique FAG identifier which is
described in a service flow map of QoS parameters. With FAG
identifier and mapping executors sitting at the border of different
QoS domains, QMS-FAG allows smooth QoS class mapping between networks
with different granularity of QoS class. Both numerical analysis and

simulation studies are given to demonstrate the efficiency of the

proposed method.
"LP-WAN GAP Analysis", Ana Minaburo, Alexander Pelov, Laurent Toutain,
2016-02-24, <draft-minaburo-lp-wan-gap-analysis-01.txt>
Low Power Wide Area Networks (LP-WAN) are different technologies
covering different applications based on long range, low bandwidth
and low power operation. The use of IETF protocols in the LP-WAN
technologies should contribute to the deployment of a wide number of
applications in an open and standard environment where actual
technologies will be able to communicate. This document makes a
survey of the principal characteristics of these technologies and
covers a cross layer analysis on how to adapt and use the actual IETF
protocols, but also the gaps for the integration of the IETF protocol
stack in the LP-WAN technologies.
"MPLS Egress Protection Framework", Yimin Shen, Jeyananth Jeganathan,
2016-02-25, <draft-shen-mpls-egress-protection-framework-01.txt>
This document specifies a fast reroute framework for protecting MPLS
tunnels and IP/MPLS services against egress router failures. The
framework relies on local detection and local repair to be performed
by the router upstream adjacent to a failure. The router can restore
traffic in the order of tens of milliseconds, by rerouting it to a
protector through a pre-established bypass tunnel. Therefore, the
mechanism can be used to reduce traffic loss before global repair
reacts to the failure and control plane protocols converge on the
topology changes due to the failure.
"DNS wire-format over HTTP", Davey Song, Paul Vixie, Shane Kerr, Runxia
Wan, 2016-04-27, <draft-song-dns-wireformat-http-03.txt>
This memo introduces a way to tunnel DNS data over HTTP. This may be
useful in any situation where DNS is not working properly, such as
when there is middlebox misbehavior.
"Last Diverting Line Identity", Nigel Weinronk, 2016-02-18,
<draft-weinronk-dispatch-last-diverting-line-id-00.txt>
This document proposes an extension to the Session Initiation
Protocol (SIP).
In cases where applications/services (for example verification /
billing) are provided by a network that is not the originating
network the Network Asserted Identity is needed to provide these
services.
This extension provides the ability for a 'diversion service' to
provide a Network Asserted Identity of the last diverting user to
these applications/services.
This extension defines a new general header, Last Diverting Line
Identity which conveys the Network Asserted Identity of the
diverting party to these applications/services.
"Properties of an Ideal Naming Service", Brian Trammell, 2016-03-11,
<draft-trammell-inip-pins-01.txt>
This document specifies a set of necessary functions and desirable

properties of an ideal system for resolving names to addresses and

associated information for establishing communication associations in
the Internet. For each property, it briefly explains the rationale
behind it, and how the property is or could be met with the present
Domain Name System. It is intended to start a discussion within the
IAB's Names and Identifiers program about gaps between the present
reality of DNS and the naming service the Internet needs by returning
to first principles.
"It's Often True: Security's Ignored (IOTSI) - and Privacy too.",
Stephen Farrell, Alissa Cooper, 2016-02-18, <draft-farrell-iotsi-00.txt>
Designers of information models for challenged devices connected to
the Internet, and most especially for devices that will be carried by
people or that will be operating in people's homes, need to not
forget that people own the devices and the data, and expect those to
work for them, not against them. This draft discusses some security
and privacy issues that may be relevant for the IAB's IOTSI workshop
on information models for such devices and related services.
"Inter-domain cooperative DDoS protection problems and mechanism",
Kaname Nishizuka, Liang Xia, Jinwei Xia, Dacheng Zhang, Luyuan Fang,
2016-02-19, <draft-nishizuka-dots-inter-domain-mechanism-00.txt>
As DDoS attack evolves rapidly in the aspect of volume and
sophistication, cooperation among operators for sharing the capacity
of the protection system to cope with it becomes very necessary.
This document describes some possible solutions to the cooperative
inter-domain DOTS problems.
"TLS/DTLS Content Provider Edge Server Abstract API", Daniel Migault,
2016-02-19, <draft-mglt-lurk-tls-abstract-api-00.txt>
This document describes the interactions between the Edge Server and
the Content Provider in a split authentication scenario.
This document provides an abstract description of the information
exchanged between an Edge Server and a Content Provider.
"RDMA Durable Write Commit", Tom Talpey, Jim Pinkerton, <>, 2016-02-19,
<draft-talpey-rdma-commit-00.txt>
This document specifies extensions to RDMA protocols to provide
capabilities in support of enhanced remotely-directed data
consistency. The extensions include a new operation supporting
remote commitment to durability of remotely-managed buffers, which
can provide enhanced guarantees and improve performance for lowlatency storage applications. In addition to, and in support of
these, extensions to local behaviors are described, which may be used
to guide implementation, and to ease adoption. This document would
extend the IETF Remote Direct Memory Access Protocol (RDMAP),
RFC5040, and RDMA Protocol Extensions, RFC7306.
"Yang Data Model for BGP/MPLS L3 VPNs", Dhanendra Jain, Keyur Patel,
Patrice Brissette, Zhenbin Li, Shunwan Zhuang, Xufeng Liu, Jeffrey Haas,
Santosh Esale, Bin Wen, 2016-02-22,
<draft-dhjain-bess-bgp-l3vpn-yang-01.txt>
This document defines a YANG data model that can be used to configure
and manage BGP Layer 3 VPNs.

"Model-Based Hypertext Language", Michael Koster, 2016-02-21,

<draft-koster-t2trg-hypertext-language-00.txt>
Interoperability for connected things is improving in a number of
important areas, converging around Internet Protocol (IP) and
internet design patterns. Hypermedia is becoming more common with
web linking becoming part of a number of important standards.
However, there is still an interoperability gap in how application
semantics are defined and used. Many organizations and industry
alliances are defining vocabulary and taxonomy for application
domains, independent of each other. These vocabularies are often
bound to particular conceptual models, and are often semantically
incompatible with each other. While it may be possible to adapt
protocols and convert representations, it is difficult to develop a
common application framework that works across ecosystems and
domains.
This article proposes a method that can be reused across application
domains and across ecosystems, to define a shared conceptual model
and common vocabulary. A public resource is described which does for
connected things what schema.org does for web commerce, to provide a
community driven vocabulary and simple ontology that enables web
scale interoperability between applications and connected things.
"Using AEAD with Secure Shell", Niels Moeller, 2016-02-22,
<draft-nisse-secsh-aead-00.txt>
This document specifies an extension of the Secure Shell transport
protocol, to enable use of Authenticated Encryption with Associated
Data (AEAD) mechanisms within the Secure Shell protocol. It also
specifies one concrete AEAD algorithm, chacha20-poly1305, for use
with Secure Shell.
"RFC6761 is now closed", George Michaelson, 2016-02-22,
<draft-michaelson-dnsop-rfc6761-is-closed-01.txt>
In hindsight, RFC6761 was a mistake. This document formally closes
this process.
"Modeling RESTful APIs with JSON Hyper-Schema", Kerry Lynn, Laird
Dornin, 2016-02-22, <draft-lynn-t2trg-model-rest-apis-00.txt>
This document explores JSON Hyper-Schema as a method of modeling
Internet of Things (IoT) systems that follow the principles of the
Representational State Transfer (REST) architectural style.
"Features of the User Datagram Protocol (UDP) and Lightweight UDP (UDPLite) Transport Protocols", Gorry Fairhurst, Tom Jones, 2016-03-21,
<draft-fairhurst-taps-transports-usage-udp-01.txt>
This document describes how the User Datagram Protocol (UDP) and the
Lightweight User Datagram Protocol (UDP-Lite) transport protocols
expose services to applications and how an application can configure
and use the features offered by the transport service. The document
is intended as a contribution to the TAPS working group to assist in
analysis of the UDP and UDP-Lite transport interface.
"Example Packets for 6TiSCH Configuration", Jonathan Munoz, Emmanuel

Riou, Guillaume Gaillard, Dominique Barthel, 2016-02-23,

<draft-munoz-6tisch-examples-00.txt>
This draft contains example packets exchanged by nodes implementing
the following 6tisch drafts: draft-ietf-6tisch-minimal, draft-wang6tisch-6top-sublayer, draft-ietf-6lo-routing-dispatch and draft-ietf6lo-paging-dispatch. All packets are presented both in raw binary
and fully parsed contents. This document can be used as a reference
when implementing the previous mentioned drafts.
"Digital Signatures on RFC and Internet-Draft Documents", Russ Housley,
2016-02-24, <draft-housley-rfc-and-id-signatures-01.txt>
This document specifies the conventions for digital signatures on
RFCs and Internet-Draft documents. For Internet-Drafts, the
Cryptographic Message Syntax (CMS) is used to create a detached
signature, which is stored in a separate companion file so that no
existing utilities are impacted by the addition of the digital
signature. For RFCs, an embedded digital signature is included in
Portable Document Format (PDF) files types in addition to the
detached signature in a separate companion file.
This document (once approved) obsoletes RFC 5485.
"DTLS Tunnel between Media Distribution Device and Key Management
Function to Facilitate Key Exchange", Paul Jones, 2016-03-21,
<draft-jones-perc-dtls-tunnel-02.txt>
This document defines a DTLS tunneling protocol for use in multimedia
conferences that enables a Media Distribution Device (MDD) to
facilitate key exchange between an endpoint in a conference and the
Key Management Function (KMF) responsible for key distribution. The
protocol is designed to ensure that the keying material used for hopby-hop encryption and authentication is accessible to the MDD, while
the keying material used for end-to-end encryption and authentication
is inaccessible to the MDD.
"A Framework for Computed Multicast applied to MPLS based Segment
Routing", David Allan, Jeff Tantsura, 2016-02-23,
<draft-allan-spring-mpls-multicast-framework-00.txt>
This document describes a multicast solution for Segment Routing with
MPLS data plane. It is consistent with the Segment Routing
architecture in that an IGP is augmented to distribute information in
addition to the link state. In this solution it is multicast group
membership information sufficient to synchronize state in a given
network domain. Computation is employed to determine the topology of
any loosely specified multicast distribution tree.
"Control and Monitoring Differentiated Service Code Point in Two-Way
Active Measurement Protocol (TWAMP)", Steve Baillargeon, Greg Mirsky,
2016-02-23, <draft-bailmir-ippm-twamp-dscp-ctrl-mon-00.txt>
This document describes an optional extension for Two-Way Active
Measurement Protocol (TWAMP) allowing control and monitoring of the
Differentiated Service Code Point (DSCP) field in forward and reverse
directions within single test session with the TWAMP-Test protocol.
This document, if accepted, will be an update to the TWAMP core
protocol specified in RFC 5357 and DSCP Monitoring mode defined in
RFC 7750 .

"Nationwide Number Portability: a MODERN Use Case", Jim Brewer, Tom

McGarry, Chris Wendt, 2016-02-24, <draft-mcgarry-nnp-use-case-00.txt>
A proposed solution for geographic number portability in the USA
calls for a new non-geographic numbering resource. This draft uses
this proposal as a use case for a MODERN solution. While this
focuses on an effort occurring in the USA the concepts are
applicable to any country.
"No-Path DAO Problem Statement", Rahul Jadhav, Rabi Sahoo, Zhen Cao,
DENG Hui, 2016-02-24, <draft-jadhav-roll-no-path-dao-ps-00.txt>
This document describes the problems associated with the use of NoPath DAO messaging in RPL.
"PCEP Extensions for Establishing Relationships Between Sets of LSPs and
Virtual Networks", Young Lee, Dhruv Dhody, Daniele Ceccarelli,
2016-02-25, <draft-leedhody-pce-vn-association-00.txt>
This document describes how to extend PCE association mechanism
introduced by [PCE-Association] to further associate sets of LSPs
with a higher-level structure such as a virtual network requested by
clients or applications. This extended association mechanism can be
used to facilitate virtual network control using PCE architecture.
"Fixed-Bandwidth Mode for SSH Channels", denis bider, 2016-02-28,
<draft-ssh-fixed-bandwidth-02.txt>
This memo defines a mechanism for SSH clients and servers to counter
some types of traffic analysis, especially keystroke analysis, in SSH
terminal session channels.
"Multicast Service YANG", Zheng Zhang, Cui Wang, 2016-02-28,
<draft-zhang-mboned-multicast-service-yang-00.txt>
This document proposes a general and all-round multicast service YANG
model, which provides explanations and guidelines for the deployment
of multicast service in all kinds of multicast scenarios. The
multicast technologies include BIER multicast, PIM multicast, MPLS
multicast and so on. And also, there defines several possible RPCs
about how to interact between multicast service model and multicast
device model.
"PCEP Extension for Flow Specification", Zhenbin Li, Xia Chen, Shunwan
Zhuang, 2016-02-28, <draft-li-pce-pcep-flowspec-00.txt>
Dissemination of the traffic flow specifications was first introduced
in the BGP protocol via RFC 5575. In order to distribute the flow
specifications from PCE controller to network device without BGP
protocol it is desirable to extend PCEP with flow specification
information.
This document specifies a set of extensions to PCEP to support
dissemination of flow specifications. The extensions include the
instantiation, updation and deletion of flow specifications.
"Updates to RFC 4572", Christer Holmberg, 2016-03-21,
<draft-holmberg-mmusic-4572-update-01.txt>

This document updates RFC 4572 by clarifying the usage of multiple

SDP 'fingerprint' attributes with a single TLS connection. The
document also updates the preferred cipher suite to be used, and
removes the requirement to use the same hash function for calculating
the certificate fingerprint that is used to calculate the certificate
signature.
"Introducing Server Name Identifiers in Certificates", Thomas Fossati,
Hannes Tschofenig, 2016-02-29,
<draft-fossati-core-server-name-id-00.txt>
TBD.
"BGP-LS Traffic Engineering (TE) Metric Extensions", Stefano Previdi,
Qin Wu, Hannes Gredler, Saikat Ray, Jeff Tantsura, Clarence Filsfils,
Les Ginsberg, 2016-03-01,
<draft-previdi-idr-bgpls-te-metric-extensions-01.txt>
This document defines new BGP-LS TLVs in order to carry the IGP
Traffic Engineering Extensions defined in IS-IS and OSPF protocols.
"RTP media failover: problem statement", Martin Taylor, Nic Larkin,
2016-02-29, <draft-taylor-mmusic-rtp-failover-problem-00.txt>
Network-based functions that terminate large numbers of RTP media
streams and that offer high availability, such as session border
controllers or conference bridges, typically preserve the same IP
address towards sources of RTP media across a failover event because
it is impractical to signal a change of IP address towards large
numbers of RTP sources sufficiently rapidly to keep media
interruption intervals within acceptable limits. The need to
preserve the IP address of RTP media terminating functions across a
failover event imposes architectural requirements that can be
difficult or costly to meet, particularly in network function
virtualization environments. This document describes the problem,
outlines the key requirements for a solution, and discusses the
merits and shortcomings of various existing approaches to solving
the problem, before arguing that a new solution is needed.
"Push Notifications in the Session Initiation Protocol (SIP)", Viktor
Ivanov, 2016-04-07, <draft-ivanov-sipcore-pnsip-01.txt>
The Session Initiation Protocol (SIP) allows User Agents to register
for inbound requests. However, the existence of firewalls and
Network Address Translators (NATs) prevent servers from reaching the
User Agents unless the User Agents keep connections to the server
alive.
To keep such connections alive User Agents employ various methods,
most of which require constant uptime resulting in high energy cost.
This is especially a problem on mobile platforms that operate
entirely on battery power. To resolve these issues many mobile
manufacturers have provided a cost effective way of pushing messages
to their devices.
This specification defines behaviors for User Agents, registrars and
proxy servers that allow a User Agent to provide a Push Notification
Configuration to its Registrar.
"Using a DNS SRV Record to Locate an X.509 Certificate Store", Brian

Haberman, John Levine, 2016-02-29, <draft-bhjl-x509-srv-00.txt>

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.
"IETF Trends and Observations", Jari Arkko, Alia Atlas, Avri Doria,
Tobias Gondrom, Olaf Kolkman, Steve Olshansky, Benson Schliesser, Robert
Sparks, Russ White, 2016-02-29,
<draft-arkko-ietf-trends-and-observations-00.txt>
While most of the work in the IETF is technical, the IETF should and
does regularly examine itself, including its processes and goals, to
determine if the technical community is truly serving the larger
network engineering community effectively. Changes in this area tend
to be incremental, as is fitting for an organization with decades of
experience and history in developing and managing the process of
building technical specifications.
The rapid and ongoing changes in the world have recently caused a
number of IETF participants to examine the current processes and
operation of the IETF, particularly in the context of the culture of
the IETF. This memo discusses some cultural and global trends in
relation to the IETF's operating environment, how these trends might
affect the operation of the IETF, and notes some topics for further
exploration.
Writing this memo has been inspired by involvement in various
decisions that the IETF leadership has to take part in, often wishing
to be able to draw more on understanding trends and their impact on
the IETF.
This memo is also input for discussion that the IETF community should
have.
The memo has no particular official standing, nor does it claim to
represent more than the authors' thinking at the time of writing.
There is no intent on the part of the authors for this to be
published as a RFC. Please direct discussion about this topic to the
ietf@ietf.org mailing list.
"IPv6 Multihoming with transparent End-to-End connectivity", Sumanta
Mahapatra, 2016-03-01, <draft-sumanta-ipv6-multihoming-solution-00.txt>
Ipv6 Multihoming for Host could be implemented using Ipv6-to-Ipv6
Network prefix translation (NPTv6), however NPTv6 not ideal as this
solution not achieve End-to-End transparency of connectivity.
Basic issues with End host Multihoming architecture without
NPTv6 are:
1. Source address selection, 2. Next hop selection
and 3. DNS resolution.
One other approach to solve above mention all three issues with
End-to-End transparent connectivity would be using policy at
End host to enforce source address and next hop selection.
In this document,a solution being propose to solve all above
mention three problem enhancing policy based enforcement on host
directed by router using its router advertisement.This document

not obsolete any of the previous work,only propose how policy

on End-host can be enforce from router by mapping destination
prefix with DNS via Router Advertisement.
"PIM DR Improvement", Zheng Zhang, fangwei hu, BenChong Xu, 2016-03-01,
<draft-pim-dr-improvement-00.txt>
PIM is worldly deployed multicast protocol. This document will
improve the stability of PIM protocol, decrease the lost of multicast
packets when the PIM DR (Designed Router) is down.
"Intended status: Standards Track", Alexey Eromenko, 2016-03-02,
<draft-eromenko-ipff-arp-00.txt>
Address Resolution Protocol in IPv5 is basically the same as in IPv4,
and it is intended to resolve Data Link Layer Ethernet addresses to
Network Layer IP-FF addresses, in addition to Duplicate Address
Detection (DAD), includes optional duplicate MAC address detection.
This spec was written for IEEE 802.3 Ethernet links or compatible.
Separate specifications may be required for other link types.
"Best current practices for TCP-ENO configuration", Andrea Bittau,
Daniel Giffin, David Mazieres, 2016-03-02,
<draft-bittau-tcpinc-bcp-00.txt>
TCP-ENO negotiates encryption of TCP connections, protecting legacy
applications and protocols from passive eavesdropping. TCP-ENO
generally falls back to unencrypted TCP when not supported by both
endpoints or the network. Nonetheless, certain middlebox behavior
could cause TCP connections to fail entirely in conjunction with TCPENO. This document specifies conventions for servers against which
TCP-ENO machines can test network paths for TCP-ENO compatibility,
and describes the best current practice for enabling TCP-ENO only
when it is unlikely to cause connection failure.
"A Retention Priority Attribute for HTTP Cookies", Erik Wright, Samuel
Huang, Mike West, 2016-03-03, <draft-west-cookie-priority-00.txt>
This document defines the "Priority" attribute for HTTP cookies.
This attribute allows servers to specify a retention priority for
HTTP cookies that will be respected by user agents during cookie
eviction.
"Interface to Network Security Functions (I2NSF) Terminology", Susan
Hares, John Strassner, Diego Lopez, Liang Xia, 2016-04-04,
<draft-hares-i2nsf-terminology-02.txt,.pdf>
This document defines a set of terms that are used for the Interface
to Network Security Functions (I2NSF) effort.
"Using Layer 3 Multicast Suppression Protocols Above Layer 3", Charles
Perkins, 2016-03-03, <draft-perkins-manet-using-rfc6621-00.txt>
This document specifies how protocols operating at layers above layer
3 can use the multicast suppression algorithms, for instance the
algorithms specified in RFC 6621.
"Endpoint Message Authentication for AODV Route Messages", Charles
Perkins, 2016-05-03, <draft-perkins-manet-aodv-e2esec-01.txt>

This document specifies a new type extension to enable RFC 7182

authentication mechanism to be used for authenticating AODVv2 route
messages. The document also specifies a new message TLV for AODVv2
and, potentially, other reactive protocols. Both mechanisms allow
the endpoints of a newly discovered route to be assured that they
were the originator of the RREQ and responder producing the RREP
respectively.
"Flow Control Extension for DLEP", Ashish Dalela, Arun Parashar, Ananth
S, 2016-03-15, <draft-dalela-dlep-flow-control-02.txt>
There is a need for a mechanism to flow control the data plane
traffic between the router and the modem. This draft extends DLEP
protocol to provide Ethernet based flow control schemes.
"TCP Capability Option", Mohamed Boucadair, Christian Jacquenet,
2016-03-04, <draft-boucadair-tcpm-capability-option-00.txt>
This document defines an experimental TCP option that can be used to
negotiate a set of options that are supported by two TCP endpoints.
The main motivation for designing this option is the optimization of
the option space for SYN segments.
"Bundle Protocol CBOR Representation Specification", Scott Burleigh,
2016-04-29, <draft-burleigh-dtn-rs-cbor-01.txt>
This Internet Draft presents a specification for the use of Concise
Binary Object Representation (CBOR) in the representation of
transmitted Bundle Protocol (BP) bundles.
"YANG Models for the Northbound Interface of a Transport Network
Controller: Requirements, Functions, and a List of YANG Models", Xian
Zhang, Ruiquan Jing, Wei Jian, Jeong-dong Ryoo, Yunbin Xu, Daniel King,
2016-03-06, <draft-zhang-ccamp-transport-ctrlnorth-yang-00.txt>
A transport network is a server-layer network designed to provide
connectivity services for a client-layer network to carry the client
traffic opaquely across the server-layer network resources. A
transport network may be constructed from equipment utilizing any of
a number of different transport technologies such as the evolving
optical transport infrastructure (Synchronous Optical Networking
(SONET) / Synchronous Digital Hierarchy (SDH) and Optical Transport
Network (OTN)) or packet transport as epitomized by the MPLS
Transport Profile (MPLS-TP).
All transport networks have high benchmarks for reliability and
operational simplicity. This suggests a common, technologyindependent management/control paradigm that can be extended to
represent and configure specific technology attributes.
This document describes the requirements facing transport networks
in order to provide open interfaces for resource programmability and
control/management automation. A list of existing and additional
YANG models is provided to fulfill the functional requirements.
"Update of the List of Configurable SCTP Protocol Parameters", Lionel
Morand, Cedric Bonnet, 2016-03-07,
<draft-morand-tsvwg-sctp-parameters-update-00.txt,.pdf>
In the SCTP protocol stack implementations available for deployment

in operational networks, it has been usually observed that the list

of parameters that can be configured by the operators is often
restricted to the list of SCTP protocol parameter values that are
recommended for SCTP given in the IETF RFC 4960. However, this list
is not exhaustive.
This document updates the IETF RFC 4960 by including the SACK delay
as part of the list of SCTP protocol parameters that can be
configurable by an SCTP administrator. The associated recommended
value is also given, according to the IETF RFC 4960
"IAOC Plenary Meeting Venue Selection Process", Fred Baker, 2016-03-17,
<draft-baker-mtgvenue-iaoc-venue-selection-process-01.txt>
This documents the IAOC's IETF Meeting Venue Selection Process.
"OVAL(R) Common Model", Michael Cokus, Daniel Haynes, David Rothenberg,
Juan Gonzalez, 2016-03-07, <draft-cokus-sacm-oval-common-model-00.txt>
This document specifies Version 5.11.1 of the Common Model of the
Open Vulnerability and Assessment Language (OVAL). It contains
definitions of the constructs and enumerations that are used
throughout the other core models in the OVAL Language both
eliminating duplication and facilitating reuse.
"OVAL(R) Results Model", Michael Cokus, Daniel Haynes, David Rothenberg,
Juan Gonzalez, 2016-03-07, <draft-cokus-sacm-oval-results-model-00.txt>
This document specifies Version 5.11.1 of the OVAL Results Model
which is used to express the results of an evaluation of a set of
systems based on a set of OVAL Definitions and the target systems'
OVAL System Characteristics.
"OVAL(R) Processing Model", Michael Cokus, Daniel Haynes, David
Rothenberg, Juan Gonzalez, 2016-03-07,
<draft-haynes-sacm-oval-processing-model-00.txt>
This document defines Version 5.11.1 of the OVAL processing model
which describes, in detail, how the major components of the OVAL
Language Data Model are used to produce OVAL Definitions, OVAL System
Characteristics, and OVAL Results.
"OVAL(R) Definitions Model", Michael Cokus, Daniel Haynes, David
Rothenberg, Juan Gonzalez, 2016-03-07,
<draft-haynes-sacm-oval-definitions-model-00.txt>
This document specifies Version 5.11.1 of the OVAL Definitions Model
which defines an extensible framework for making assertions about a
system that are based upon a collection of logical statements. Each
logical statement defines a specific machine state by identifying the
data set on the system to examine and describing the expected state
of that system data.
"OVAL(R) Variables Model", Michael Cokus, Daniel Haynes, David
Rothenberg, Juan Gonzalez, 2016-03-07,
<draft-haynes-sacm-oval-variables-model-00.txt>
This document specifies Version 5.11.1 of the OVAL Variables Model
which contains constructs that allow for the specification of values
for external_variables defined in content that was created using the

OVAL Definitions Model. The OVAL Variables Model serves as a useful

mechanism for parameterizing content based on the OVAL Definitions
Model.
"OVAL(R) Directives Model", Michael Cokus, Daniel Haynes, David
Rothenberg, Juan Gonzalez, 2016-03-07,
<draft-rothenberg-sacm-oval-directives-model-00.txt>
This document specifies Version 5.11.1 of the OVAL Directives Model
which defines the constructs used to tailor the level of detail
contained within a set of OVAL Results.
"OVAL(R) System Characteristics Model", Michael Cokus, Daniel Haynes,
David Rothenberg, Juan Gonzalez, 2016-03-07,
<draft-rothenberg-sacm-oval-sys-char-model-00.txt>
This document specifies Version 5.11.1 of the OVAL System
Characteristics Model which provides a framework for representing
low-level system configuration information that can be extended to
support platform-specific constructs.
"RSVP-TE Extensions For Associated Co-routed Bidirectional Label
Switched Paths (LSPs)", Rakesh Gandhi, Himanshu Shah, Jeremy Whittaker,
2016-03-15, <draft-gandhishah-teas-assoc-corouted-bidir-01.txt>
In packet transport networks, there are requirements where reverse
unidirectional LSP of a bidirectional LSP needs to follow the same
path as its forward unidirectional LSP. This document describes how
the RSVP association signaling is used to bind two co-routed
point-to-point unidirectional LSPs into an associated co-routed
bidirectional LSP in single-sided provisioning case. Fast-reroute
procedures are defined to ensure that the traffic flows on the
co-routed path after a failure event.
"Semantics and the Internet of Things", John Strassner, Joel Halpern,
Qin Wu, 2016-03-08, <draft-strassner-t2trg-semantics-and-iot-00.txt>
This document examines how semantics help different deployments in
an Internet of Things (IoT) environment interoperate. IoT data,
device, and system interoperability requires semantics to ensure
that the meaning of terms and objects in one device or system are
not lost or altered when they are exchanged and used by other
devices or systems.
"Architecture for a Delay-and-Disruption Tolerant Public-Key
Distribution Network (PKDN)", Kapali Viswanathan, Fred Templin,
2016-03-08, <draft-viswanathan-dtn-pkdn-00.txt>
Delay/Disruption Tolerant Networking (DTN) introduces a network model
in which communications can be subject to long delays and/or
intermittent connectivity. DTN specifies the use of public-key
cryptography to secure the confidentiality and integrity of messages
in transit. The use of public-key cryptography posits the need for
certification of public keys and revocation of certificates. This
document formally defines the DTN key management problem and then
provides a high-level design solution for delay and disruption
tolerant distribution and revocation of public-key certificates along
with relevant design options and recommendations for design choices.
"Framework and Requirements for GMPLS-based Control of Flexible Ethernet

Network", Qilei Wang, 2016-03-08, <draft-wang-ccamp-flexe-fwk-00.txt>

Flex Ethernet (FlexE) technology, which is defined by Optical
Internetworking Forum (OIF), is a new kind of data plane technology
and can be used to provides a generic mechanism for supporting a
variety of Ethernet MAC rates that may or may not correspond to any
existing Ethernet PHY rate. This includes MAC rates that are both
greater than (through bonding) and less than (through sub-rate and
channelization) the Ethernet PHY rates used to carry FlexE.
Based on the applications/use cases given in the Flex Ethernet
Implementation Agreement, this document defines a framework and
control plane requirements for the application of existing GMPLS
architecture and control plane protocols to the control of flexible
Ethernet network. The actual extensions to the GMPLS protocols will
be defined in companion documents.
"RSVP-TE Signaling Extensions in support of Flexible Ethernet networks",
Qilei Wang, 2016-03-21, <draft-wang-ccamp-flexe-signaling-01.txt>
This draft describes the extensions to the Resource Reservation
Protocol Traffic Engineering (RSVP-TE) signalling protocol to support
Label Switched Paths (LSPs) in a GMPLS-controlled flexible Ethernet
network.
"A YANG model for Multicast Protocol for Low power and lossy Networks
(MPL)", Peter Van der Stok, Pascal Thubert, 2016-03-08,
<draft-vanderstok-roll-mpl-yang-00.txt>
This document defines a YANG data model for management of Multicast
Protocol for Low power and lossy Networks (MPL) implementations. The
data model includes configuration data and state data.
Note
Discussion and suggestions for improvement are requested, and should
be sent to roll@ietf.org.
"Signaling Maximum SID Depth using Border Gateway Protocol Link-State",
Jeff Tantsura, Greg Mirsky, Siva Sivabalan, Uma Chunduri, 2016-03-09,
<draft-tantsura-idr-bgp-ls-segment-routing-msd-00.txt>
This document discusses use of BGP-LS to expose node and/or link on a
node MSD "Maximum SID Depth" to a centralized controller (PCE/SDN).
"Signaling MSD (Maximum SID Depth) using OSPF", Jeff Tantsura, Uma
Chunduri, 2016-03-09, <draft-tantsura-ospf-segment-routing-msd-00.txt>
This document proposes a way to expose Maximum SID Depth (MSD)
supported by a node at node and/or link level by an OSPF Router. In
a Segment Routing (SR) enabled network a centralized controller that
programs SR tunnels at the head-end node needs to know the MSD
information at node level and/or link level to push the label stack
of an appropriate depth . Here the term OSPF means both OSPFv2 and
OSPFv3.
"Signaling MSD (Maximum SID Depth) using IS-IS", Jeff Tantsura, Uma
Chunduri, 2016-03-09, <draft-tantsura-isis-segment-routing-msd-00.txt>
This document proposes a way to expose Maximum SID Depth (MSD)

supported by a node at node and/or link level by an OSPF Router. In

a Segment Routing (SR) enabled network a centralized controller that
programs SR tunnels at the head-end node needs to know the MSD
information at node level and/or link level to push the label stack
of an appropriate depth.
"Remote Hub Status and Definition", Nalini Elkins, Alvaro Retana, Anand
Raje, 2016-03-09, <draft-elkins-ietf-remote-hubs-00.txt>
Remote IETF hubs seem to be springing up organically in quite a few
regions. There appear to be regional differences in how hubs are
organized. Latin America has quite a few remote hubs as does India.
The two regions are different in how they arose, where they meet, and
what they do.
Thus, creating a template for a remote hub may not work because hubs
may be very different across cultures and of very different sizes.
Lastly, this document discusses how IETF "central" can assist with
remote hubs.
"Remote Hubs in Latin America", Alvaro Retana, Carlos Martinez, Nalini
Elkins, Simon Romano, 2016-03-09,
<draft-oflaherty-ietf-remote-hubs-lac-00.txt>
This document describes experiences and lessons learnt organizing
remote sessions for working group meetings in Latin America. The main
objective is to engage people in the IETF through small and informal
meetings with people that share common interests.
At the same time, remote participation for those already active in
the IETF is more attractive and they help with IETF outreach sharing
their experiences with newcomers.
The local meetings are called remote IETF Working Group Hubs.
"Privacy Extensions for DNS-SD", Christian Huitema, 2016-03-09,
<draft-huitema-dnssd-privacy-00.txt>
DNS-SD allows discovery of services published in DNS or MDNS. The
publication normally disclose information about the device publishing
the services. There are use cases where devices want to communicate
without disclosing their identity, for example two mobile devices
visiting the same hotspot. We propose a method to obfuscate the
identification information published by DNS-SD.
"Network Telemetry and Big Data Analysis", Qin Wu, John Strassner,
Adrian Farrel, Liang Zhang, 2016-03-09,
<draft-wu-t2trg-network-telemetry-00.txt>
This document focuses on network measurement and analysis in the
network environment. It first defines network telemetry, describes
an exemplary network telemetry architecture, and then explores the
characteristics of network telemetry data. It ends with detailing a
set of issues with retrieving and processing network telemetry data.
"Optimized 6LoWPAN Fragmentation Header for LPWAN", Carles Gomez, Josep
Paradells, Jon Crowcroft, 2016-03-20,
<draft-gomez-lpwan-fragmentation-header-01.txt>

LPWAN technologies are characterized by a very limited data unit and/

or payload size, often one order of magnitude below the one in IEEE
802.15.4. However, many such technologies do not support layer 2
fragmentation. The 6LoWPAN fragmentation header defined in RFC 4944
represents very high overhead for LPWAN technologies, and it even
does not support transporting IPv6 datagrams that require
fragmentation over layer 2 technologies of a payload size below 13
bytes. This specification defines an optimized 6LoWPAN fragmentation
header for LPWAN.
"IAB Workshop on Managing Radio Networks in an Encrypted World (MaRNEW)
Report", N Rooney, 2016-04-04, <draft-nrooney-marnew-report-01.txt>
The MarNEW workshop aimed to discuss solutions for badnwidth
optimisation on mobile networks for encrypted content, as current
solutions rely on unencrypted content which is not indicative of the
security needs of today's internet users. The workshop gathered IETF
attendees, IAB members and various organisations involved in the
telecommunications industry including original equipment
manufacturers and mobile network operators.
The group discussed the current internet encryption trends and
deployment issues identified within the IETF, and the privacy needs
of users which should be adhered. Solutions designed around sharing
data from the network to the endpoints and vice versa were then
discussed as well as analysing whether the current issues experienced
on the transport layer are also playing a role here. Content
providers and CDNs gave an honest view of their experiences delivery
content with mobile network operators. Finally, technical responses
to regulation was discussed to help the regulated industries relay
the issues of impossible to implement or bad-for-privacy technologies
back to regulators.
A group of suggested solutions were devised which will be discussed
in various IETF groups moving forward.
"Structure Identifier (SID)", Abhinav Somaraju, Michel Veillette,
Alexander Pelov, Randy Turner, Ana Minaburo, 2016-03-11,
<draft-somaraju-core-sid-00.txt>
Structured IDentifiers (SID) are used to identify different YANG
items when encoded in CBOR. This document defines the registration
and assignment processes of SIDs. To enable the implementation of
these processes, this document also defines a file format used to
persist and publish assigned SIDs.
"The PKCS #8 EncryptedPrivateKeyInfo Media Type", Sean Leonard,
2016-03-11, <draft-seantek-pkcs8-encrypted-00.txt>
This document registers the application/pkcs8-encrypted media type
for use with the EncryptedPrivateKeyInfo unit of PKCS #8. This format
carries an encrypted private key.
"CoOL Problem Statement", Randy Turner, Michel Veillette, Alexander
Pelov, Abhinav Somaraju, Ana Minaburo, 2016-03-11,
<draft-turner-core-cool-problem-statement-00.txt>
A significant part of the next tens of billion of devices that will
be connected to the Internet will be constrained devices, connecting
over constrained networks. Managing these devices and the networks

they form in a consistent, scalable, extensible, secure, energyefficient manner with low computational and protocol complexity
cannot be done in an ad-hoc manner. This document outlines the
problem at hand and provides a roadmap of the possible solutions
develped at the IETF. The description includes the basic constrained
management problem, as well as properties of the solution. Details
as to the Constrained Objecs Language (CoOL) protocol itself can be
found in companion documents.
"CBOR Encoding of Data Modeled with YANG", Michel Veillette, Alexander
Pelov, Abhinav Somaraju, Randy Turner, Ana Minaburo, 2016-03-11,
<draft-veillette-core-yang-cbor-mapping-00.txt>
This document defines encoding rules for serializing configuration
data, state data, RPC input and RPC output, Action input, Action
output and notifications defined within YANG modules using the
Concise Binary Object Representation (CBOR) [RFC7049].
"DNS Transport over TCP - Operational Requirements", John Kristoff,
2016-03-11, <draft-kristoff-dnsop-dns-tcp-requirements-00.txt>
This document encourages the practice of permitting DNS messages to
be carried over TCP on the Internet. It also describes some of the
consequences of this behavior and the potential operational issues
that can arise when this best common practice is not applied.
"Multi-Stage Transparent Server Load Balancing", Naoki Matsuhira,
2016-03-12, <draft-matsuhira-mslb-00.txt>
This document specifies Multi-Stage Transparent Server Load Balancing
(MSLB) specification. MSLB make server load balancing over Layer3
network without packet header change at client and server. MSLB make
server load balancing with any protocol and protocol with encription
such as IPsec ESP, SSL/TLS.
"Use of BGP for dissemination of ILA mapping information", Petr
Lapukhov, 2016-03-21, <draft-lapukhov-bgp-ila-afi-01.txt>
Identifier-Locator Addressing [I-D.herbert-nvo3-ila] relies on
splitting the 128-bit IPv6 address into identifier and locator parts
to implement identifier mobility, and network virtualization. This
document proposes a method for distributing the identifier to locator
mapping information using Multiprotocol Extensions for BGP-4
[RFC4760].
"Packet Loss measurement for layer2 services", Bharat Gaonkar, Praveen
Ananthasankaran, sudhin jacob, 2016-03-12,
<draft-bhaprasud-lime-pm-00.txt>
This memo defines the loss measurement over a point-to-point service.
Loss will be measured over this service in single class colored and
colorless mode.
"The Constrained RESTful Application Language (CoRAL)", Klaus Hartke,
2016-03-13, <draft-hartke-t2trg-coral-00.txt>
The Constrained RESTful Application Language (CoRAL) is a compact,
binary representation format for hypermedia-driven applications. It
supports links, forms and the embedding of resource representations.

"Kerberos in the Extensible Authentication Protocol (EAP-Kerberos)",

Rick van Rein, 2016-03-13, <draft-vanrein-eap-kerberos-00.txt>
This specification permits Kerberos authentication as part of the
EAP. To support identity bootstrapping during network logon, the
preceding acquisition of tickets may also be passed through this EAP
mechanism.
"OAuth 2.0 Bound Configuration Lookup", Phil Hunt, Anthony Nadalin,
2016-03-13, <draft-hunt-oauth-bound-config-00.txt>
This specification defines a mechanism for the client of an OAuth 2.0
protected resource service to obtain the configuration details of an
OAuth 2.0 authorization server that is capable of authorizing access
to a specific resource service. The information includes the OAuth
2.0 component endpoint location URIs and as well as authorization
server capabilities.
"BGP Link-State extensions for BIER", Ran Chen, Zheng Zhang, Vengada
Govindan, IJsbrand Wijnands, 2016-03-13,
<draft-chenvgovindan-bier-bgp-ls-bier-ext-00.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 perflow 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 addressfamily in order to advertising BIER information.
"Latency Loss Tradeoff PHB Group", Jianjie You, Michael Welzl, Brian
Trammell, Mirja Khlewind, Kevin Smith, 2016-03-13,
<draft-you-tsvwg-latency-loss-tradeoff-00.txt>
This document defines a PHB (Per-Hop Behavior) group called Latency
Loss Tradeoff (LLT). The LLT group is intended to provide delivery
of IP packets in two classes of services: a low-loss service (Lo
service) and a low-latency service (La service). The LLT group
enables an application to request treatment for either low-loss or
low-latency at a congested network link.
"DMARC verification without record definitions", Takehito Akagiri, Genki
Yasutaka, Masaki Kase, Kouji Okada, Kaoru Maeda, 2016-03-13,
<draft-akagiri-dmarc-virtual-verification-00.txt>
DMARC is a powerful architecture to defend mail end users from
malicious mail activities, but its deployment is still under process.
To encourage the installations of DMARC, we propose an incremental
deployment procedure in this document.
"Virtual CPE Deployment Considerations", Byju Pularikkal, Qiao Fu, DENG
Hui, Ganesh Sundaram, Sri Gundavelli, 2016-03-14,

<draft-pularikkal-virtual-cpe-00.txt>
Broadband Service Provider Industry has been gearing towards the
adoption of Virtual CPE (vCPE) solutions. The concept of vCPE is
build around the idea that the physical CPE device at the customer
premises can be simplified by moving some of the key feature
functionalities from the physical CPE device to the Service Provider
Network. This document starts discussing the drivers behind vCPE
adoption followed by Solution level requirements. Two key
Architecture models for vCPE, which can address the service provider
and subscriber requirements, are covered in this reference document.
Document also touches up on some of the key deployment
considerations, which can influence the adoption of the vCPE
architecture models.
"I2RS Data Flow Requirements", Susan Hares, amit.dass@ericsson.com,
2016-05-05, <draft-hares-i2rs-dataflow-req-04.txt,.pdf>
This document covers requests to the netmod and netconf Working
Groups for functionality to support the data flows described in the
I2RS architecture and the I2RS use cases requirements summary.
"IPv4 Declared Historic", Lee Howard, 2016-03-14,
<draft-howard-sunset4-v4historic-00.txt>
IPv4 has been superseded by IPv6, and is therefore Historic.
"Decomposing the Hypertext Transfer Protocol", Mike Bishop, 2016-03-14,
<draft-bishop-httpbis-decomposing-http-00.txt>
The Hypertext Transfer Protocol in its various versions combines
concepts of both an application and transport-layer protocol. As
this group contemplates employing alternate transport protocols
underneath HTTP, this document attempts to delineate the boundaries
between these functions to define a shared vocabulary in discussing
the revision and/or replacement of one or more of these components.
"Implementation Report for BGP FlowSpec RPD", Nan Wu, Shankara Devadiga,
2016-03-15, <draft-wu-idr-flowspec-rpd-impl-00.txt>
BGP FlowSpec Extensions for Routing Policy Distribution (RPD) has
provided a mechanism to use BGP Flowspec address family as routingpolicy distribution protocol.
This document provides an implementation report for RPD mechanism on
inbound-traffic and outbound-traffic adjustment scenarios. What's
more, it gives some details and consideration for exceptions during
development and verification.
"VLAN Extension to DLEP", Ashish Dalela, Arun Parashar, Ananth S,
2016-03-15, <draft-dalela-vlans-and-dlep-01.txt>
This document introduces optional extension to the core DLEP
specification for VLAN encapsulation.
"Carry congestion status in BGP extended community", Zhenqiang Li, Jie
Dong, 2016-03-15,
<draft-li-idr-congestion-status-extended-community-00.txt>
A new extended community is introduced in this document to carry the

link congestion status, especially for the exit link of one AS. We
call this extended community congestion status community, which can
be used by the BGP routers to steer the Internet-access traffic among
the exit links by deploying policy routing.
"Secondary Server-Certificate Authentication in HTTP/2", Mike Bishop,
2016-03-15, <draft-bishop-httpbis-http2-additional-certs-00.txt>
Many HTTP servers host content from several origins. HTTP/2
[RFC7540] permits clients to reuse an existing HTTP connection to a
server provided that certain conditions are satisfied. One of these
conditions is the inclusion of the secondary origin in the
certificate provided during the TLS [I-D.ietf-tls-tls13] handshake.
In many cases, origins will wish to maintain separate certificates
for different origins but still desire the benefits of a shared HTTP
connection. This draft describes how frames which were defined to
transfer client certificates might be used to provide additional
server certificates as well.
"The CCNx URI Scheme", marc.mosko@parc.com, Christopher Wood,
2016-04-06, <draft-mosko-icnrg-ccnxurischeme-01.txt>
This document defines an RFC3986 URI compliant identifier called a
Labeled Segment URI in which name segments carry a label. This
allows differentiation between unrelated resources with similar
identifiers. This document also specifies the CCNx URI scheme,
called "ccnx:," which conforms to the labeled segment encoding rules
presented here. The CCNx URI scheme applies specific labels to each
name segment of a URI to disambiguate between resources with similar
names. This document defines a specific set of segment labels with
label semantics.
"I2RS protocol strawman", Susan Hares, 2016-03-15,
<draft-hares-dt-i2rs-protocol-strawman-00.txt,.pdf>
This document provides a strawman proposal for the I2RS protocol
covering the ephemeral data store and data flow requirements not
covered by i2rs publication/subscription service or traceability. It
also proposes additions to YANG for the ephemeral data store and for
additional data flow requirements. It proposes additions to the
NETCONF and RESTCONF for these additions. Future versions of this
document will propose changes to support the I2RS protocol security
requirements.
"I2RS protocol strawman", Susan Hares, Andy Bierman,
amit.dass@ericsson.com, 2016-05-05,
<draft-hares-i2rs-protocol-strawman-02.txt,.pdf>
This strawman proposal for the I2RS protocol supports I2RS
requirements for ephemeral data store, management data flows, and
protocol security. It proposes additions to the NETCONF, RESTCONF,
and YANG for these requirements.
"IEEE 802.15.4 Information Element for IETF", Tero Kivinen, Pat Kinney,
2016-04-22, <draft-kivinen-802-15-ie-02.txt>
IEEE Std 802.15.4 has Information Elements (IE) that can be used to
extend the 802.15.4 in interoperable manner. IEEE 802.15 Assigned
Numbers Authority (ANA) manages the registry of the Information

Elements, and this document requests ANA to allocate a number for

IETF and provides the information how the IE is formatted to provide
sub types.
"Designating 6LBR for IID Assignment", Abdur Sangi, Mach Chen, Charles
Perkins, 2016-03-16, <draft-rashid-6lo-iid-assignment-00.txt,.pdf>
In IPv6 Stateless Address Autoconfiguration (SLAAC), use of a random
interface identifier (IID) is a common practice to promote privacy.
If there are a very large number of nodes, as has been discussed in
several use cases, the effect will to proportionately increase the
number of IIDs. A duplicate address detection (DAD cycle) is needed
for each configured IID, introducing more and more overhead into the
network. Each failed DAD requires the initiating node to regenerate
a new IID and undergo the DAD cycle again. This document proposes an
optimized approach that requires 6LBR (6LoWPAN Border Router) to
provide a unique IID, avoiding the potential duplication.
"OSPF Corrupted MaxAge LSA Flushing Problem Statement", Jie Dong, Xudong
Zhang, Zhenqiang Li, 2016-03-16,
<draft-dong-ospf-maxage-flush-problem-statement-00.txt>
In OSPF protocol, Link State Advertisements (LSAs) are exchanged in
Link State Update (LSU) packets to achieve link state database (LSDB)
synchronization and consistent route calculation. The "LS age" field
is part of the LSA header, which is excluded from the checksum
calculation of the LSA. Due to some hardware or software problems,
the LS age may be corrupted and reach the MaxAge prematurely.
Flushing of the corrupted MaxAge LSA may cause flooding storm of OSPF
packets and severely impact the services in the network.
This document describes the problem of OSPF corrupted MaxAge LSA
flushing, and specifies the requirements on potential solutions.
"Deterministic Networking Requirements on Data and Control Plane",
Yiyong Zha, 4c 69 61 6e 67, 2016-03-16,
<draft-zha-detnet-requirments-00.txt>
Deterministic Networking (DetNet) is focused on how to serve time
critical flow with low data loss and bounded delay. Unlike
contemporary solution which improves QoS such as TE, redundant
bandwidth provisioning and dedicated channel reservation, DetNet
provides more general approaches that use IP-based techniques and
guarantee the worst-case latency of DetNet flows while allowing
sharing among best-effort flows. For this purpose, DetNet may
require upgraded or redefined data plane as well as control plane,
since current networking cannot assure maximum end-to-end latency.
This document describes some technical requirements on possible
data plane, control plane and DetNet flow modeling that can help
to clarify those capabilities DetNet should have.
"IANA Registry for LISP Packet Type Allocations", Mohamed Boucadair,
Christian Jacquenet, 2016-03-16, <draft-boucadair-lisp-type-iana-00.txt>
This document defines a registry for LISP Packet Type allocations.
It also specifies a shared LISP message type for experimentation
purposes.
"TLS 1.2 Long-term Support Profile", Peter Gutmann, 2016-04-06,
<draft-gutmann-tls-lts-03.txt>

This document specifies a profile of TLS 1.2 for long-term support,

one that incoporates as far as possible what's already deployed for
TLS 1.2 but with the security holes and bugs fixed. This represents
a stable, known-good profile that can be deployed to systems that
can't roll out a new set of patches every month or two when the next
attack on TLS is published.
"MPLS Test Labels", Partha Turaga, Robert Raszuk, 2016-03-16,
<draft-turaga-mpls-test-labels-00.txt>
This document describes an underlying mechanism for automatic
diagnostics of link quality between any two devices connected
together by standard point to point link.
"Special Loop Address", Partha Turaga, Robert Raszuk, 2016-03-16,
<draft-turaga-lmap-special-loop-address-00.txt>
This document describes a method for automatic detection of link
quality issues between two devices connected together by any standard
link in an IP based network. This document focuses on inline
detection in any network attached device (ie server, router, switch
etc..)
"BGP Link-State Extension for Distribution of IP Tunnel Information",
Jie Dong, Zhenbin Li, Jeff Tantsura, Hannes Gredler, 2016-03-16,
<draft-dong-idr-ls-ip-tunnel-00.txt>
This document specifies extensions to BGP-LS for the collection and
distribution of IP tunnel information. Such information can be
distributed to external components for service mapping and tunnel
selection.
"Decoupling scheme for hypervisor from SDN architecture", Rong Gu, Chen
Li, 2016-03-16, <draft-gu-sdnrg-decoupling-scheme-hypervisor-sdn-00.txt>
Different hypervisors are used in SDN network in cloud datacenters,
such as KVM, VMware ESXi and Xen. However, different hypervisors are
not well supported by SDN network to some degrees. In order to solve
the problems with hypervisor VMware ESXi and Xen, decoupling schemes
for hypervisor from SDN architecture are presented. Through
different decoupling schemes, we want to find a better way in order
to get the overall view by the SDN network.
"BGP Flowspec Redirect to VPN RD Extended Community", Lucy Yong, Shunwan
Zhuang, Hao Weiguo, 2016-03-16,
<draft-yong-idr-flowspec-redirect-vpn-rd-00.txt>
This document defines a new type of the redirect extended community,
called as Redirect to VPN RD Extended Community. When activated, the
Redirect to VPN RD Extended Community is used to identify the unique
VPN instance within a router.
"The Use Cases for Using PCE as the Central Controller(PCECC) of LSPs",
Quintin Zhao, Zhenbin Li, Zekung Ke, Luyuan Fang, Chao Zhou, Telus
Communications, 2016-03-17, <draft-zhao-teas-pcecc-use-cases-00.txt>
In certain networks deployment scenarios, service providers would
like to keep all the existing MPLS functionalities in both MPLS and
GMPLS network while removing the complexity of existing signaling

protocols such as LDP and RSVP-TE. In this document, we propose to

use the PCE as a central controller so that LSP can be
calculated/signaled/initiated/downloaded/managed through a
centralized PCE server to each network devices along the LSP path
while leveraging the existing PCE technologies as much as possible.
This draft describes the use cases for using the PCE as the central
controller where LSPs are calculated/setup/initiated/downloaded/
maintained through extending the current PCE architectures and
extending the PCEP.
"L2VPN Service YANG Model", fangwei hu, Ran Chen, Jie Yao, 2016-03-17,
<draft-hu-bess-l2vpn-service-yang-00.txt>
This document defines a YANG data model that can be used to deliver a
Layer 2 Provider Provisioned VPN service. These services include
Virtual Private Wire Service (VPWS) and Virtual Private LAN service
(VPLS). This model is intended to be instantiated at management
system to deliver the L2VPN service, and is not a configuration model
to be used directly on network elements.
This model provides an abstracted view of the Layer 2 VPN service
configuration components. It will be up to a management
system(orchestrator) to take this as an input and use specific
configurations models to configure the different network elements to
deliver the service. It is called as north bound L2VPN Service YANG
data model. How configuration of network elements is out of scope of
the document, and is defined in document[I-D.shah-bess-l2vpn-yang].
"A Framework for Service-Driven Co-Routed MPLS Traffic Engineering
LSPs", Zhenbin Li, Shunwan Zhuang, Jie Dong, 2016-03-17,
<draft-li-teas-serv-driven-co-lsp-fmwk-00.txt>
MPLS Traffic Engineering (TE) has been widely deployed to satifisfy
all kinds of requirements of traffic engineering for transport of
services. Complexity of configuration has much negative effect on
the MPLS TE deployment in the large-scale network. The document
identifies the configuration issues for MPLS TE deployment and
proposes a new mechanism, the service-driven mechanism, by which the
setup of co-routed MPLS Traffic-Engineered Label-Switched Paths(TE
LSPs) is triggered by the bidirectional service. Then the document
proposes the framework for setting up service-driven co-routed MPLS
TE LSP for L2VPN and L3VPN.
"A TLS Extension for Service Indication", Dacheng Zhang, Dapeng Liu,
2016-03-17, <draft-zhang-tls-service-indication-extension-00.txt>
This memo specifies a service indication extension, which is used to
identify the services or contents that a client is trying to access.
This extension can be used in the scenarios such as reverse charging.
"An Information Model for the Monitoring of Network Security Functions
(NSF)", Dacheng Zhang, Yi Wu, Liang Xia, 2016-03-17,
<draft-zhang-i2nsf-info-model-monitoring-00.txt>
In this draft, an information model for the capability interface
monitoring network security functions (NSF) is proposed.
"A YANG profile for defining Asynchronous Management Protocol
Application Data Models", Brian Sipos, Edward Birrane, 2016-04-04,

<draft-bsipos-dtn-amp-yang-01.txt>
This document specifies a YANG profile for defining Application Data
Model (ADM) schema for the Asynchronous Management Protocol (AMP).
The AMP has no relation to NETCONF; YANG is used here only for its
language syntax, and its module and type systems.
"Research into Human Rights Protocol Considerations", Niels Oever,
Corinne Cath, 2016-05-05, <draft-tenoever-hrpc-research-01.txt>
The increased intertwinement of Internet and society increases the
impact of the Internet on the lives of individuals. Because of this,
the design and development of the architecture of the Internet also
has an increasing impact on society. This has led to an increasing
recognition that human rights [UDHR] [ICCPR] [ICESCR] have a role in
the development and management of the Internet [HRC2012] [UNGA2013]
[NETmundial]. It has also been argued that the Internet should be
strenghtened as a human rights enabeling environment [Brown].
This document provides a proposal for a glossary to discuss the
relation between human rights and Internet protocols, an overview of
the discussion, a proposal for the mapping of the relation between
human rights and technical concepts, and a proposal for guidelines
for human rights considerations, similar to the work done on the
guidelines for privacy considerations [RFC6973].
Discussion of this draft at: hrpc@irtf.org //
https://www.irtf.org/mailman/listinfo/hrpc
"DNS Name Autoconfiguration for Internet of Things Devices", Jaehoon
Jeong, Sejun Lee, Park Jung-Soo, 2016-03-17,
<draft-jeong-its-iot-dns-autoconf-00.txt>
This document specifies an autoconfiguration scheme for the global
(or local) DNS names of Internet of Things (IoT) devices, such as
sensors, actuators, and in-vehicle units. By this scheme, the DNS
name of an IoT device can be autoconfigured with the device's
category and model in wired and wireless target networks (e.g.,
vehicle, road network, home, office, shopping mall, and smart grid).
This DNS name lets IoT users (e.g., drivers, passengers, home
residents, and customers) in the Internet (or local network) easily
identify each device for monitoring and remote-controlling it in the
target network.
"A YANG model to manage the optical interface parameters for an external
transponder in a WDM network", Gabriele Galimberti, Ruediger Kunze,
Hing-Kam Lam, Dharini Hiremagalur, Gert Grammel, Luyuan Fang, Gary
Ratterree, 2016-03-17, <draft-dharini-ccamp-dwdm-if-yang-00.txt>
This memo defines a Yang model that translates the SNMP mib module
defined in draft-galikunze-ccamp-dwdm-if-snmp-mib for managing single
channel optical interface parameters of DWDM applications. This
model is to support the optical parameters specified in ITU-T G.698.2
[ITU.G698.2] and application identifiers specified in ITU-T G.874.1
[ITU.G874.1] . Note that G.874.1 encompasses vendor-specific codes,
which if used would make the interface a single vendor IaDI and could
still be managed.
The Yang model defined in this memo can be used for Optical
Parameters monitoring and/or configuration of the endpoints of the

multi-vendor IaDI optical link.

"Algorithm Implementation Requirements and Usage Guidance for DNSSEC",
Paul Wouters, Ond ej Sur, 2016-03-21,
<draft-wouters-sury-dnsop-algorithm-update-01.txt>
The DNSSEC protocol makes use of various cryptographic algorithms in
order to provide authentication of DNS data and proof of nonexistence. To ensure interoperability between DNS resolvers and DNS
authoritative servers, it is necessary to specify a set of algorithm
implementation requirements and usage guidance to ensure that there
is at least one algorithm that all implementations support. This
document defines the current algorithm implementation requirements
and usage guidance for DNSSEC. This document obsoletes RFC-6944.
"Receive-Only Service Function and External Service in SFC", Eric Wang,
Kent Leung, 2016-03-17, <draft-wang-sfc-receive-only-00.txt>
A category of services such as Intrusion
Capture operates in "receive-only" mode.
which consume all packets sent to them.
proposals for such service to be part of
Chaining framework.

Detection Service and Packet

They are "packet sinks"
This document describes the
the Service Function

"TRILL Multilevel Using Unique Nicknames", Mingui Zhang, Donald

Eastlake, Radia Perlman, Margaret Cullen, Hongjun Zhai, 2016-03-18,
<draft-zhang-trill-multilevel-unique-nickname-00.txt>
TRILL routing can be extended to support multiple levels by building
on the multilevel feature of IS-IS routing. Depending on how
nicknames are managed, there are two primary alternatives to realize
TRILL multilevel: the unique nickname approach and the aggregated
nickname approach as discussed in [MultiL]. This document specifies
the unique nickname approach. This approach gives unique nicknames to
all TRILL switches across the multilevel TRILL campus.
"Asymmetrical AODV-P2P-RPL in 6tisch Networks", Satish Anamalamudi,
Mingui Zhang, Charles Perkins, Dongxin Liu, S.V.R Anand, 2016-03-18,
<draft-satish-6tisch-aodv-rpl-00.txt>
Asymmetrical link based time-sensitive traffic flows with highly
reliable shortest end-to-end route discovery is pre-requisite in IPv6
over the TSCH mode of IEEE 802.15.4e (6tisch) Networks. To achieve,
this document specifies a resource reservation based reactive P2P
route discovery mechanism for hop-by-hop routing (storing mode) based
on Ad Hoc On-demand Distance Vector Routing (AODV) RPL protocol for
6tisch Networks. Two separate instances are used to achieve
directional paths based on asymmetric links in between source and
destination.
"Use-cases for Traffic Steering in Operator Networks", Yujia Luo, Liang
Ou, Sujian Lu, Shunwan Zhuang, Nan Wu, 2016-03-18,
<draft-luo-grow-ts-use-cases-00.txt>
Transporting data to their users through operators' networks is a
fundamental service that can benefit both providers and consumers.
Due to the dramatically increased popularity and desire of
differentiated services and their constraints, it is essential for
operators to provide the traffic steering service under limited
network resources and maximize their benefits at the same time.

This document lists some typical use cases for traffic steering
services. This document does not attempt to enumerate all kinds of
scenarios, but rather it describes several key features of these
scenarios from which solutions may be constructed.
"Conveying Vendor-Specific Information in the Path Computation Element
(PCE) Communication Protocol (PCEP) extensions for stateful PCE.", Dhruv
Dhody, 2016-03-18, <draft-dhody-pce-stateful-pce-vendor-00.txt>
A Stateful Path Computation Element (PCE) maintains information on
the current network state, including: computed Label Switched Path
(LSPs), reserved resources within the network, and pending path
computation requests. This information may then be considered when
computing new traffic engineered LSPs, and for associated and
dependent LSPs, received from Path Computation Clients (PCCs).
RFC 7470 defines a facility to carry vendor-specific information in
PCEP.
This document extends this capability for stateful PCE.
"BIER-TE Ping and Trace", Ran Chen, Shaofu Peng, 2016-03-18,
<draft-chen-bier-te-ping-00.txt>
Bit Index Explicit Replication (BIER)-TE shares architecture and
packet formats with BIER as described in
[I-D.ietf-bier-architecture]. BIER-TE forwards and replicates
packets based on a BitString in the packet header, but every
BitPosition of the BitString of a BIER-TE packet indicates one or
more adjacencies.
This document describes the mechanism and basic BIER-TE OAM packet
format that can be used to perform Ping and Traceroute on BIER-TE
network.
"PCEP Extensions for Bidirectional Forwarding Detection", Zhenbin Li,
Xia Chen, 2016-03-18, <draft-li-pce-bfd-00.txt>
This document describes the extensions to the PCEP to notify BFD
parameters for LSPs from PCE to PCC for PCE-initiated LSP. The
extensions include BFD protocol parameters and allow PCC to support
BFD for PCE-Initiated LSP whose BFD session is a bi-directional corouted channel.
"I2NSF Management Traffic Flow Requirement", Susan Hares, 2016-03-20,
<draft-hares-i2nsf-mgtflow-reqs-01.txt,.pdf>
This document discuss the stresses on I2NSF management traffic during
periods DDoS and network attacks, and how application layer tuning of
I2NSF management traffic can improve the managementtraffic flow.
"Data-plane probe for in-band telemetry collection", Petr Lapukhov,
2016-03-18, <draft-lapukhov-dataplane-probe-00.txt>
Detecting and isolating network faults in IP networks has
traditionally been done using tools like ping and traceroute (see
[RFC7276]) or more complex systems built on similar concepts of
active probing and path tracing. While using active synthetic probes
is proven to be helpful in detecting data-plane faults, isolating

fault location has proven to be a much harder problem, especially in

diverse networks with multiple active forwarding planes (e.g. IP and
MPLS). Moreover, existing end-to-end tools do not generally support
functionality beyond dealing with packet loss - for example, they are
hardly useful for detecting and reporting transient (i.e. milli- or
even micro-second) network congestion.
Modern network forwarding hardware can enable more sophisticated
data-plane functionality that provides substantial improvement to the
isolation and identification capabilities of network elements. For
example, it has become possible to encode a snapshot of a network
elements forwarding state within the packet payload as it transits
the device. One example of such device/network state would be queue
depth on the egress port taken by that specific packet. When
combined with a unique device identifier embedded in the same packet,
this could allow for precise time and topological identification of
the the congested location within the network.
This document proposes a standard format for embedding telemetry
information in UDP-based probing packets, i.e. packets designated for
testing the network while not carrying application traffic. These
active probes could be conveyed over multiple protocols (ICMP, UDP,
TCP, etc.) but this document specifically focuses on UDP, given its
simple semantics. In addition this document provides recommendations
on handling the active probes by devices that do not support the
required data-plane functionality.
"SCIM Polling Protocol", Craig McMurtry, 2016-04-04,
<draft-mcmurtry-scim-polling-01.txt>
This document specifies a protocol by which a System for Cross-Domain
Identity Management Protocol (SCIM) client can poll a SCIM service
provider for the current states of resources that have changed since a
given point in time.
"Quantisation matrices for Thor video coding", Thomas Davies,
2016-03-18, <draft-davies-netvc-qmtx-00.txt>
This draft describes a family of default quantisation matrices
that may be used to improve perceptual quality when encoding with
Thor. Similar quantisation matrix designs may be used in most
block-based video and image codecs.
"Yang Data Model for IKEv2", Khanh Tran, Daniel Migault, Honglei Wang,
Vijay Nagaraj, Xia Chen, 2016-03-18,
<draft-tran-ipsecme-ikev2-yang-00.txt>
This document defines a YANG data model that can be used to
configure and manage Internet Key Exchange version 2 (IKEv2). The
model covers the IKEv2 protocol configuration and operational state.
"Requirements for mounting of local and remote YANG subtrees", Eric
Voit, Alex Clemm, Sander Mertens, 2016-03-18,
<draft-voit-netmod-yang-mount-requirements-00.txt>
Applications want simple ways to reference and access YANG objects
and subtrees. These simplifications might include aliasing of local
YANG information. These simplifications might include remote
referencing of YANG information distributed across network.

For such applications, development complexity is a barrier to YANG

usage and therefore must be minimized. Specific aspects of
complexity developers want to ignore include:
o whether context specific aliases and paths to the same information
can be exposed on a single device,
o whether authoritative information is actually sourced from local
or remote datastores,
o whether the application needs to manage the overhead of session
establishment and maintenance in order to access information on
remote datastores,
o whether objects have been locally cached or not, and
o whether there is a mix of controllers, NMSs, and/or CLI which have
access permission to update the primary copy of a particular
object.
The solution requirements described in this document detail what is
needed to support application access to authoritative network YANG
objects locally (via aliasing), or remotely from controllers or
peering network devices in such a way to meet these goals.
"A PFS-preserving protocol for LURK", Samuel Erb, Rich Salz, 2016-03-18,
<draft-erb-lurk-rsalg-00.txt>
This document defines a protocol between a content provider and an
external key owner that enables the provider to act as a TLS
termination end-point for the key owner, without having the key
actually being provisioned at the provider.
The protocol between the two preserves forward secrecy, and is also
designed to prevent the use of the key owner as a general-purpose
signing oracle which would make it complicit in attacks against uses
of the very keys it is trying to protect.
"Selective Advertisement of Multiple Paths within BGP", Keyur Patel,
Acee Lindem, 2016-03-18,
<draft-keyupate-idr-bgp-selective-add-paths-00.txt>
Originally, a BGP speaker was only allowed to advertise one path to
any given address prefix. If the BGP speaker advertised a second
path to a given prefix, the second path was considered to be a
replacement for the first. The BGP ADD-PATH capability was defined
to enable a BGP speaker to advertise multiple paths to a given
address prefix, without one path replacing any of the others.
However, whether a BGP speaker advertises multiple paths for any
given prefix is always a matter of local policy for that BGP speaker.
In certain situations, it is desirable to allow a BGP speaker to
signal to its peers that the peers may advertise multiple
simultaneous paths for certain prefixes but not for others. This
document defines a new BGP capability, the Selective ADD-PATH
capability, that allows a BGP speaker to signal to its peers whether
a particular prefix is or is not eligible to have multiple paths
advertised.
"Hypertext Transfer Protocol (HTTP/1.1): Activity Identifiers", Scott
Perham, 2016-03-18, <draft-activity-identifiers-00.txt>

It is very common that implementers of HTTP severs require the ability

to associate an identifier to an HTTP request and or response, this can
be for a number of reasons which could include checking for duplicate
requests, allowing the caller of an API to maintain a record of their
interaction with the server or to track client/server requests through
a disparate system of services. In any case, the implementer will quite
often use a custom HTTP header and either assign a value itself or
require the caller to supply the value. This document outlines a
consistent storage mechanism for this identifier by way of a standard
HTTP header and a new status code for when a mandated identifier is
omitted. The purpose is to create better consistency for clients of
third-party HTTP servers and HTTP based APIs by introducing this
standard request and response header.
"A YANG Data Model for Configuration Scheduling", Xufeng Liu, Igor
Bryskin, Vishnu Pavan Beeram, Tarek Saad, Himanshu Shah, Oscar Gonzalez
de Dios, 2016-03-18, <draft-liu-netmod-yang-schedule-00.txt>
This document describes a data model grouping for configuration
scheduling.
"Limited Use of Remote Keys, Protocol and Reference.", Phillip
Hallam-Baker, 2016-04-04, <draft-hallambaker-lurk-02.txt>
The Limited Use of Remote Keys (LURK) BOF has been scheduled with the
objective of discussing approaches to mitigating security risks to
TLS private keys. In particular in situations where a Content
Delivery Network (CDN) is used to deliver content and thus the party
that is being authenticated is not the party that the user is
attempting to authenticate.
Three classes of solution are considered, short term credentials, a
remote service offering to perform private key operations and a
remote service that is further constrained through the use of some
form of threshold approach. A JSON/HTTP protocol implementing the
second and third protocol is demonstrated and documented.
"PCE Hierarchical SDNs", Huaimo Chen, Mehmet Toy, Lei Liu, Vic Liu,
2016-03-18, <draft-chen-pce-h-sdns-00.txt>
This document presents extensions to the Path Computation Element
Communication Protocol (PCEP) for supporting a hierarchical SDN
control system, which comprises multiple SDN controllers controlling
a network with a number of domains.
"EVPN Generic Route Type", Jorge Rabadan, Martin Vigoureux, Mallika
Gautam, Siddhesh Dindorkar, 2016-03-19,
<draft-rabadan-bess-vendor-evpn-route-00.txt>
RFC7432 defines Ethernet VPN as a BGP address family that makes use
of Typed NLRIs. IANA has a registry called "EVPN Route Types" that
allocates values to Route Types. The purpose of this document is to
solicit IANA the registration of a route type value for a vendor
specific usage, as well as the definition of the EVPN NLRI for that
route.
"Additional Considerations for UDP Encapsulation of Stream Control
Transmission Protocol (SCTP) Packets", Michael Tuexen, Randall Stewart,
2016-03-19, <draft-tuexen-tsvwg-sctp-udp-encaps-cons-00.txt>

RFC 6951 specifies the UDP encapsulation of SCTP packets. The

described handling of received packets requires the check of the
verification tag. However, RFC 6951 misses a specification for the
handling of received packets for which this check is not possible.
This document updates RFC 6951 by specifying the handling of received
packets where the verification tag can not be checked.
"Requirements for CoAP End-To-End Security", Goran Selander, Francesca
Palombini, Klaus Hartke, Ludwig Seitz, 2016-03-19,
<draft-hartke-core-e2e-security-reqs-00.txt>
This document analyses threats to CoAP message exchanges traversing
proxies and derives the security requirements for mitigating those
threats.
"Distributed-Denial-of-Service (DDoS) Open Threat Signaling
Architecture", Andrew Mortensen, Flemming Andreasen, Tirumaleswar Reddy,
Christopher Gray, R. Compton, Nik Teague, 2016-03-19,
<draft-mortensen-dots-architecture-00.txt>
This document describes an architecture for establishing and
maintaining Distributed Denial of Service (DDoS) Open Threat
Signaling (DOTS) within and between networks. The document makes no
attempt to suggest protocols or protocol extensions, instead focusing
on architectural relationships, components and concepts used in a
DOTS deployment.
"Advertising Segment Routing Traffic Engineering Policies in BGP",
Stefano Previdi, Clarence Filsfils, Arjun Sreekantiah, Siva Sivabalan,
Paul Mattes, 2016-03-20,
<draft-previdi-idr-segment-routing-te-policy-00.txt>
This document defines a new BGP SAFI with a new NLRI in order to
advertise a Segment Routing Traffic Engineering Policy (SR TE
Policy). The SR TE Policy is advertised along with the Tunnel
Encapsulation Attribute for which this document also defines new subTLVs. An SR TE policy is advertised with the information that will
be used by the node receiving the advertisement in order to
instantiate the policy in its forwarding table and to steer traffic
according to the policy.
"YANG Data Model for Layer 3 TE Topologies", Xufeng Liu, Igor Bryskin,
Vishnu Pavan Beeram, Tarek Saad, Himanshu Shah, Oscar Gonzalez de Dios,
2016-03-20, <draft-liu-teas-yang-l3-te-topo-00.txt>
This document defines a YANG data model for layer 3 traffic
engineering topologies.
"6top Protocol (6P)", Qin Wang, Xavier Vilajosana, 2016-03-20,
<draft-wang-6tisch-6top-protocol-00.txt>
This document defines the 6top Protocol (6P), which enables
distributed scheduling in 6TiSCH networks. 6P allows neighbor nodes
in a 6TiSCH network to add/delete TSCH cells to one another. 6P is
part of the 6TiSCH Operation Sublayer (6top), the next higher layer
of the IEEE802.15.4 TSCH medium access control layer. The 6top
Scheduling Function (SF) decides when to add/delete cells, and
triggers 6P transactions. Several SFs can be defined, each

identified by a different 6top Scheduling Function Identifier (SFID).

This document lists the requirements for an SF, but leaves the
definition of the SF out of scope. Different SFs are expected to be
defined in future companion specifications.
"Resource Indicators for OAuth 2.0", Brian Campbell, J. Bradley, Hannes
Tschofenig, 2016-03-21,
<draft-campbell-oauth-resource-indicators-01.txt,.pdf>
This straw-man specification defines an extension to The OAuth 2.0
Authorization Framework that enables the client and authorization
server to more explicitly to communicate about the protected
resource(s) to be accessed.
"Identity Event Token", Phil Hunt, W. Denniss, Morteza Ansari,
2016-04-08, <draft-hunt-idevent-token-01.txt>
This specification defines an Identity Event token which may be
distributed via a protocol such as HTTP. An identity event token is
based on the JSON Web Token and may be optionally signed and/or
encrypted. It describes a statement of fact that may be shared by an
event publisher with registered subscribers.
"SCIM Event Extension", Phil Hunt, W. Denniss, Morteza Ansari,
2016-03-20, <draft-hunt-idevent-scim-00.txt>
This specification profiles the Identity Event Token specification to
define a set of identity events to be used with SCIM.
"NETCONF Event Notifications", Alberto Prieto, Alex Clemm, Eric Voit,
Einar, Ambika Tripathy, 2016-03-21,
<draft-gonzalez-netconf-5277bis-01.txt>
This document defines capabilities and operations for providing
asynchronous message notification delivery on top of the Network
Configuration protocol (NETCONF). This notification delivery is an
optional capability built on top of the base NETCONF definition.
This document is eventually intended to obsolete RFC 5277.
"Packet-Optical Integration in Segment Routing", Madhukar Anand, Sanjoy
Bardhan, Ramesh Subrahmaniam, 2016-03-20,
<draft-anand-spring-poi-sr-00.txt>
This document illustrates a way to integrate a new class of nodes and
links in segment routing to represent networks in an opaque way for
further extensibility of the link-state protocols that help with
segment routing. An instance of the opaque definition 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
opaque 'segments' or sub-paths as an augmentation to the defined
extensions of segment routing. This opaque option defines a general
mechanism to allow for future extensibility of segment routing.
"P-Served-User Header Field Parameter for Originating CDIV session case
in Session Initiation Protocol (SIP)", Marianne Mohali, 2016-04-12,
<draft-mohali-dispatch-originating-cdiv-parameter-01.txt>
This specification defines a new Session Initiation Protocol (SIP) PServed-User header field parameter, "orig-cdiv-param", which defines

the session case used by a proxy when handling an originating session

after Call Diversion (CDIV) services has been invoked for the served
user. The P-Served-User header field is defined in [RFC5502]. The
P-Served-User header field conveys the identity of the served user
and the session case that applies to this particular communication
session and application invocation.
This document updates [RFC5502] in order to add the originating after
CDIV session case.
"Interworking SFC network and Overlay network", Ting Ao, 2016-03-20,
<draft-ao-sfc-overlay-00.txt>
For SFC, it's generally transmitted over an overlay network, such as
Vxlan network. This document describes how to interwork SFC network
with an overlay network. Especially, when overlay network edge
devide NVE is seperate with SFF, this document provide a suggestion
to make sure SFC traffic can forwarded properly in the overlay
network.
"Operation Recommendations for DNS Cache Service", Dapeng Liu, Zhihui
Liu, Zhiwei Yan, Lanlan Pan, Guanggang Geng, 2016-03-20,
<draft-liu-dnsop-dns-cache-00.txt>
In this document, we give some recommendations to operate the DNS
cache service based on our previous work and practice.
"Gap Analysis of Scalable Synchronization Networks", Yuanlong Jiang,
Xian Liu, 4c 69 61 6e 67, Daniel Venmani, 2016-03-21,
<draft-jiang-scsn-gap-analysis-00.txt>
This draft provides a gap analysis for the Scalable Synchronization
Networks (SCSN). The document provides an overview of the existing
standardization work on synchronization solutions, and outlines some
of the important features with regard to scalability that are still
missing in current synchronization networks.
"A YANG model to manage the optical optical parameters for in a WDM
network", Gabriele Galimberti, Ruediger Kunze, Dharini Hiremagalur, Gert
Grammel, 2016-03-21, <draft-galimbe-ccamp-iv-yang-00.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-ietfccamp-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
"Traffic Distribution for GRE Tunnel Bonding", Jianjie You, Mingui
Zhang, Nicolai Leymann, Cornelius Heidemann, 2016-03-21,
<draft-you-traffic-distribution-for-bonding-00.txt>
GRE (Generic Routing Encapsulation) Tunnel Bonding as an L3 overlay
tunneling mechanism is used for Hybrid Access (HA) bonding between
HCPE (Hybrid Customer Premises Equipment) and HAG (Hybrid Access
Gateway). The bonding performance depends upon the performance for

each individual link. This document specifies a trying overflow

mechanism to avoid the bonding performance downgrading due to the
situation that an individual link is disrupted or its quality
downgrages too much so that the bonding is no longer applicable.
"Flow Control for Bonding Tunnels", Mingui Zhang, Nicolai Leymann,
Cornelius Heidemann, Margaret Cullen, 2016-03-21,
<draft-zhang-banana-tcp-in-bonding-tunnels-00.txt>
Tunnel bonding enables Bandwidth Aggregation across multiple Internet
access links. From the practice of deployment, flow control is a
desirable feature of the bonding tunnel. This document explores the
way to equip bonding tunnel with flow control mechanism.
"A Configuration File Format for Network Services on Leaf Devices",
Stefan Winter, 2016-03-21,
<draft-winter-opsec-netconfig-metadata-00.txt>
This document specifies a YANG module for transfering configuration
information of deployments of network services towards leaf nodes
(hosts) on the internet. Such configuration files are meant to be
discovered, consumed and used by configuration agents on the host to
achieve correct and secure setup of these services on the consuming
device. This iteration of the I-D concentrates on Wi-Fi network
setup and EAP credentials, but is extensible to cover a wide range
including VPN, E-Mail and other services.
"IS-IS Extensions for Segment Path Programming", Zhenbin Li, Nan Wu,
2016-03-21, <draft-li-isis-spp-extensions-00.txt>
Segment Routing (SR) facilitates the steering of unicast traffic
through leveraging the source routing paradigm. As introduced in
Segment Path Programming (SPP), the concept of segment could be used
in a more generalized manner that may be beyond reachability. This
document describes the necessary IS-IS extensions for those cases.
"Analytic Framework for NFV Orchestrator", Vic Liu, 2016-03-21,
<draft-liu-nfvrg-analytic-framework-00.txt>
This draft introduces an analytic model and framework with data
collection and policy management in NFV Orchestrator.
"Co-Constraints for JSON Content Rules", Pete Cordell, Andrew Newton,
2016-03-21, <draft-cordell-jcr-co-constraints-00.txt>
JSON Content Rules (JCR) [JCR] provides a powerful, intuitive and
concise method for defining the structure of JSON [RFC7159] messages.
However, modern JSON usage patterns occasionally mean that JCR alone
is not able to capture the required constraints in a satisfactory
way. This document describes JCR Co-Constraints (JCRCC) which
defines additional JCR directives and annotations that can be added
to a JCR ruleset in order to define more detailed constraints on JSON
messages.
"Integrated Mobile Fronthaul and Backhaul", Jing Huang, 2016-03-21,
<draft-huang-detnet-xhaul-00.txt>
Ethernet can be a very promising technology for mobile Fronthaul and
Backhaul traffic transportation, even an integrated Fronthaul /
Backhaul (XHaul), although there are still some challenges. This

memo tries to analyze some of the challenges and issues, such as L2

or L3 (MPLS/IP) forwarding, packet loss, etc., and to find out some
requirements.
"BGP RR Benchmarking Methodology", Gregory Lasserre, jgc, Carsten
Rossenhoevel, Guillaume Gaulon, 2016-03-21,
<draft-lasserre-bgp-rr-benchmark-method-00.txt>
BGP is commonly used with network operators in order to distribute
routing information for both infrastructure routes as well as service
routing information. BGP is used due to its ability to handle high
amounts of prefixes and paths information coupled with administrative
attributes, such as communities, in a reliable and scalable manner.
A route-reflector is a key network component of BGP as it propose an
alternative to internal border gateway protocol (iBGP) fully-meshed
peering requirement. By acting as a concentration point it learns,
process, and reflect prefixes from and to all its iBGP Peers also
referred as route-reflector clients, and is a key element of such
networks performances.
As today networks grow in terms of size and offered services, this
translates into more prefixes to be handled by BGP Route-Reflectors,
and there is a demand by service providers to be able to benchmark
this key function in a realistic and consistent manner.
This document covers how to provide an accurate BGP route-reflector
benchmark.
"GPCOMP", Robert Moskowitz, Susan Hares, Igor Faynberg, Huilan Lu,
Pierpaolo Giacomin, 2016-03-21, <draft-moskowitz-gpcomp-00.txt>
This document describes a protocol intended to provide lossless
compression for use within any datagram. It is particularly intended
for use in encrypted datagrams where lower-level compression is
ineffective.
"Security alerts over the first MILE", Robert Moskowitz, Susan Hares,
Liang Xia, 2016-03-21, <draft-moskowitz-firstmile-00.txt>
This document describes a pub/sub styled protocol to send security
alerts to a security monitor that can feed into MILE and other
management platforms. It uses data structures from NETCONF, MILE,
and IPFIX to manage the reporting and report security alerts.
"Problem Statements of Scalable Synchronization Networks", Liuyan Han,
Yuanlong Jiang, Jinchun Xu, Xian Liu, Daniel Venmani, 2016-03-21,
<draft-hjxl-scsn-ps-00.txt>
With the wide deployment of 4G and beyond mobile networks, a great
number of cells need high precision frequency and/or time
synchronization for their normal operation. It is crucial to
configure and manage the synchronization network in a scalable way,
and simplify the monitoring and operation for synchronization
networks. This document analyzes the use cases and requirements in
synchronization networks, and provides a problem statement for
scalable synchronization networks.
"A YANG data model for Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD)", Xufeng Liu, Feng Guo, Mahesh

Sivakumar, Pete McAllister, Anish Peter, 2016-03-21,

<draft-guo-pim-igmp-mld-yang-01.txt>
This document defines a YANG data model that can be used to
configure and manage Internet Group Management Protocol (IGMP) and
Multicast Listener Discovery (MLD) devices.
"Data Security Maturity Model", Kepeng Li, 2016-03-21,
<draft-li-saag-data-security-maturity-model-00.txt>
Data Security Maturity Model (DSMM) provides a multi-level maturity
model to help organizations to measure their data security capability
maturity level, identify issues related to data security capability,
and improve their data security capability.
"DOTS Secure Session Layer Services", Robert Moskowitz, Susan Hares,
2016-03-21, <draft-moskowitz-dots-ssls-02.txt>
This document describes using a session layer service for DOTS
messaging to provide secure messaging while delivering on a number of
DOTS requirements including avoiding fate-sharing with the underlying communications.
"Analysis of IPv6 over LPWAN: design space and challenges", Carles
Gomez, Josep Paradells, Jon Crowcroft, 2016-03-21,
<draft-gomez-lpwan-ipv6-analysis-00.txt>
Connecting Low Power Wide Area Networks (LPWANs) to the Internet is
expected to provide significant benefits to these networks in terms
of interoperability, application deployment, and management, among
others. However, the constraints of LPWANs, often more extreme than
those of typical 6Lo(WPAN) technologies, constitute a challenge for
the 6LoWPAN suite in order to enable IPv6 over LPWAN. Considering
the typical characteristics of LPWAN technologies, this document
analyzes the design space and challenges related with enabling IPv6
over LPWAN.
"SUPA Value Proposition", Maxim Klyus, John Strassner, Shucheng LIU,
Georgios Karagiannis, Jun Bi, 2016-03-21,
<draft-klyus-supa-value-proposition-00.txt>
Simplified Use of Policy Abstractions (SUPA) defines a set of rules
that define how services are designed, delivered, and operated
within an operator's environment independent of any one particular
service or networking device. SUPA expresses policy rules using a
generic policy information model, which serves as a unifying
influence to enable different data model implementations to be
simultaneously developed.
"BGP Flow Specification MPLS action", LQD, Susan Hares, Jianjie You,
Robert Raszuk, danma@cisco.com, 2016-03-21,
<draft-liang-idr-flowspec-mpls-action-00.txt,.pdf>
This document specifies a BGP Flow specification policy action to
push/pop/swap MPLS labels.
"Overlay OAM Requirements", Nagendra Kumar, Carlos Pignataro, Deepak
Kumar, Greg Mirsky, Mach Chen, Erik Nordmark, Juniper Networks, David
Mozes, 2016-03-21, <draft-ooamdt-rtgwg-ooam-requirement-00.txt>

This document describes a list of functional requirements for

Operations Administration and Maintenance (OAM) in various Overlay
and Service networks like Service Function Chaining (SFC), Bit Index
Explicit Replication (BIER), Network Virtualization over Layer 3
(NVO3).
"Cross-layer Cooperation for Encrypted Traffic", Hao Chen, Yue Yin, Ge
Chen, 2016-03-21, <draft-chen-tsvwg-crosslayer-cooperation-00.txt>
This memo mainly considers the requirement and feasibility of crosslayer design in the encrypted traffic scenario.
By permitting the interaction between the encrypted application layer
and non-encrypted transport/network layer, the network layer may
schedule service flow more properly and the application layer may
know the network status information well, which actually optimize the
network bandwidth.
"The STRIDE towards IPv6: A Threat Model for IPv6 Transition
Technologies", Marius, 2016-03-21,
<draft-georgescu-opsec-ipv6-trans-tech-threat-model-00.txt>
This document provides a structured approach for analyzing the
threats associated with the various IPv6 transition technologies
specified by the IETF. The threat model is built around the
established STRIDE threat classification and is aimed at existing
IPv6 transition technologies, as well as their future developments.
"Cryptographic Algorithm Implementation Requirements and Usage Guidance
for Encapsulating Security Payload (ESP) and Authentication Header
(AH)", Daniel Migault, John Mattsson, Paul Wouters, Yoav Nir,
2016-03-21, <draft-mglt-ipsecme-rfc7321bis-00.txt>
This document updates the Cryptographic Algorithm Implementation
Requirements for ESP and AH. The goal of these document is to enable
ESP and AH to benefit from cryptography that is up to date while
making IPsec interoperable.
This document obsoletes RFC 7321 on the cryptographic recommendations
only.
"Secure Session Layer Services", Susan Hares, Robert Moskowitz,
2016-03-21, <draft-hares-i2nsf-ssls-00.txt,.pdf>
Each I2NSF agent and I2NSF client needs to provide application level
support for management traffic during periods of DDoS and network
security attacks to deal with congestion (burst and/or continuous),
high error rates and packet loss due to the attacks, and the
inability to utilize a transport protocol (E.g. TCP) due to a
specific protocol attack. This application level support needs to be
able to select the key management system and provide "chunking" of
data (in order to fit in reduced effective MTUs), compression of data
(in order to fit into reduced bandwidth), small security envelope )in
order to maximize room for mangement payload), and fragmentation and
reassembly at the application layer for those protocols which do not
support fragmentation/reassembly (E.g. UDP or SMS). The application
layer needs to be able to turn off this features if the system
detects these features are no longer needed.
This draft specifies a security session layer services(SSLs) which

provide these features in terms of an API, and the component features

(interface to key management systems, data compression, chunking of
data, secure session envelope (SSE) to send data, and fragmentation
and reassembly, and ability to detect existence of attack).
"Route Leak Detection and Filtering using Roles in Update and Open
messages", A. Azimov, Eugene Bogomazov, Randy Bush, 2016-03-21,
<draft-ymbk-idr-bgp-open-policy-00.txt>
Route Leaks are propagation of BGP prefixes which violate assumptions
of BGP topology relationships; e.g. passing a route learned from one
peer to another peer or to a transit provider, passing a route
learned from one transit provider to another transit provider or to a
peer. Today, approaches to leak prevention rely on marking routes
according to some configuration options without any check of the
configuration corresponds to that of the BGP neighbor, or enforcement
that the two BGP speakers agree on the relationship. This document
enhances BGP Open to establish agreement of the (peer, customer,
provider, internal) relationship of two BGP neighboring speakers to
enforce appropriate configuration on both sides. Propagated routes
are then marked with a flag according to agreed relationship allowing
detection and mitigation of route leaks.
"Problem statement for centralized address management", Chongfeng Xie,
Qiong, Weiping Xu, Shucheng LIU, Ian Farrer, 2016-03-21,
<draft-xie-ps-centralized-address-management-00.txt>
The increase in number, diversity and complexity of modern network
devices and services bring new challenges for the management of
network resources, such as IP addresses, bandwidth, VAS(Value Added
Service) pool, etc. This draft contains a problem statement and
defines the requirements for IP address management with practical use
cases provided by operators.
"Ephemeral Diffie-Hellman Over COSE (EDHOC)", Goran Selander, John
Mattsson, Francesca Palombini, 2016-04-03,
<draft-selander-ace-cose-ecdhe-01.txt>
This document specifies Diffie-Hellman key exchange with ephemeral
keys embedded in messages encoded with the CBOR Encoded Message
Syntax.
"VNF Benchmarking Methodology", Raphael Rosa, Robert Szabo, 2016-03-21,
<draft-rosa-bmwg-vnfbench-00.txt>
This document describes VNF benchmarking methodologies.
"Bidirectional Forwarding Detection (BFD) on Multi-chassis Ling
Aggregation Group (MC-LAG) Interfaces in IP/MPLS Networks", Greg Mirsky,
Jeff Tantsura, 2016-03-21, <draft-tanmir-rtgwg-bfd-mc-lag-mpls-00.txt>
This document discusses use of Bidirectional Forwarding Detection for
Multi-chassis Link Aggregation Group to provide faster than Link
Aggregation Control Protocol convergence.
"Bidirectional Forwarding Detection (BFD) on Multi-chassis Ling
Aggregation Group (MC-LAG) Interfaces in IP Networks", Greg Mirsky, Jeff
Tantsura, 2016-03-21, <draft-tanmir-rtgwg-bfd-mc-lag-ip-00.txt>
This document discusses use of Bidirectional Forwarding Detection for

Multi-chassis Link Aggregation Group to provide faster than Link

Aggregation Control Protocol convergence.
"Node Protection for SR-TE Paths", Shraddha Hegde, Chris Bowers,
2016-03-21,
<draft-hegde-spring-node-protection-for-sr-te-paths-00.txt,.pdf>
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.
"Mandating use of IPv6 in examples", Andrei Robachevsky, 2016-04-07,
<draft-robachevsky-mandating-use-of-ipv6-examples-01.txt>
IPv6 is a successor of the legacy IPv4 protocol. This document
strongly recommends use of IPv6 in examples provided in RFCs.
"TCP in UDP", Michael Welzl, Safiqul Islam, Kristian Hiorth, Jianjie
You, 2016-03-21, <draft-welzl-irtf-iccrg-tcp-in-udp-00.txt>
This document specifies a method to encapsulate multiple TCP
connections using only one UDP port number pair. Doing so allows for
a relatively easy implementation of coupled congestion control for
the TCP connections. This can have several performance benefits, and
it makes it possible to precisely assign a share of the congestion
window to the connections based on priorities. It also enables use
of UDP-based NAT traversal techniques, and it can act as a framework
for experimentation with novel changes to the TCP standard.
"IPv6 DOTS Signal Option", Jerome Francois, Abdelkader Lahmadi, Giovane
Moura, Marco Davids, 2016-03-21,
<draft-francois-ipv6-dots-signal-option-00.txt>
This document describes a delivery mechanism based on the IPv6 Hopby-Hop options extension header type to carry a DOTS client signal
message over a congested network due to a DDoS attack. The specified
mechanism allows the DOTS client signal message to be included using
an opportunistic way in outgoing IPv6 packets traveling then through
the network to reach a DOTS server or relay.
"Observations on Deploying New DNSSEC Cryptographic Algorithms",
york@isoc.org, Ond ej Sur, Paul Wouters, lafur Gumundsson,
2016-03-21, <draft-york-dnsop-deploying-dnssec-crypto-algs-00.txt>
As new cryptographic algorithms are developed for use in DNSSEC
signing and validation, this document captures the steps needed for
new algorithms to be deployed and enter general usage. The intent is
to ensure a common understanding of the typical deployment process
and potentially identify opportunities for improvement of operations.
"Efficient Patterns for Service Function Chaining within Network

Function Virtualization Infrastructure", David Dolson, Michael

Marchetti, Kyle Larose, 2016-03-21,
<draft-dolson-sfc-nfv-patterns-00.txt>
The document presents some considerations for efficiently deploying
Service Function Chaining (SFC) within a Network Function
Virtualization Infrastructure (NFVI).
"A Multi-Domain Multi-Technology SFC Control Plane Experiment: A UNIFYed
Approach", Robert Szabo, Balazs Sonkoly, 2016-03-21,
<draft-unify-sfc-control-plane-exp-00.txt>
This document reports on the experimentation with a combined Network
Function Virtualization (NFV) orchestrator and Service Function Chain
(SFC) Control Plane proof of concept prototype.
"NSH Context Header Allocation -- Broadband", Jeffrey Napper, Surendra,
Praveen Muley, Wim Henderickx, 2016-03-21,
<draft-napper-sfc-nsh-broadband-allocation-00.txt>
This document provides a recommended allocation of context headers
for a Network Service Header (NSH) within the broadband service
provider network context. NSH is described in detail in
[ietf-sfc-nsh]. This allocation is intended to support uses cases as
defined in [ietf-sfc-use-case-mobility].
"TRILL: ECN (Explicit Congestion Notification) Support", Donald
Eastlake, Bob Briscoe, 2016-03-21,
<draft-eastlake-trill-ecn-support-00.txt>
Explicit congestion notification (ECN) allows a forwarding element to
notify downstream devices, including the destination, of the onset of
congestion without having to drop packets. This document extends this
capability to TRILL switches, including integration with IP ECN.
"DNS Editing Through HTTPS (DETH)", Joe Hildebrand, Paul Hoffman,
2016-03-21, <draft-hildebrand-deth-00.txt>
There is a strong desire in many communities for service operators to
be able to dynamically update DNS records in an easy-to-deploy,
standardized method. For example, operating SIP requires DNS records
to be added and updated as the SIP service starts and is moved among
different servers. This document describes an HTTPS-based mechanism
for service operators who are authorized by their DNS administrator
to add, change, and delete DNS records.
"Operations, Administration and Maintenance (OAM) for Overlay Networks:
Gap Analysis", Greg Mirsky, Erik Nordmark, Carlos Pignataro, Nagendra
Kumar, Deepak Kumar, Mach Chen, David Mozes, Juniper Networks,
2016-03-21, <draft-ooamdt-rtgwg-oam-gap-analysis-01.txt>
This document provides an overview of the Operations, Administration,
and Maintenance (OAM) for overlay networks. The OAM toolset includes
set of fault management and performance monitoring capabilities
(operating in the data plane) that comply with the Overlay OAM
Requirements. Insufficient functional coverage of existing OAM
protocols also noted in this document. The protocol definitions for
each of the Overlay OAM tools to be defined in separate documents.
"BGP for Communications among Controllers", Huaimo Chen, Susan Hares, Yi

Yang, Yanhe Fan, Mehmet Toy, Zhenqiang Li, Lei Liu, 2016-03-21,
<draft-chen-idr-com-cntlrs-00.txt>
This document describes extensions to the BGP routing protocol for
supporting communications among SDN controllers in a centralized
control system, which comprises multiple SDN controllers controlling
a network with a number of domains.
"PASSporT Extension for Caller Name", Jon Peterson, Chris Wendt,
2016-03-21, <draft-peterson-stir-cnam-00.txt>
This document extends the PASSporT object, which conveys
cryptographically-signed information about the people involved in
personal communications, to include a human-readable display name
comparable to the "Caller ID" function common on the telephone
network.
"SACM Information Model", Henk Birkholz, Nancy Cam-Winget, 2016-03-21,
<draft-cam-winget-sacm-information-model-00.txt>
This document defines the data types and data relations and
operations that comprise the information model for Security
Automation and Continuous Monitoring (SACM) of posture information.
This information model is maintained as the IANA "SACM Information
Elements" registry. This document defines the initial set and
contents to address SACM's use cases (RFC7632).
Please help this paragraph becoming an abstract.
"Concise Software Identifiers", Henk Birkholz, Jessica Fitzgerald-McKay,
Charles Schmidt, D. Waltermire, 2016-03-21,
<draft-birkholz-sacm-coswid-00.txt>
This document defines a concise representation of ISO 19770-2:2015
Software Identifiers (SWID tags) that is interoperable with the XML
schema definition of ISO 19770-2:2015.
"A JSON format for LGR files", Audric Schiltknecht, 2016-03-21,
<draft-schiltknecht-lager-json-00.txt>
This document defines a JSON format for LGRs (Label Generation
Rules). LGRs are used to represent rules for validating identifier
labels and their alternate representations. These LGRs are expressed
in XML as defined in [I-D.ietf-lager-specification].
"Encrypted Key Transport for Secure RTP", John Mattsson, David McGrew,
Dan Wing, Cullen Jennings, 2016-04-20,
<draft-jennings-perc-srtp-ekt-diet-01.txt>
IMPORTANT: This draft is just a cut down version of draft-ietfavtcore-srtp-ekt-03 to help discussion about the key parts of EKT for
the PERC WG. Any changes decided here would need to be synchronized
with the draft-ietf-avtcore-srtp-ekt draft. Nearly all the text here
came from draft-ietf-avtcore-srtp-ekt and the authors of that draft.
Encrypted Key Transport (EKT) is an extension to Secure Real-time
Transport Protocol (SRTP) that provides for the secure transport of
SRTP master keys, Rollover Counters, and other information within
SRTP. This facility enables SRTP to work for decentralized
conferences with minimal control by allowing a common key to be used

across multiple endpoints.

"Multi-domain Network Virtualization", Carlos Bernardos, Luis Contreras,
2016-03-21, <draft-bernardos-nfvrg-multidomain-00.txt>
This draft introduces the challenge of Multi-domain Network
Virtualization. The mutiple domains considered here correspond to
multiple administrative domains operating distinct infrastructures.
"Filter-Based RIB Data Model", Susan Hares, Russ White, 2016-04-04,
<draft-hares-rtgwg-fb-rib-01.txt,.pdf>
This document defines a yang data model for a Filter-based Routing
Information Base (RIB) Yang data model. A routing system uses the
Filter-based RIB to program FIB entries that process incoming packets
by matching on multiple fields (n-tuple) within the packet and then
performing a specified action on it. The FB-RIB can also specify an
action to forward the packet according to the FIB entries programmed
using the RIBs of its routing instance.
"Best Practices for Securing RTP Media Signaled with SIP", Jon Peterson,
Eric Rescorla, Richard Barnes, Russ Housley, 2016-03-21,
<draft-peterson-dispatch-rtpsec-00.txt>
Although the Session Initital Protocol (SIP) includes a suite of
security services that has been expanded by numerous specifications
over the years, there is no single place that explains how to use SIP
to establish confidential media sessions. Additionally, existing
mechanisms have some feature gaps that need to be identified and
resolved in order for them to address the pervasive monitoring threat
model. This specification describes practices for negotiating
confidential media with SIP, including both comprehensive security
solutions which bind the media to SIP-layer identities as well as
opportunistic security solutions.
"CBOR Merge Patch", Carsten Bormann, Peter Van der Stok, 2016-03-21,
<draft-bormann-appsawg-cbor-merge-patch-00.txt>
This specification defines the CBOR merge patch format and processing
rules, as an analog to the JSON merge patch format defined in RFC
7396. The merge patch format is primarily intended for use with the
HTTP PATCH method and potential related CoAP methods as a means of
describing a set of modifications to a target resource's content.
This specification also defines how a JSON merge patch document is
applied to a CBOR data item and vice versa.
"RPKI Multiple "All Resources" Trust Anchors Applicability Statement",
Andrew Newton, Carlos Martinez, Daniel Shaw, Tim Bruijnzeels, Byron
Ellacott, 2016-03-21, <draft-rir-rpki-allres-ta-app-statement-00.txt>
This document provides an applicability statement for the use of
multiple, overclaiming 'all resources' (0/0) RPKI root certificates
operated by the Regional Internet Registry community to help mitigate
the risk of massive downstream invalidation in the case of transient
registry inconsistencies.
"Knowledge Exchange in Autonomic Networks", Laurent Ciavaglia, Peloso
Pierre, 2016-03-21, <draft-ciavaglia-anima-knowledge-00.txt,.pdf>

This document describes a solution to manage the exchange and

processing of information and knowledge between autonomic functions.
The objective is to provide a unified interface to enable an
interoperable management of information flows among autonomic
functions by insuring the use common mechanisms. The protocol
negotiate and automatically adapt to the communication and
information capabilities, requirements and constraints of the
participating entities.
"Patch and Fetch Methods for Constrained Application Protocol (CoAP)",
Peter Van der Stok, Carsten Bormann, Anuj Sehgal, 2016-03-21,
<draft-vanderstok-core-etch-00.txt>
The existing Constrained Application Protocol (CoAP) methods only
allow access to a complete resource. This does not permit
applications to access parts of a resource. In case of resources
with larger or complex data, or in situations where a resource
continuity is required, replacing or requesting the whole resource is
undesirable. Several applications using CoAP will need to perform
partial resource accesses.
Similar to HTTP, the existing Constrained Application Protocol (CoAP)
GET method only allows the specification of a URI and request
parameters in CoAP options, not the transfer of a request payload
detailing the request. This leads to some applications to using POST
where actually a cacheable, idempotent, safe request is desired.
Again similar to HTTP, the existing Constrained Application Protocol
(CoAP) PUT method only allows to replace a complete resource. This
also leads applications to use POST where actually a cacheable,
possibly idempotent request is desired.
This specification adds new CoAP methods, FETCH, to perform the
equivalent of a GET with a request body; and the twin methods PATCH
and iPATCH, to modify parts of an existing CoAP resource.
"Generic Policy Data Model for Simplified Use of Policy Abstractions
(SUPA)", Joel Halpern, John Strassner, 2016-04-15,
<draft-halpern-supa-generic-policy-data-model-01.txt>
This document defines two YANG policy data models. The first is a
generic policy model that is meant to be extended on an applicationspecific basis. The second is an exemplary extension of the first
generic policy model, and defines rules as event-condition-action
policies. Both models are independent of the level of abstraction of
the content and meaning of a policy.
"DetNet Data Plane Protocol and Solution Alternatives", Jouni Korhonen,
Janos Farkas, Greg Mirsky, Pascal Thubert, Zhuangyan, Lou Berger,
2016-03-21, <draft-dt-detnet-dp-alt-00.txt>
This document identifies existing IP and MPLS, and other
encapsulations that run over IP and/or MPLS data plane technologies
that can be considered as the base line solution for deterministic
networking data plane definition.
"Deploying Identifier-Locator Addressing (ILA) in datacenter", Petr
Lapukhov, 2016-03-21, <draft-lapukhov-ila-deployment-00.txt>
Identifier-Locator Addressing defined in [I-D.herbert-nvo3-ila]

proposes using locator-identifier split in IPv6 address to realize

workload mobility and network virtualization. This document
describes how ILA can be implemented in datacenter using BGP as the
control-plane protocol. In general, ILA could be built upon
different control planes, and BGP is one particular instantiation.
BGP is a well-known protocol, sufficient for small to medium size
deployments, on scale of few millions of mappings. Defining more
generic and scalable control plane is outside of scope of this
document.
"Glass to Glass Internet Ecosysten Introduction", Glenn Deen, Leslie
Daigle, 2016-03-21, <draft-deen-daigle-ggie-00.txt>
This document introduces the Glass to Glass Internet Ecosystem
(GGIE). The GGIE goal is to improve how the Internet is used for all
video, both amateur and professional, reflecting that the line
between amature and professional video technology is increasinly
blurred. As the Glass to Glass (camera lens to viewing screen) name
implies GGIE's scope is from the original recording by a lens,
through the steps of editing, packaging, distributed and searching,
and finally viewing. GGIE is not a complete end to end architecture
or solution, it is use cases and technical specifications that can
serve as foundational building blocks for new Internet video
innovation.
This is a companion effort to the GGIE W3C Taskforce in the W3C Web
and TV Interest Group.
This document is being discussed on the ggie@ietg.org mailing list.
"Use-cases for Traffic Tagging", Deng Lingli, Dapeng Liu, 2016-03-21,
<draft-deng-tls-tagging-00.txt>
This document discusses the motivation and use-cases for coding
third-party aware tags for content/source related information into
resource retrieval process for encrypted web traffic.
"Problem Statement and Use-cases for Collaborative Measurements", Deng
Lingli, Rachel Huang, Shihui Duan, 2016-03-21,
<draft-deng-lmap-ps-collaboration-00.txt>
This document presents the problem statement and use-cases for cross
domain collaborative measurement practices, where multiple autonomous
measurement systems collaborate together in performing various
connectivity or performance measurements to help with QoE enhancement
by ICPs, network performance monitory to guide ISP/Regulator
coordination between autonomous network domains and/or regulatory
policies and cross-boundary troubleshooting for complaints from end
consumers.
"Providing AAAA records for free with QTYPE=A", marek@vavrusa.com,
lafur Gumundsson, 2016-03-21,
<draft-vavrusa-dnsop-aaaa-for-free-00.txt>
This document enables DNS servers to include AAAA addresses in the
answer section for DNS queries with QTYPE=A in order to reduce the
number of resolver round-trips during address lookups, and also
provides guidance for recursive DNS servers in accepting such
records.

"Source/Destination Routing Using BGP-4", Mingwei Xu, Shu Yang, Jianping

Wu, 2016-03-21, <draft-xu-src-dst-bgp-00.txt>
This document describes the changes necessary for BGP-4 to route
traffic from a specified prefix to a specified prefix.
"GPE-VPN: Programmable LISP-based Virtual Private Networks", Fabio
Maino, Vina Ermagan, John Evans, Horia Miclea, 2016-03-21,
<draft-maino-gpe-vpn-00.txt>
GPE-VPN is an architecture for programmable SD-WAN solutions that
leverages the Generic Protocol Encapsulation (GPE) overlay.
GPE-VPN uses an extended LISP-based map-assisted control plane to
dynamically lookup forwarding policies on demand. A northbound
programmable mapping system is used to store and retrieve mappings
and forwarding policies.
The GPE-VPN data plane is secured with IPsec based encryption.
Overlay tunnels, as well as cryptographic parameters, are provisioned
on demand.
"Secure IoT Bootstrapping: A Survey", Behcet Sarikaya, 2016-03-21,
<draft-sarikaya-t2trg-sbootstrapping-00.txt>
This document presents a survey of secure bootstrapping mechanisms
available for smart objects that are part of an Internet of Things
(IoT) network. It aims to provide a structured classification of the
available mechanisms. The document does not prescribe any one secure
bootstrapping mechanism and rather presents IoT developers with
different options to choose from, depending on their use-case,
security requirements and the user interface available on their smart
objects.
"Constrained ABNF", Sean Leonard, Paul Kyzivat, 2016-03-21,
<draft-seantek-constrained-abnf-00.txt>
This document extends the base definition of ABNF (Augmented BackusNaur Form) to express a rule that is constrained by another rule. If
a rule B is constrained by rule A, then every production generated by
rule B must also be generated by rule A. By creating subordinate
production forms, ABNF-using specifications can formally denote the
relationship between a general rule and specific subsets of that
rule, while preserving ABNF's context-free nature.
"PCEP Procedures for Hierarchical Label Switched Paths", Cyril Margaria,
Colby Barth, Sudhir Cheruathur, Ben Tsai, 2016-03-21,
<draft-margaria-pce-pcep-hlsp-extension-00.txt>
Label Switched Paths (LSPs) set up in Multiprotocol Label Switching
(MPLS) or Generalized MPLS (GMPLS) networks can be used to form links
to carry traffic in those networks or in other (client) networks.
These LSPs can be referred to as Hierarchical LSPs (H-LSP). H-LSPs
allow to improve the scalability of MPLS/GMPLS networks by creating
hierarchies of TE-LSPs. Those hierarchies are an important state for
optimal TE-Computation, therefore a stateful PCE should be able to
discover and manage those H-LSPs. A PCE having a global view of the
network, including Forwarding Adjacencies LSP (FA-LSP) and non FALSPs, can create more optimal hierachies and (re-)compute the TE-LSPs

path to make use of the H-LSPs. In particular a PCE can better

leverage the Private H-LSP introduced by RFC6107 without influencing
the IGP, allowing a less disruptive use of Hierarchies.
RFC6107 defined Protocol mechanisms to facilitate the establishment
of such LSPs and to bundle traffic engineering (TE) links to reduce
the load on routing protocols.
This document defines PCEP extensions to learn about and control
those H-LSPs.
"Multicast Considerations over IEEE 802 Wireless Media", Charles
Perkins, Dorothy Stanley, Warren Kumari, JC Zuniga, 2016-03-21,
<draft-perkins-intarea-multicast-ieee802-00.txt>
This document describes some performance issues that have been
observed when multicast packet transmission is attempted over IEEE
802 wireless media. Multicast features specified for IEEE 802
wireless media related to multicast are also described, along with
explanations about how these features can help ameliorate the
observed performance issues. IETF protocols that are likely to be
affected by the observed performance issues are identified, and
workarounds are proposed in some cases. The performance of multicast
over wireless media often can be quite different than the performance
of unicast. This draft describes the nature of the differences and
the effects on representative IETF protocols. We also describe some
efforts that have been made by IEEE 802 Wireless groups to ameliorate
the performance differences.
"SDCP: Streaming Distributed Control Protocol", Cristian Perez-Monte,
2016-03-21, <draft-appsawg-perez-sdcp-00.txt>
This memorandum describes SDCP, a protocol to control multimedia
streaming in cases where streaming generation should be distributed
to improve performance. This is especially useful for Human-Things
streams. Usually, real time applications such as virtual reality
generate a user-controlled multimedia streaming. This is a time
continuous data flux that could be divided spatially to distribute
processing, memory or network resources. This protocol does not
describe streaming communication, but the control of each single
streaming generation in a best-effort by many nodes or things.
"Compact DNSSEC Denial of Existence or Black Lies", Filippo Valsorda,
lafur Gumundsson, 2016-03-21, <draft-valsorda-dnsop-black-lies-00.txt>
This document describes a technique to generate valid DNSSEC answers
on demand for non-existing names by claiming the name exists and
returning a NSEC record for it. These answers require only one NSEC
record and allow live-signing servers to minimize signing operations,
packet size, disclosure of zone contents and required knowledge of
the zone layout.
"ILA Control Messages", Tom Herbert, 2016-03-21,
<draft-herbert-ila-messages-00.txt>
This specification defines control messages for Identifier Locator
Addressing. These control messages are sent between ILA hosts or from
ILA routers to ILA hosts to notify a sending host to change its entry
for an identifier in its ILA mapping table. Messages indicate that no
mapping was found for a destination identifier or indicate a redirect

to use a different locator for an identifier.

"Porting QUIC to Transport Layer Security (TLS)", Martin Thomson, Ryan
Hamilton, 2016-03-21, <draft-thomson-quic-tls-00.txt>
The QUIC experiment defines a custom security protocol. This was
necessary to gain handshake latency improvements. This document
describes how that security protocol might be replaced with TLS.
"An Architecture for Secure Content Delegation using HTTP", Martin
Thomson, Goran Eriksson, Christer Holmberg, 2016-03-21,
<draft-thomson-http-scd-00.txt>
An architecture is described for content distribution via third-party
content distribution networks with reduced privileges. This
architecture allows an origin server to delegate the responsibility
for delivery of the payload of an HTTP response to a third party.
That party is unable to modify this content. The content is
encrypted, which in some cases will prevent the third party from
learning about the content.
"ICE Network Cost: Dynamically selecting ICE candidate pairs based on
relative cost of network interfaces", Peter Thatcher, Honghai Zhang,
Taylor Brandstetter, 2016-03-21,
<draft-thatcher-ice-network-cost-00.txt>
This document describes an extension to the Interactive Connectivity
Establishment (ICE) that enables ICE agents to exchange information
about the relative cost of network interfaces and dynamically choose
the selected ICE candidate pair based on the cost of both the local
and remote network interfaces. For example, if a cellular network
interface has a higher cost than a Wi-Fi network interface, the ICE
agents can use that information to prefer candidate pairs with Wi-Fi
rather than cellular when possible, and only use cellular when
necessary.
This document additionally describes a second piece of information,
network ID, that goes along with the network cost and can be used to
know when a network interface has changed, even if two network
interfaces have the same network cost.
"Caching Secure HTTP Content using Blind Caches", Martin Thomson, Goran
Eriksson, Christer Holmberg, 2016-03-21, <draft-thomson-http-bc-00.txt>
A mechanism is described whereby a server can use client-selected
shared cache.
"Regular Expressions for Internet Mail", Sean Leonard, 2016-03-21,
<draft-seantek-mail-regexen-00.txt>
Internet Mail identifiers are used ubiquitously throughout computing
systems as building blocks of online identity. Unfortunately,
incomplete understandings of the syntaxes of these identifiers has
led to interoperability problems and poor user experiences. Many
users use specific characters in their addresses that are not
properly accepted on various systems. This document prescribes
normative regular expression (regex) patterns for all Internetconnected systems to use when validating or parsing Internet Mail
identifiers, with special attention to regular expressions that work
with popular languages and platforms.

"Failure Detection Extensions for Publish-Subscribe in CoAP", Luyuan

Fang, 2016-03-21, <draft-fang-core-coap-pubsub-failure-detection-00.txt>
This document defines extensions to the Constrained Application
Protocol Publish/Subscribe function set, to make the protocol
suitable to address the use case of failure detection in a hyperscale system with millions of endpoints. Specifically, this document
defines a Last Will mechanism and a scheme to guarantee hot fail-over
of the pub/sub broker.
"ICE Renomination: Dynamically selecting ICE candidate pairs", Peter
Thatcher, Honghai Zhang, Taylor Brandstetter, 2016-03-21,
<draft-thatcher-ice-renomination-00.txt>
This document describes an extension to the Interactive Connectivity
Establishment (ICE) that enables ICE agents to dynamically change the
selected candidate pair of the controlled side by allowing the
controlling side to nominate different candidate pairs over time as
network conditions change.
"No MTI Crypto without Public Review", Rich Salz, 2016-03-22,
<draft-rsalz-drbg-speck-wap-wep-00.txt>
Cryptography is becoming more important to the IETF and its
protocols, and more IETF protocols are using, or looking at,
cryptography to increase privacy on the Internet [RFC7258].
This document specifies a proposed best practice for any protocol (or
data format) that uses cryptography. Namely, that such RFCs cannot
specify an algorithm as mandatory-to-implement (MTI) unless that
algorithm has had reasonable public review. This document also
"sketches out" a rough definition around what such a review would
look like.
"Homenet Naming and Service Discovery Architecture", Ted Lemon,
2016-03-23, <draft-lemon-homenet-naming-architecture-00.txt>
This document recommends a naming and service discovery resolution
architecture for homenets. This architecture covers the publication
and resolution of names of hosts on the homenet both within the
homenet and on the public internet, and the use of such names for
offering and discovering services that exist on the homenet both
within the homenet and on the public internet. Security and privacy
implications and techniques for automatically and administratively
setting security and privacy policies for such names are also
described.
"DMM Deployment Models and Architectural Considerations", Sri
Gundavelli, 2016-04-03, <draft-wt-dmm-deployment-models-00.txt>
This document identifies the deployment models for Distributed
Mobility Management architecture.
"HTTP bytes-live Range Unit for Live Content", Craig Pratt, Barbara
Stark, Darshak Thakore, 2016-04-18,
<draft-pratt-httpbis-bytes-live-range-unit-01.txt>
To accommodate byte range requests for content that has data appended
over time, this document defines a new HTTP range unit named "bytes-

live". The "bytes-live" range unit provides the ability for a client
to specify a byte range in a GET or HEAD request which starts at an
arbitrary byte offset within the representation and ends at an
indeterminate offset, represented by "*".
"A Uniform Resource Name (URN) Namespace for SCTE", Darshak Thakore,
Niem Dang, Gary Hughes, 2016-04-03, <draft-dthakore-scte-urn-00.txt>
This document describers the Namespace Identifier (NID) 'scte' for
Uniform Resource Names (URNs) used to identify resources published by
the Society of Cable Telecommunications Engineers (SCTE). SCTE
specifies and manages resources that utilize this URN identification
model. Management activities for these and other resource types are
handled by the SCTE.
"Microwave Radio Link YANG Data Models", Jonas Ahlberg, Jan-Olof
Carlson, Hans-Ake Lund, Thomas Olausson, 2016-04-04,
<draft-ahlberg-ccamp-microwave-radio-link-00.txt>
YANG model for managing microwave radio link functionality.
"YANG Model for QoS", Aseem Choudhary, Mahesh Jethanandani, 2016-04-04,
<draft-asechoud-netmod-qos-model-00.txt>
This document describes a YANG model for Quality of Service (QoS)
configuration and operational parameters.
"OPEN-O (Orchestrator)", DENG Hui, Uri Elzur, 2016-04-04,
<draft-deng-opsawg-nfvrg-sdnrg-openo-00.txt>
OPEN-O(Orchestrator) Project was presented for the first time during
Open Network Summit 2016 in Santa Clara. The purpose of OPEN-O would
intent to propose an open source project under Linux foundation. It
includes cross domain orchestrator, SDN-O and NFV-O. SDN-O is
sitting on top of SDN Controller like ODL or ONOS and somewhere
below the SDN APP. NFVO is aligned with ETSI NFV ISG. This document
is seeking for the relationship between open standard IETF and open
source project OPEN-O.
"Piggybacked DTLS Handshakes in SDP", Eric Rescorla, 2016-04-04,
<draft-rescorla-dtls-in-sdp-00.txt>
This document describes a mechanism for embedding DTLS handshake
messages in SDP descriptions. This technique allows implementations
to shave a full round-trip off of DTLS-SRTP session establishment,
while retaining compatibility with ordinary DTLS-SRTP endpoints.
"Constrained Application Protocol (CoAP) over IEEE 802.15.4 Information
Element for IETF", Carsten Bormann, 2016-04-04,
<draft-bormann-6lo-coap-802-15-ie-00.txt>
IEEE Std. 802.15.4-2015 defines Information Elements (IE), and draftkivinen-802-15-ie defines a framework for using these IEs in IETF
protocols.
The present specification defines a way to transport CoAP messages in
IEs. This can be used to perform CoAP exchanges with neighboring
IEEE 802.15.4 nodes before there is IP connectivity, e.g., to
configure that IP connectivity.

draft-wang-6tisch-6top-coapie demonstrates example applications of

this for 6TiSCH. Other areas of application are conceivable even in
classic 6LoWPAN networks.
"Generic Autonomic Signaling Protocol Application Program Interface
(GRASP API)", Brian Carpenter, Bing Liu, Wendong Wang, Xiangyang Gong,
2016-04-04, <draft-liu-anima-grasp-api-00.txt>
This document specifies the application program interface of the
Generic Autonomic Signaling Protocol (GRASP). The API is used for
Autonomic Service Agent (ASA) calling the GRASP protocol module to
communicate the autonomic network signalings with other ASAs.
"CIRA IDN EPP Extension", Jacques Latour, Tongfeng Zhang,
julien.bernard@viagenie.ca, 2016-04-04, <draft-cira-regext-idn-01.txt>
The Canadian Internet Registration Authority (CIRA), administering
the .CA country-code top-level domain, offers internationalized
domain names (IDN) in French, one of Canada's official languages.
CIRA's Extensible Provisioning Protocol (EPP) services have been
augmented with an IDN EPP extension in order to support registrars
desiring to register internationalized domains using French
characters as bundled domains.
This document defines the extension to the Extensible Provisioning
Protocol used at CIRA to support IDN operations.
"Service Function Chaining Dataplane Elements in Mobile Networks", Pedro
Aranda, Marco Gramaglia, Diego Lopez, Walter Haeffner, 2016-04-04,
<draft-aranda-sfc-dp-mobile-00.txt>
The evolution of the network towards 5G implies a challenge for the
infrastructure. The targeted services and the full deployment of
virtualization in all segments of the network will need service
function chains that previously resided in the(local and remote)
infrastructure of the Network operators to extend to the radio access
network (RAN).
The objective of this draft is to provide a non-exhaustive but
representative list of service functions in 4G and 5G networks. We
base on the problem statement [RFC7498] and architecture framework
[RFC7665] of the SFC working group, as well on the existing mobile
networks use cases [I-D.ietf-sfc-use-case-mobility] and the
requirement gathering process of the ITU-R IMT 2020 [1] and different
initiatives in Europe [2], Korea [3] and China [4] to anticipate
network elements that will be needed in 5G networks.
"File-Like ICN Collection (FLIC)", Christian Tschudin, Christopher Wood,
2016-04-04, <draft-tschudin-icnrg-flic-00.txt,.pdf>
This document describes a bare bones "index table"-approach for
organizing a set of ICN data objects into a large, File-Like ICN
Collection (FLIC).
At the core of this collection is a so called manifest which acts as
the collection's root node. The manifest contains an index table
with pointers, each pointer being a hash value pointing to either a
final data block or another index table node.
"Using RSA Algorithms with COSE Messages", Michael Jones, 2016-04-04,

<draft-jones-cose-rsa-00.txt>
The CBOR Object Signing and Encryption (COSE) specification defines
cryptographic message encodings using Concise Binary Object
Representation (CBOR). This specification defines algorithm
encodings and representations enabling RSA algorithms to be used for
COSE messages.
"YANG Data Model for PW Protocol", Ran Chen, fangwei hu, 2016-04-04,
<draft-chen-pals-pw-yang-00.txt>
This document defines a YANG data model for PW configuration and
operation.
"Identity Event Subscription Protocol", Phil Hunt, Morteza Ansari,
2016-04-04, <draft-hunt-idevent-distribution-00.txt>
This specification defines a registry to define methods to distribute
identity events to subscribers. It includes a definition for
publishers to use HTTP POST to push events to clients via web
callback, and a method for subscribers to use HTTP GET to retrieve
events in a feed queue.
"Asynchronous Services Bus Protocol", Scott Morgan, Adligo Inc,
2016-04-07, <draft-adligo-hybi-asbp-01.txt>
ASBP (Asynchronous Services Bus Protocol) is a simple command based
application-level protocol for routing data and messages. ASBP
is intended to allow implementation of fully Asynchronous
Service Bus Architectures, in a simple standardized
manor. ASBP is intended to be layered over
WebSocket or HTTP. The protocol consists of a simple UTF-8
key value(s) header and any arbitrary data (text, binary, XML, JSON,
etc.), which the application's specific Command-Attendant or
Command-Respondent processes. In addition this document touches on
an extension to ASBP, CP (Conversation Protocol) a protocol used
to facilitate communication between Asynchronous Service Busses
implemented or hosted by different organizations. CP will be
covered in more detail in another RFC still in progress.
Internet-Draft
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current
Internet-Drafts is at http://datatracker.ietf.org/drafts/current.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use InternetDrafts as reference material or to cite them other than as
"work in progress.
"Priority based Flow Rule Request Message Processing Mechanism in the
OpenFlow Switch", Xinjian Long, Wendong Wang, Xiangyang Gong, Xirong
Que, Qinglei Qi, 2016-04-05, <draft-long-sdnrg-pfrrmpm-openflow-00.txt>

In the SDN, the controller is in charge of the maintenance and

administration of variable aspects like the network topology and the
network resources etc. of the whole network. Administrative
strategies are made upon these work and sent to the switches from the
controller so as to instruct the network devices to apply appropriate
policies to the data flows. As for the data packet which reaches the
ingress OpenFlow switch for the first time, the packet itself or a
fraction of the packet will be encapsulated into a packet-in message
and will be sent to the controller to request for a new flow rule.
After the flow-mod message and the packet-out message are sent back
to the switch from the controller, the determined forwarding action
will be applied to the certain data flow.
So far, the inbound latency caused by the creation of the packet-in
message and the outbound latency caused by the receive and the
execution of the flow-mod message are highlighted when it comes to
the concerns about the latency and the effectiveness of the data
transportation in the SDN[Mazu]. Attention to the studies on the
processing order of the flow rule request message like the packet-in
message and the packet-out message is comparatively low. As the SDN
continually grows in scale and complexity and the packets' forwarding
policies become more recursive and dynamic, the number of the
switches under the administration of the same controller is elevated
and unavoidably causes the network congestion problem widespread.
The scale of modern networks and data-centers and the associated
operational expense deteriorates the delay problem in the network
with congestion. The ability to help the services with high priority
be processed without delay becomes critical.
This document proposes the combination of appending a priority tag to
the packet-in message and the Priority based Flow Rule Request
Message Processing Mechanism(PFRRMPM) as a solution to help the data
flow with high priority or lantency-sensitive to acquire the
forwarding rule without or with shorter waiting latency when there
are excess flow rule request messages in the SDN.
"Experiences implementing the Babel routing protocol", Toke
Hoeiland-Joergensen, 2016-04-05,
<draft-hoeiland-joergensen-babel-implementation-00.txt>
This document describes the experiences creating independent
implementations of the Babel routing protocol [RFC6126], based on the
two independent implementations currently available.
The Babel routing protocol is easy to implement, and it is quite
feasible for someone with no prior experience with routing protocols
to create a working implementation. The few issues that needed
clarification during the independent implementation work are
documented, with the hope of aiding others seeking to implement
Babel.
"Open Source Software Manifest Retrieval from a Headless Device",
Zachary Beese, Gregory Barton, 2016-04-05,
<draft-beese-opsawg-ossman-00.txt>
In commercial embedded systems utilizing open source, there are legal
requirements to make open source software utilized in a product
known. Headless devices have no UI to display an open source
manifest. Additionally, printed manuals become out of date as
software updates occur throughout the product lifetime. This

standard intends to create a common method of retrieving open source

manifests directly from an embedded device utilizing Ethernet or WiFi.
"Certificate credentials for ACE framework", Samuel Erdtman, 2016-04-05,
<draft-erdtman-ace-certificate-credential-00.txt>
This draft provides an example of how to extend the ACE framework
[I-D.ietf-ace-oauth-authz], to use client and server certificates
(x509), for mutual authentication. Certificate are used to establish
the security context between the client and resource server. This
draft is limited to transport layer security based on DTLS and it
does not consider the mixed case where e.g. only the server is
authenticated with a certificate.
"Special Use TLD Problem Statement", Ted Lemon, Ralph Droms, 2016-04-05,
<draft-tldr-sutld-ps-00.txt>
The Special-Use Domain Names registration policy in RFC 6761 has been
shown through experience to present unanticipated challenges. This
memo explores current IETF and non-IETF publications relating on
special-use TLDs, describes the history of domain names, and
enumerates some problems that have come up in connection with the
Special-Use Domain Names allocation process specifically as it
related to top-level domains.
"SUPA policy-based management framework", Shucheng LIU, John Strassner,
Georgios Karagiannis, Maxim Klyus, Jun Bi, 2016-04-05,
<draft-liu-supa-policy-based-management-framework-00.txt>
Simplified Use of Policy Abstractions (SUPA) defines a set of rules
that define how services are designed, delivered, and operated
within an operator's environment independent of any one particular
service or networking device. This document describes the SUPA basic
architecture, its elements and interfaces.
"Architecture/Framework for SUPA", Tianran Zhou, Bert Wijnen,
2016-04-06, <draft-bw-supa-architecture-00.txt>
This document describes the architecture and framework for the Simple
Use of Policy Abtractions (SUPA). It also gives an overview of the
SUPA components.
"A new Designated Forwarder Election for the EVPN", satyamoh@cisco.com,
Keyur Patel, Ali Sajassi, John Drake, A. Przygienda, 2016-04-06,
<draft-bess-evpn-df-election-00.txt>
This document describes an improved EVPN Designated Forwarder
Election (DF) algorithm which can be used to enhance operational
experience in terms of convergence speed and robustness over a WAN
deploying EVPN
"Using DNAME in the DNS root zone for sinking of special-use TLDs",
Stephane Bortzmeyer, 2016-04-29, <draft-bortzmeyer-dname-root-02.txt>
This documents asks IANA to add DNAME
for TLDs which are in the Special-Use
to ensure they receive an appropriate
root nameservers are not too bothered

records in the DNS root zone

Domain Names registry, in order
reply (NXDOMAIN) and that the
by them.

REMOVE BEFORE PUBLICATION: there is no obvious place to discuss this

document. May be the IETF DNSOP (DNS Operations) group, through its
mailing list (the author reads it). Or may AS112 operators mailing
lists? The source of the document, as well as a list of open issues,
is currently kept at Github [1].
"DTN Security Key Management - Requirements and Design", Fred Templin,
Scott Burleigh, 2016-04-06, <draft-templin-dtn-dtnskmreq-00.txt>
Delay/Disruption Tolerant Networking (DTN) introduces a network model
in which communications may be subject to long delays and/or
intermittent connectivity. These challenges render traditional
security key management mechanisms infeasible since round trip delays
may exceed the duration of communication opportunities. This
document therefore proposes requirements and outlines a design for
security key management in DTNs.
"Extensions to the Path Computation Element Protocol(PCEP) Management
Information Base(MIB) Module", Vaidyanathan Ramany, Dheeraj Parchuru,
Dilip Kumar, 2016-04-07, <draft-pce-mib-extensions-00.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 extensions to the managed objects for
modeling of the Path Computation Element Communication Protocol
(PCEP) for communications between a Path Computation Client (PCC) and
a Path Computation Element (PCE), or between two PCEs, that support
stateful capabilities.
"LISP L2/L3 EID Mobility Using a Unified Control Plane", Marc
Portoles-Comeras, Vrushali Ashtaputre, Victor Moreno, Fabio Maino, Dino
Farinacci, 2016-04-07, <draft-portoles-lisp-eid-mobility-00.txt>
The LISP control plane offers the flexibility to support multiple
overlay flavors simultaneously. This document specifies how LISP can
be used to provide control-plane support to deploy a unified L2 and
L3 overlay solution, as well as analyzing possible deployment options
and models.
"Problem Statement for Simplified Use of Policy Abstractions (SUPA)",
Jun Bi, Georgios Karagiannis, John Strassner, Maxim Klyus, Qiong, Luis
Contreras, 2016-04-07, <draft-bi-supa-problem-statement-00.txt>
Simplified Use of Policy Abstractions (SUPA) defines a set of rules
that define how services are designed, delivered, and operated
within an operator's environment independent of any one particular
service or networking device. SUPA expresses policy rules using a
generic policy information model, which serves as a unifying
influence to enable different data model implementations to be
simultaneously developed.
"Draft LDAP Single Sign On Token Processing", William Brown, Simo Sorce,
Kieran Andrews, 2016-04-07, <draft-wibrown-ldapssotoken-00.txt>
LDAP Single Sign On Token is a SASL (Simple Authentication and
Security Layer RFC 2222 [RFC2222]) mechanism to allow single sign-on
to an LDAP Directory Server environment. Tokens generated by the
LDAP server can be transmitted through other protocols and channels,
allowing a broad range of clients and middleware to take advantage of
single sign-on in environments where Kerberos v5 or other Single Sign

On mechanisms may not be avaliable.

"Using Edwards-curve Digital Signature Algorithm (EdDSA) in the Internet
Key Exchange (IKEv2)", Yoav Nir, 2016-04-07,
<draft-nir-ipsecme-eddsa-00.txt>
This document describes the use of the Edwards-curve digital
signature algorithm in the IKEv2 protocol.
"OCSP over DNS (ODIN)", Max, 2016-04-08, <draft-pala-odin-00.txt>
With the increase number of protocols and applications that rely on
digital certificates to authenticate either the communication channel
(TLS) or the data itself (PKIX), the need for providing an efficient
revocation system is paramount. Although the Online Certificate
Status Protocol (OCSP) allows for efficient lookup of the revocation
status of a certificate, the distribution of this information via
HTTP or HTTPS is not particularly efficient for high volume websites
without incurring in high distribution costs (e.g., CDN).
This draft describes how to provide pre-signed OCSP responses via the
DNS system in order to leverage its distributed nature and, therefore
lowering operational costs for Certification Authorities.
"SACM Information Model", Henk Birkholz, Nancy Cam-Winget, 2016-04-08,
<draft-camwinget-sacm-information-model-00.txt>
***replaces abstract in WG IM*** This document defines the
information model for Security Automation and Continuous Monitoring
(SACM). This includes the definition of information elements
transported between SACM components (data in motion) and how to
express their relationships. This information model is maintained as
the IANA "SACM Information Elements" registry. The information model
captures the information needs described in the use cases defined by
SACM.
"Process Experiment: Expanded Qualification of Nominating Committee
Selecting Members", Murray Kucherawy, 2016-04-08,
<draft-kucherawy-nomcom-procexp-00.txt>
The criteria by which one qualifies to be a selecting member of the
IETF Nominating Committee are somewhat limited, having been developed
long before the current IETF meeting model that allows for greater
remote participation both during and between organized meetings.
This document describes a process experiment whereby those criteria
are extended to meet the IETF's current participation model. If
successful, the results of this experiment can be folded into our
permanent NomCom procedures.
"RPC-over-RDMA Version Two", Chuck Lever, David Noveck, 2016-04-08,
<draft-cel-nfsv4-rpcrdma-version-two-00.txt,.ps,.pdf>
This document specifies an improved protocol for conveying Remote
Procedure Call (RPC) messages on physical transports capable of
Remote Direct Memory Access (RDMA), based on RPC-over-RDMA Version
One.
"RPC-over-RDMA Extension to Manage Transport Characteristics", David
Noveck, 2016-04-11, <draft-dnoveck-nfsv4-rpcrdma-xcharext-00.txt>

It is expected that the RPC-over-RDMA transport will, at some point,

allow protocol extensions to be defined. This would provide for the
specification of OPTIONAL features, allowing participants who
implement the OPTIONAL features, to cooperate as specified by that
extension, while still interoperating with participants who do not
support that extension.
A particular extension is described herein, whose purpose is to allow
RPC/RDMA Endpoints to specify and manage their transport
characteristics in order to allow the other participant to optimize
message transfer in light of the characteristics communicated by the
initial sender.
"Transporing access tokens in session resumption tickets
draft-seitz-ace-ticket-token-transfer-00 (TTT) Abstract", Ludwig Seitz,
2016-04-12, <draft-seitz-ace-ticket-token-transfer-00.txt>
This memo presents a method of transferring an access token from a
client to a resource server in a (D)TLS handshake, based on Session
Resumption without Server-Side State (RFC 5077).
"Requirements for Resource Public Key Infrastructure (RPKI) Relying
Parties", Di Ma, Stephen Kent, 2016-04-12, <draft-madi-sidr-rp-00.txt>
This document provides a single reference point for requirements for
Relying Party (RP) software for use in the Resource Public Key
Infrastructure (RPKI). It cites requirements that appear in several
RPKI RFCs, making it easier for implementers to become aware of these
requirements.
"LISP Distinguished Name Encoding", Dino Farinacci, 2016-04-13,
<draft-farinacci-lisp-name-encoding-00.txt>
This draft defines how to use the AFI=17 Distinguished Names in LISP.
"Improving Awareness of Running Code: The Implementation Status
Section", Yaron Sheffer, Adrian Farrel, 2016-04-14,
<draft-sheffer-rfc6982bis-00.txt>
This document describes a simple process that allows authors of
Internet-Drafts to record the status of known implementations by
including an Implementation Status section. This will allow
reviewers and working groups to assign due consideration to documents
that have the benefit of running code, which may serve as evidence of
valuable experimentation and feedback that have made the implemented
protocols more mature.
This process is not mandatory. Authors of Internet-Drafts are
encouraged to consider using the process for their documents, and
working groups are invited to think about applying the process to all
of their protocol specifications. This document obsoletes RFC 6982,
advancing it to a Best Current Practice.
"LISP Geo-Coordinate Use-Cases", Dino Farinacci, 2016-04-14,
<draft-farinacci-lisp-geo-00.txt>
This draft describes how Geo-Coordinates can be used in the LISP
Architecture and Protocols.
"Access Privilege Provisioning for Constrained Devices",

vasu.kantubukta@huawei.com, Rahul Jadhav, yangneng, 2016-04-15,

<draft-vasu-ace-core-access-privilege-provisioning-00.txt>
As more constrained devices are integrating with current Internet,
the ubiquitous computing in scenarios like smart home is very
important. In smart home, the constrained devices (ex. thermostat)
need to be provisioned in such a way that it can inter-operate with
any kind of devices like other constrained devices (ex. Air
conditioner) or client devices (ex. smart phone). This document
provides a method to support access privilege provisioning based on
pre-configured admission and resource control policies, where this
method explains device's service access in two different use cases:
first provisioning the service when a constrained device accessing
the service provided by other constrained device, second, accessing
the service provided by constrained device from the client device
(non constrained device).
"Issues Related to RPC-over-RDMA Internode Round-trips", David Noveck,
2016-04-17, <draft-dnoveck-nfsv4-rpcrdma-rtissues-00.txt>
As currently designed and implemented, the RPC-over-RDMA protocol
requires use of multiple internode round trips to process many common
operations. For example, NFS READ or WRITE operations require use of
three internode round trips. This document looks at this issue and
discusses what can and what should be done to address it, both within
the context of an extensible version of RPC-over-RDMA and possibly
outside that framework.
"Validate Extension for the Extensible Provisioning Protocol (EPP)",
rcarney@godaddy.com, jsnitker@godaddy.com, 2016-04-18,
<draft-carney-regext-validate-00.txt,.pdf>
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the validation of contact and eligibility data.
"Use of EdDSA Signatures in the Cryptographic Message Syntax (CMS)",
Russ Housley, 2016-04-18, <draft-housley-cms-eddsa-signatures-00.txt>
This document describes the conventions for using Edwards-curve
Digital Signature Algorithm (EdDSA) in the Cryptographic Message
Syntax (CMS). The conventions for Ed25519, Ed25519ph, Ed448, and
Ed448ph are described.
"Multiple Ethernet - IPv6 mapped IPv6 address (ME6A)", Naoki Matsuhira,
2016-04-18, <draft-matsuhira-me6a-00.txt>
This document specifies Multiple Ethernet - IPv6 mapped IPv6
address(ME6A) spefification. ME6A is Ethernet mapped IPv6 address
with plane ID. Unique allocation of plane id value enable duplicated
MAC address unique in IPv6 address space. This address may use
Ethernet over IPv6 encapsulation.
"Received Signal Weakness (RSW) Metric", Charles Perkins, 2016-04-18,
<draft-perkins-manet-rsw-00.txt>
The Received Signal Weakness (RSW) metric is a simple cost metric
that enables selection of a route with the high end-to-end signal
strength.
"LP-WAN Compression Context", Ana Minaburo, Laurent Toutain, 2016-04-19,

<draft-toutain-lp-wan-compression-context-00.txt>
This documents describes a way to adapt the formal notation to the
IoT context, especially for LP-WAN communication where packet size is
drastically limited. It is also necessary to simplify several
notation and avoid a specific notation. Concept described in
[RFC4997] may be written in CBOR or YANG.
"Simpler Algorithms for Processing Alert-Info URNs", Dale Worley,
2016-04-19, <draft-worley-alert-info-fsm-00.txt>
The "alert" namespace of uniform resource names (URNs) can be used in
the Alert-Info header field of Session Initiation Protocol (SIP)
requests and responses to inform a VoIP telephone (user agent) of the
characteristics of the call that the user agent has originated or
terminated. Based on the URNs in the Alert-Info header field, the
user agent must select an the best available signal to present to its
user to indicate the characteristics of the call. This document
describes a method of constructing a finite state machine (FSM) to do
this selection. In many situations, the resulting FSM is simpler and
faster than previously described selection algorithms. The designer
must construct the FSM so that its behavior will satisfy the
requirements given in the definition of the "alert" URN namespace.
"Routing Optimization with SDN in Data Center Networks", Qian Kong, Tao
Gao, Dajiang Wang, Zhenyu Wang, Jiayu Wang, Bingli Guo, Shanguo Huang,
2016-04-20, <draft-kong-sdnrg-routing-optimization-sdn-in-dc-00.txt>
With the open and standard programmatic interface and the flexibility
of controlling network, Software Defined Network (SDN) can obviously
simplify and integrate operation and business support systems. As a
consequence, to satisfy the rising switching demand in the data
center network, it is a good option to adopt SDN technology. In
addition, current architecture of data center network is far from
ideality, which results in the low utilization rate in bandwidth
resource. For example, mice flow cannot be well effectively served in
the conventional Wavelength Division Multiplexing (WDM) optical
network with at least 50GHz spectrum interval. From a data center
network perspective, it is necessary to further improve the resource
utilization efficiency and the flexibility of coping with different
traffic.
This document described an optical data center interconnect, which
comprises both the fixed and flexible grid transceivers. A traffic
monitor is implemented in the SDN-based data center network to
evaluate the coming traffic demands and allocate appropriate spectrum
for the request. For instance, mice flow can be served by fixed grid
transceivers, well the elephant flows can be transmitted by the
flexi-grid transceiver using multiple subcarriers to form a
superchannel. Thus, spectrum efficiency is optimized and bandwidth
utilization is improved dramatically.
"Path Table based Routing Mechanism in Software-Defined Optical
Transport Networks (SD-OTN)", Li Xin, Yu Zhou, Dajiang Wang, Zhenyu
Wang, Jiayu Wang, Wenzhe Li, Shan Yin, Shanguo Huang, 2016-04-20,
<draft-li-sdnrg-path-table-routing-in-sd-otn-00.txt>
The dynamic establishment and removal of an end-to-end light-path
consume a lot of time which are also the main burden of control plane
in optical transport networks. With the frequent arrival and

departure of services, the control plane needs to handle a large

number of control and management messages to conduct path
computation, resource reservation and cross connection configuration.
This draft proposes a novel routing mechanism based on Path Table for
software-defined optical transport networks (SD-OTN). The Path Table
reserves partial activated established light-paths that can be
directly used by subsequent requests for subsequent services. This
new routing mechanism can reduce the network load and save routing
time for some services.
"Security of Messages Exchanged Between Servers and Relay Agents",
Bernie Volz, Yogendra Pal, 2016-04-20,
<draft-volz-dhc-relay-server-security-00.txt>
The Dynamic Host Configuration Protocol for IPv4 (DHCPv4) has no
guidance for how to secure messages exchanged between servers and
relay agents. The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) states that IPsec should be used to secure messages
exchanged between servers and relay agents, but does not recommend
encryption. And, with recent concerns about pervasive monitoring it
is appropriate to provide recommendations for DHCPv4 and also improve
the recommendations for DHCPv6. This document updates RFC1542 and
RFC3315.
"Emergency Communication for Low Energy Body-Centric Wearable Networks",
Choong Hong, Ameen, Seung Moon, 2016-04-20,
<draft-hongcs-6lo-bcwc-00.txt>
Wearable devices are among the core technologies for Internet of Things
(IoT). Recent advances in wireless communication devices have made it
possible to create a wearable network in and around the human body. Such
a network can be used for diverse applications such as monitoring human
body activities and personal entertainments. A typical wearable device
runs on battery power, which is limited and often non-rechargeable.
Therefore, a low energy operation environment is desirable. Emergency
traffic management is an important aspect of such a network. This
document describes how an out-of-bound external wake up based on
on-demand mechanism can work to successfully transmit emergency traffic
in a typical body-centric wearable network (BC-WN).
"ACME Account Key Binding via CAA Records", Hugo Landau, 2016-04-21,
<draft-landau-acme-caa-00.txt>
The ACME protocol provides a means for hosts to automatically request
and obtain X.509 certificates from certificate authorities.
Certification authorities which implement ACME may also choose to
implement the CAA DNS record, which allows a domain to communicate
issuance policy to CAs. The CAA specification alone 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 such a
parameter.
"MSDP YANG model", Zheng Zhang, BenChong Xu, 2016-04-24,
<draft-zhang-pim-msdp-yang-00.txt>
This document defines a YANG data model for MSDP protocol
configuration and operation.
"SMTP MTA Strict Transport Security", Daniel Margolis, Mark Risher,

Nicolas Lidzborski, Wei Chuang, Brandon Long, Binu Ramakrishnan,

Alexander Brotman, Janet Jones, Franck Martin, Klaus Umbach, Markus
Laber, 2016-04-25, <draft-brotman-mta-sts-00.txt>
SMTP MTA-STS is a mechanism enabling mail service providers to
declare their ability to receive TLS-secured connections, to declare
particular methods for certificate validation, and to request that
sending SMTP servers report upon and/or refuse to deliver messages
that cannot be delivered securely.
"SMTP TLS Reporting", Daniel Margolis, Alexander Brotman, Binu
Ramakrishnan, Janet Jones, Mark Risher, 2016-04-25,
<draft-brotman-smtp-tlsrpt-00.txt>
A number of protocols exist for establishing encrypted channels
between SMTP Mail Transfer Agents, including STARTTLS [RFC3207], DANE
[RFC6698], and SMTP MTA STS (TODO: Add ref). These protocols can
fail due to misconfiguration or active attack, leading to undelivered
messages or delivery over unencrypted or unauthenticated channels.
This document describes a reporting mechanism and format by which
sending systems can share statistics and specific information about
potential failures with recipient domains. Recipient domains can
then use this information to both detect potential attackers and
diagnose unintentional misconfigurations.
"Federated Authentication for the Registration Data Access Protocol
(RDAP) using OpenID Connect", Scott Hollenbeck, 2016-04-26,
<draft-hollenbeck-regext-rdap-openid-00.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.
"Requirements for Data Aggregation in Intelligent Transportation
Systems", Zhiwei Yan, Jong-Hyouk Lee, 2016-04-26,
<draft-yan-its-aggregation-00.txt>
Considering the large-scale but small-sized information exchange in
the vehicular information network, this draft aims to outline the
requirements to support the data aggregation in ITS, in order to make
the information retrieval and dissemination more efficient.
"Neighbor discovery to support direct communication in ITS", Zhiwei Yan,
Jong-Hyouk Lee, 2016-04-26, <draft-yan-its-nd-00.txt>
For C-ACC, Platooning and other typical use cases in ITS, how to
establish direct IP communication paths between neighbor vehicles
poses "how to discover the neighbors" as the prime issue. In this
draft, the issue is analyzed.
"Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.5

Message Specification", Jim Schaad, Blake Ramsdell, spt, 2016-04-27,

<draft-schaad-rfc5751-bis-00.txt>
This document defines Secure/Multipurpose Internet Mail Extensions
(S/MIME) version 3.5. S/MIME provides a consistent way to send and
receive secure MIME data. Digital signatures provide authentication,
message integrity, and non-repudiation with proof of origin.
Encryption provides data confidentiality. Compression can be used to
reduce data size. This document obsoletes RFC 5751.
"A DNS Query including A Main Question with Accompanying Questions",
Jiankang Yao, Paul Vixie, Ning, XiaoDong Lee, 2016-04-28,
<draft-yao-dnsop-accompanying-questions-00.txt>
This document enables DNS initiators to send a main question
accompanying with several related questions in a single DNS query,
and enables DNS responders to put the answers into a single DNS
response. This mechanism can reduce the number of DNS round-trips
per application work-unit.
"Entertainment Identifier Registry (EIDR) URN Namespace Definition",
Pierre-Anthony Lemieux, 2016-04-30, <draft-pal-eidr-urn-2016-00.txt>
Entertainment Identifier Registry (EIDR) Identifiers are used for the
globally unique identification of motion picture and television
content. This document defines the formal Uniform Resource Name
(URN) Namespace Identifier (NID) for EIDR Identifiers.
This document revises Request For Comments (RFC) 7302 by allowing
confidential resolution of EIDR Identifiers using HTTP over TLS.
"64::/16: An IPv4/IPv6 translation prefix", Tore Anderson, 2016-05-01,
<draft-anderson-v6ops-v4v6-xlat-prefix-00.txt>
This document reserves the IPv6 prefix 64::/16 for use with IPv4/IPv6
translation mechanisms.
"Clarification to the channel closure procedure in Secure Shell (SSH)",
Simon Tatham, Damien Miller, 2016-05-04,
<draft-sgtatham-secsh-closure-race-02.txt>
This memo identifies an ambiguity in the Secure Shell (SSH)
connection protocol defined by RFC 4254 regarding the handling of
channel closure in combination with channel requests requiring a
reply, and issues a clarification specifying the correct
interpretation of the ambiguous point.
"IUTF8 Terminal Mode in Secure Shell (SSH)", Simon Tatham, Darren
Tucker, 2016-05-03, <draft-sgtatham-secsh-iutf8-01.txt>
This document specifies a value for the widely used IUTF8 bit in the
Secure Shell terminal modes encoding.
"An Update to 6LoWPAN ND", Pascal Thubert, Erik Nordmark, Samita
Chakrabarti, 2016-05-04, <draft-thubert-6lo-rfc6775-update-00.txt>
This specification proposes an update to 6LoWPAN Neighbor Discovery,
to clarify the role of the protocol as a registration technique, and
provide enhancements to the registration capabilities, in particular
for the registration to a backbone router for proxy ND operations.

"Header compression and multiplexing in LISP", Jose Saldana, Julian

Navajas, Jose Mas, 2016-05-04,
<draft-saldana-lisp-compress-mux-00.txt,.pdf>
When small payloads are transmitted
network, the resulting overhead may
stressed in the case of LISP, where
to a packet, as new headers have to

through a packet-switched
result significant. This is
a number of headers are prepended
be added to each packet.

This document proposes to send together a number of small packets,

which are in the buffer of a ITR, having the same ETR as destination,
into a single packet. Therefore, they will share a single LISP
header, and therefore bandwidth savings can be obtained, and a
reduction in the overall number of packets sent to the network can be
achieved.
"OpenPGP Web Key Service", Werner Koch, 2016-05-06,
<draft-koch-openpgp-webkey-service-00.txt>
This specification describes a service to
address using a Web service and the HTTPS
a method for secure communication between
provider to publish and revoke the public

locate OpenPGP keys by mail

protocol. It also provides
the key owner and the mail
key.

"Problem Statement and Considerations for ROA Mergence", Zhiwei Yan, Yu

Fu, Xiaowei Liu, Guanggang Geng, 2016-05-06,
<draft-yan-sidr-roa-mergence-00.txt>
The address space holder needs to issue an ROA object when it
authorizes one or more ASes to originate routes to multiple prefixes.
During the process of ROA issuance, the address space holder needs to
specify an origin AS for a list of IP prefixes. Besides, the address
space holder has a free choice to put multiple prefixes into a single
ROA or issue separate ROAs for each prefix based on the current
specification. This memo analyzes and presents some operational
problems which may be caused by the misconfigurations of ROAs
containing multiple IP prefixes. Some suggestions and considerations
also have been proposed.
"An Architecture for Use of PCE and PCEP in a Network with Central
Control", Adrian Farrel, Quintin Zhao, Zhenbin Li, Chao Zhou,
2016-05-06, <draft-zhao-teas-pce-control-function-00.txt>
The Path Computation Element (PCE) has become established as a core
component of Software Defined Networking (SDN) systems. It can
compute optimal paths for traffic across a network for any definition
of "optimal" and can also monitor changes in resource availability
and traffic demands to update the paths.
Conventionally, the PCE has been used to derive paths for MPLS Label
Switched Paths (LSPs). These paths are supplied using the Path
Computation Element Communication Protocol (PCEP) to the head end of
the LSP for signaling in the MPLS network.
SDN has a far broader applicability than just signaled MPLS traffic
engineered networks, and the PCE may be used to determine paths in a
wide range of use cases including static LSPs, segment routing,
service function chaining (SFC), and indeed any form of routed or
switched network. It is, therefore reasonable to consider PCEP as a

general southbound control protocol for use in these environments to

allow the PCE to be fully enabled as a central controller.
This document briefly introduces the architecture for PCE as a
central controller, examines the motivations and applicability for
PCEP as a southbound interface, and introduces the implications for
the protocol. This document does not describe the use cases in
detail and does not define protocol extensions: that work is left for
other documents.
"LISP EID Anonymity", Dino Farinacci, Padma Pillay-Esnault, 2016-05-06,
<draft-farinacci-lisp-eid-anonymity-00.txt>
This specification will describe how ephemeral LISP EIDs can be used
to create source anonymity. The idea makes use of frequently
changing EIDs much like how a credit-card system uses a different
credit-card numbers for each transaction.
"LISP Predictive RLOCs", Dino Farinacci, Padma Pillay-Esnault,
2016-05-06, <draft-farinacci-lisp-predictive-rlocs-00.txt>
This specification will describe a method to achieve near-zero packet
loss when an EID is roaming quickly across RLOCs.
"Multi-site EVPN based VXLAN using Border Gateways", Rajesh Sharma, Ayan
Banerjee, Raghava Sivaramu, 2016-05-06,
<draft-sharma-multi-site-evpn-00.txt>
This document describes the procedures for interconnecting two or
more BGP based Ethernet VPN (EVPN) sites in a scalable fashion over
an IP-only network. The motivation is to support extension of EVPN
sites without having to rely on typical Data Center Interconnect
(DCI) technologies like MPLS/VPLS for the interconnection. The
requirements for such a deployment are very similar to the ones
specified in RFC 7209 -- "Requirements for Ethernet VPN (EVPN)".
Network Time Protocol (ntp)
--------------------------"Network Time Security", Dieter Sibold, Stephen Roettger, Kristof
Teichel, 2016-03-21, <draft-ietf-ntp-network-time-security-14.txt>
This document describes Network Time Security (NTS), a collection of
measures that enable secure time synchronization with time servers
using protocols like the Network Time Protocol (NTP) or the Precision
Time Protocol (PTP). Its design considers the special requirements
of precise timekeeping which are described in Security Requirements
of Time Protocols in Packet Switched Networks [RFC7384].
"Protecting Network Time Security Messages with the Cryptographic
Message Syntax (CMS)", Dieter Sibold, Kristof Teichel, Stephen Roettger,
Russ Housley, 2016-02-25, <draft-ietf-ntp-cms-for-nts-message-06.txt>
This document describes a convention for using the Cryptographic
Message Syntax (CMS) to protect the messages in the Network Time
Security (NTS) protocol. NTS provides authentication of time servers
as well as integrity protection of time synchronization messages
using Network Time Protocol (NTP) or Precision Time Protocol (PTP).
"Using the Network Time Security Specification to Secure the Network

Time Protocol", Dieter Sibold, Stephen Roettger, Kristof Teichel,

2016-03-21, <draft-ietf-ntp-using-nts-for-ntp-05.txt>
This document describes how to use the measures described in the
Network Time Security (NTS) specification to secure time
synchronization with servers using the Network Time Protocol (NTP).
"Network Time Protocol Best Current Practices", Denis Reilly, H. Stenn,
Dieter Sibold, 2016-03-09, <draft-reilly-ntp-bcp-01.txt>
NTP Version 4 (NTPv4) has been widely used since its publication as
RFC 5905 [RFC5905]. This documentation is a collection of Best
Practices from across the NTP community.
"The Network Time Protocol Version 4 (NTPv4) MAC Extension Field", Danny
Mayer, H. Stenn, 2016-03-14,
<draft-mayer-ntp-mac-extension-field-00.txt>
The Network Time Protocol Version 4 (NTPv4) defines in RFC5905 the
optional usage of Message Authentication Code (MAC). The MAC is an
optional component of the NTP packet at the end of the packet. There
can only be one MAC segment in the packet but there is no way of
knowing if the last data segment at the end of an NTP packet is a MAC
or an extension field, which is also defined in RFC5905. This draft
defines a MAC extension field which will allow the existing MAC
segment to be moved into an extension field and have a known length
and deprecates the existing MAC.
"Network Time Protocol I-Do Extension Field", H. Stenn, 2016-04-25,
<draft-stenn-ntp-i-do-01.txt>
The first implementation of NTPv4 was released in 2003. NTPv4 is
defined by RFC 5905 [RFC5905]. It contains a public-key security
protocol, autokey, which is defined by RFC 5906 [RFC5906]. Until
very recently, autokey has been the only defined "user" of NTP packet
Extension Fields. New proposals for extension fields are being
written and there is currently no convenient way to learn if a remote
instance of NTP supports any extension fields or not. This proposal
contains a method to tell a remote instance of NTP what we support,
and ask what they support.
"Network Time Protocol IPv6 REFID Hash", H. Stenn, 2016-03-14,
<draft-stenn-ntp-ipv6-refid-hash-00.txt>
RFC 5905 [RFC5905], section 7.3, "Packet Header Variables", defines
the value to be used as the REFID for network associations. For IPv4
associations the IPv4 address is used, and for IPv6 associations four
octets of the MD5 hash of the IPv6 are used. Often, the REFID is
simplistically and incorrectly used to identify upstream servers.
While this works in an IPv4 network, it doesn't work for IPv6
associations and may have other problems in an environment with mixed
use of IPv4 and IPv6. Specifically, the NTP Project has received a
report where the generated IPv6 hash decoded to the IPv4 address of a
different machine on the system peer's network.
This proposal offers a way for a system to generate a REFID for a
system peer that communicates over IPv6 that does not conflict with a
valid IPv4-based REFID.
"Network Time Protocol Last Extension Field", H. Stenn, 2016-03-14,

<draft-stenn-ntp-last-extension-00.txt>
NTPv4 is defined by RFC 5905 [RFC5905], and it and earlier versions
of the NTP Protocol have supported symmetric private key MAC
authentication. MACs pre-date the Extension Fields introduced in RFC
5905 [RFC5905], and as the number of Extension Fields grows there is
an increasing chance of ambiguity when deciding if the "next" set of
data is an Extension Field or a MAC. This proposal defines a new
Extension Field which is used to signifiy that it is the last
Extension Field in the packet. If present, any subsequent data
SHOULD be considered to be a legacy MAC.
"Network Time Protocol Leap Smear REFID", H. Stenn, 2016-03-14,
<draft-stenn-ntp-leap-smear-refid-00.txt>
RFC 5905 [RFC5905] and earlier versions of NTP are the overwhelming
method of distributing time on networks. Leap Seconds will continue
to exist for a good number of years' time, and since the timescale
mandated by POSIX effectively ignores any instances where there are
not 86,400 seconds' time in a day, something must be done to reliably
synchronize clocks during the application of leap second corrections.
One mechanism for dealing with the application that has recently
become visible is to apply the leap second using a "smear", where the
time reported by leap-second aware servers is gradually adjusted so
there is no major disruption to time synchronization when processing
a leap second.
While leap second processing can be expected to be properly handled
by up-to-date software and by time servers, there are large numbers
of out-of-date software installations and client systems that are
just not able to properly handle a leap second correction.
This proposal offers a way for a system to generate a REFID that
indicates that the time being supplied in the NTP packet already
contains an amount of leap smear correction, and what that amount is.
"Network Time Protocol Suggest REFID Extension Field", H. Stenn,
2016-03-14, <draft-stenn-ntp-suggest-refid-00.txt>
NTP has been widely used through several revisions, with the latest
being RFC 5905 [RFC5905]. A core component of the protocol and the
algoritms is the Reference ID, or REFID, which is used to identify
the source of time used for synchronization. Traditionally, when the
source of time was another system the REFID was the IPv4 address of
that other system. The purpose of the REFID is to prevent a onedegree timing loop, where if A has several timing sources that
include B, if B decides to get its time from A we don't want A then
deciding to get its time from B. The REFID is considered to be
"public data" and is a vital core-component of the base NTP packet.
If a system's REFID is the IPv4 address of its system peer, an
attacker can try to use that information to send spoofed time packets
to either or both the target or the target's server, attempting to
cause a disruption in time service. This proposal is a backwardcompatible way for a time source to tell its peers or clients "If you
use me as your system peer, use this nonce as your REFID." This
nonce SHOULD not be traceable to the original system, and if it is
used as the REFID this type of attack is prevented.
Network Virtualization Overlays (nvo3)
--------------------------------------

"Network Virtualization NVE to NVA Control Protocol Requirements",

Lawrence Kreeger, Dinesh Dutt, Thomas Narten, David Black, 2016-03-21,
<draft-ietf-nvo3-nve-nva-cp-req-05.txt>
[RFC7364] "Problem Statement: Overlays for Network Virtualization"
discusses the needs for network virtualization using overlay networks
in highly virtualized data centers. The problem statement outlines a
need for control protocols to facilitate running these overlay
networks. This document outlines the high level requirements to be
fulfilled by the control protocols related to building and managing
the mapping tables and other state information used by the Network
Virtualization Edge to transmit encapsulated packets across the
underlying network.
"Security Requirements of NVO3", Sam Hartman, Dacheng Zhang, Margaret
Wasserman, Zu Qiang, Mingui Zhang, 2015-12-15,
<draft-ietf-nvo3-security-requirements-06.txt>
The draft describes a list of essential requirements in order to
benefit the design of NVO3 security solutions. In addition, this
draft introduces the candidate techniques which could be used to
construct a security solution fulfilling these security requirements.
"An Architecture for Data Center Network Virtualization Overlays
(NVO3)", David Black, Jon Hudson, Lawrence Kreeger, Marc Lasserre,
Thomas Narten, 2016-04-21, <draft-ietf-nvo3-arch-06.txt>
This document presents a high-level overview architecture for
building data center network virtualization overlay (NVO3) networks.
The architecture is given at a high-level, showing the major
components of an overall system. An important goal is to divide the
space into individual smaller components that can be implemented
independently and with clear interfaces and interactions with other
components. It should be possible to build and implement individual
components in isolation and have them work with other components with
no changes to other components. That way implementers have
flexibility in implementing individual components and can optimize
and innovate within their respective components without requiring
changes to other components.
"Split-NVE Control Plane Requirements", Li Yizhou, Lucy Yong, Lawrence
Kreeger, Thomas Narten, David Black, 2016-02-18,
<draft-ietf-nvo3-hpvr2nve-cp-req-04.txt>
In a Split-NVE architecture, the functions of the NVE are split
across a server and an external network equipment which is called an
external NVE. The server-resident control plane functionality
resides in control software, which may be part of a hypervisor or
container management software; for simplicity, this draft refers to
the hypervisor as the location of this software.
A control plane protocol(s) between a hypervisor and its associated
external NVE(s) is used for the hypervisor to distribute its virtual
machine networking state to the external NVE(s) for further handling.
This document illustrates the functionality required by this type of
control plane signaling protocol and outlines the high level
requirements. Virtual machine states as well as state transitioning
are summarized to help clarifying the needed protocol requirements.

"Generic UDP Encapsulation", Tom Herbert, Lucy Yong, Osama Zia,

2015-12-22, <draft-ietf-nvo3-gue-02.txt>
This specification describes Generic UDP Encapsulation (GUE), which
is a scheme for using UDP to encapsulate packets of arbitrary IP
protocols for transport across layer 3 networks. By encapsulating
packets in UDP, specialized capabilities in networking hardware for
efficient handling of UDP packets can be leveraged. GUE specifies
basic encapsulation methods upon which higher level constructs, such
tunnels and overlay networks for network virtualization, can be
constructed. GUE is extensible by allowing optional data fields as
part of the encapsulation, and is generic in that it can encapsulate
packets of various IP protocols.
"Generic Protocol Extension for VXLAN", Lawrence Kreeger, Uri Elzur,
2016-04-21, <draft-ietf-nvo3-vxlan-gpe-02.txt>
This draft describes extending Virtual eXtensible Local Area Network
(VXLAN), via changes to the VXLAN header, with three new
capabilities: support for multi-protocol encapsulation, operations,
administration and management (OAM) signaling and explicit
versioning.
"Geneve: Generic Network Virtualization Encapsulation", Jesse Gross,
Ilango Ganga, 2016-01-14, <draft-ietf-nvo3-geneve-01.txt>
Network virtualization involves the cooperation of devices with a
wide variety of capabilities such as software and hardware tunnel
endpoints, transit fabrics, and centralized control clusters. As a
result of their role in tying together different elements in the
system, the requirements on tunnels are influenced by all of these
components. Flexibility is therefore the most important aspect of a
tunnel protocol if it is to keep pace with the evolution of the
system. This draft describes Geneve, a protocol designed to
recognize and accommodate these changing capabilities and needs.
"A Framework for Multicast in NVO3", Anoop Ghanwani, Linda Dunbar, Mike
McBride, Vinay Bannai, Ram (Ramki) Krishnan, 2016-02-15,
<draft-ietf-nvo3-mcast-framework-04.txt>
This document discusses a framework of supporting multicast traffic
in a network that uses Network Virtualization Overlays over Layer 3
(NVO3). Both infrastructure multicast and application-specific
multicast are discussed. It describes the various mechanisms that
can be used for delivering such traffic as well as the data plane
and control plane considerations for each of the mechanisms.
Web Authorization Protocol (oauth)
---------------------------------"OAuth 2.0 Proof-of-Possession (PoP) Security Architecture", Phil Hunt,
Justin Richer, William Mills, Prateek Mishra, Hannes Tschofenig,
2015-12-01, <draft-ietf-oauth-pop-architecture-07.txt>
The OAuth 2.0 bearer token specification, as defined in RFC 6750,
allows any party in possession of a bearer token (a "bearer") to get
access to the associated resources (without demonstrating possession
of a cryptographic key). To prevent misuse, bearer tokens must be
protected from disclosure in transit and at rest.

Some scenarios demand additional security protection whereby a client

needs to demonstrate possession of cryptographic keying material when
accessing a protected resource. This document motivates the
development of the OAuth 2.0 proof-of-possession security mechanism.
"A Method for Signing HTTP Requests for OAuth", Justin Richer, J.
Bradley, Hannes Tschofenig, 2016-02-03,
<draft-ietf-oauth-signed-http-request-02.txt>
This document a method for offering data origin authentication and
integrity protection of HTTP requests. To convey the relevant data
items in the request a JSON-based encapsulation is used and the JSON
Web Signature (JWS) technique is re-used. JWS offers integrity
protection using symmetric as well as asymmetric cryptography.
"OAuth 2.0 Token Exchange: An STS for the REST of Us", Michael Jones,
Anthony Nadalin, Brian Campbell, J. Bradley, Chuck Mortimore,
2016-03-04, <draft-ietf-oauth-token-exchange-04.txt,.pdf>
This specification defines a protocol for a lightweight HTTP- and
JSON- based Security Token Service (STS) by defining how to request
and obtain security tokens from OAuth 2.0 authorization servers,
including security tokens employing impersonation and delegation.
"OAuth 2.0 JWT Authorization Request", Nat Sakimura, J. Bradley,
2016-01-19, <draft-ietf-oauth-jwsreq-07.txt,.pdf>
The authorization request in OAuth 2.0 [RFC6749] utilizes query
parameter serialization, which means that parameters are encoded in
the URI of the request. This document introduces the ability to send
request parameters in form of a JSON Web Token (JWT) instead, which
allows the request to be signed and encrypted. using JWT
serialization. The request is sent by value or by reference.
"OAuth 2.0 Security: Closing Open Redirectors in OAuth", J. Bradley,
Antonio Sanso, Hannes Tschofenig, 2016-02-04,
<draft-ietf-oauth-closing-redirectors-00.txt>
This document gives additional security considerations for OAuth,
beyond those in the OAuth 2.0 specification and in the OAuth 2.0
Threat Model and Security Considerations.
"OAuth 2.0 for Native Apps", W. Denniss, J. Bradley, 2016-03-20,
<draft-ietf-oauth-native-apps-01.txt>
OAuth 2.0 authorization requests from native apps should only be made
through external user-agents such as the system browser (including
via an in-app browser tab). This specification details the security
and usability reasons why this is the case, and how native apps and
authorization servers can implement this best practice.
"OAuth 2.0 Authorization Server Discovery Metadata", Michael Jones, Nat
Sakimura, J. Bradley, 2016-03-21, <draft-ietf-oauth-discovery-02.txt>
This specification defines a discovery metadata format that an OAuth
2.0 client can use to obtain the information needed to interact with
an OAuth 2.0 authorization server, including its endpoint locations
and authorization server capabilities.
"OAuth 2.0 Device Flow", W. Denniss, Stein Myrseth, J. Bradley, Michael

Jones, Hannes Tschofenig, 2016-03-03,

<draft-ietf-oauth-device-flow-01.txt>
The device flow is suitable for OAuth 2.0 clients executing on
devices that do not have an easy data-entry method (e.g., game
consoles, TVs, picture frames, and media hubs), but where the enduser has separate access to a user-agent on another computer or
device (e.g., desktop computer, a laptop, a smart phone, or a
tablet).
"Authentication Method Reference Values", Michael Jones, Phil Hunt,
Anthony Nadalin, 2016-03-20, <draft-ietf-oauth-amr-values-00.txt>
The "amr" (Authentication Methods References) claim is defined and
registered in the IANA "JSON Web Token Claims" registry but no
standard Authentication Method Reference values are currently
defined. This specification establishes a registry for
Authentication Method Reference values and defines an initial set of
Authentication Method Reference values.
"OAuth 2.0 Mix-Up Mitigation", Michael Jones, J. Bradley, Nat Sakimura,
2016-03-20, <draft-ietf-oauth-mix-up-mitigation-00.txt>
This specification defines an extension to The OAuth 2.0
Authorization Framework that enables the authorization server to
dynamically provide the client using it with additional information
about the current protocol interaction that can be validated by the
client and that enables the client to dynamically provide the
authorization server with additional information about the current
protocol interaction that can be validated by the authorization
server. This additional information can be used by the client and
the authorization server to prevent classes of attacks in which the
client might otherwise be tricked into using inconsistent sets of
metadata from multiple authorization servers, including potentially
using a token endpoint that does not belong to the same authorization
server as the authorization endpoint used. Recent research
publications refer to these as "IdP Mix-Up" and "Malicious Endpoint"
attacks.
Operations and Management Area (ops)
-----------------------------------"Reclassification of COPS-PR and SPPI to Historic", Jrgen Schnwlder,
2016-04-13, <draft-schoenw-opsawg-copspr-historic-04.txt>
This memo requests the reclassification of RFC 3084, COPS Usage for
Policy Provisioning, RFC 3159, Structure of Policy Provisioning
Information, RFC 3317, Differentiated Services Quality of Service
Policy Information Base, RFC 3318, Framework Policy Information Base,
and RFC 3571, Framework Policy Information Base for Usage, Feedback,
to Historic status.
"Exporting MIB Variables using the IPFIX Protocol", Paul Aitken, Benoit
Claise, Srikar S, Colin McDowall, Jrgen Schnwlder, 2015-11-20,
<draft-ietf-ipfix-mib-variable-export-10.txt>
This document specifies a way to complement IPFIX Data Records with
Management Information Base (MIB) objects, avoiding the need to
define new IPFIX Information Elements for existing Management
Information Base objects that are already fully specified.

An IPFIX Options Template and method are specified, which are used to
export the extra information required to fully describe Simple
Network Management Protocol (SNMP) MIB objects in IPFIX.
Operations and Management Area Working Group (opsawg)
----------------------------------------------------"The TACACS+ Protocol", Thorsten Dahm, Andrej Ota, D. Medway Gash, David
Carrel, Jerome Marcon, 2016-04-12,
<draft-ietf-opsawg-tacacs-02.txt,.pdf>
TACACS+ provides Device Administration for routers, network access
servers and other networked computing devices via one or more
centralized servers. This document describes the protocol that is
used by TACACS+.
Operational Security Capabilities for IP Network Infrastructure (opsec)
----------------------------------------------------------------------"Operational Security Considerations for IPv6 Networks", Kiran
Chittimaneni, Merike Kaeo, Eric Vyncke, 2016-03-21,
<draft-ietf-opsec-v6-08.txt>
Knowledge and experience on how to operate IPv4 securely is
available: whether it is the Internet or an enterprise internal
network. However, IPv6 presents some new security challenges. RFC
4942 describes the security issues in the protocol but network
managers also need a more practical, operations-minded document to
enumerate advantages and/or disadvantages of certain choices.
This document analyzes the operational security issues in all places
of a network (enterprises, service providers and residential users)
and proposes technical and procedural mitigations techniques.
Open Shortest Path First IGP (ospf)
----------------------------------"OSPFv3 LSA Extendibility", Acee Lindem, Sina Mirtorabi, Abhay Roy, Fred
Baker, 2015-11-19, <draft-ietf-ospf-ospfv3-lsa-extend-09.txt>
OSPFv3 requires functional extension beyond what can readily be done
with the fixed-format Link State Advertisement (LSA) as described in
RFC 5340. Without LSA extension, attributes associated with OSPFv3
links and advertised IPv6 prefixes must be advertised in separate
LSAs and correlated to the fixed-format LSAs. This document extends
the LSA format by encoding the existing OSPFv3 LSA information in
Type-Length-Value (TLV) tuples and allowing advertisement of
additional information with additional TLVs. Backward compatibility
mechanisms are also described.
"OSPF Extensions for Segment Routing", Peter Psenak, Stefano Previdi,
Clarence Filsfils, Hannes Gredler, Rob Shakir, Wim Henderickx, Jeff
Tantsura, 2016-04-27,
<draft-ietf-ospf-segment-routing-extensions-08.txt>
Segment Routing (SR) allows a flexible definition of end-to-end paths
within IGP topologies by encoding paths as sequences of topological
sub-paths, called "segments". These segments are advertised by the
link-state routing protocols (IS-IS and OSPF).

This draft describes the OSPF extensions required for Segment

Routing.
"OSPFv3 Extensions for Segment Routing", Peter Psenak, Stefano Previdi,
Clarence Filsfils, Hannes Gredler, Rob Shakir, Wim Henderickx, Jeff
Tantsura, 2016-03-21,
<draft-ietf-ospf-ospfv3-segment-routing-extensions-05.txt>
Segment Routing (SR) allows for a flexible definition of end-to-end
paths within IGP topologies by encoding paths as sequences of
topological sub-paths, called "segments". These segments are
advertised by the link-state routing protocols (IS-IS and OSPF).
This draft describes the OSPFv3 extensions that are required for
Segment Routing.
"OSPF Extensions to Advertise Seamless Bidirectional Forwarding
Detection (S-BFD) Target Discriminators", Carlos Pignataro, Manav
Bhatia, Sam Aldrin, Trilok Ranganath, 2016-04-29,
<draft-ietf-ospf-sbfd-discriminator-06.txt>
This document defines a new OSPF Router Information (RI) TLV that
allows OSPF routers to flood the Seamless Bidirectional Forwarding
Detection (S-BFD) discriminator values associated with a target
network identifier. This mechanism is applicable to both OSPFv2 and
OSPFv3.
"OSPFv3 over IPv4 for IPv6 Transition", I. Chen, Acee Lindem, R.
Atkinson, 2016-04-11, <draft-ietf-ospf-transition-to-ospfv3-04.txt>
This document defines a mechanism to use IPv4 to transport OSPFv3
packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address
Family extension can simplify transition from an OSPFv2 IPv4-only
routing domain to an OSPFv3 dual-stack routing domain. This document
updates RFC 5838 to support virtual links in the IPv4 unicast address
family when using OSPFv3 over IPv4.
"OSPF Two-part Metric", Jeffrey Zhang, Lili Wang, Acee Lindem, Dave
DuBois, Vibhor Julka, Tom McMillan, 2016-05-05,
<draft-ietf-ospf-two-part-metric-05.txt>
This document specifies an optional extension to the OSPF protocol,
to represent the metric on a multi-access network as two parts: the
metric from a router to the network, and the metric from the network
to the router. The router to router metric would be the sum of the
two. This document updates RFC 2328 and RFC 5340.
"OSPF Topology-Transparent Zone", Huaimo Chen, Renwei Li, Alvaro Retana,
Yi Yang, Vic Liu, Mehmet Toy, 2016-03-10, <draft-ietf-ospf-ttz-03.txt>
This document presents a topology-transparent zone in an OSPF area.
A topology-transparent zone comprises a group of routers and a number
of links connecting these routers. Any router outside of the zone is
not aware of the zone. The information about the links and routers
such as a link down inside the zone is not advertised to any router
outside of the zone.
"Yang Data Model for OSPF Protocol", Derek Yeung, Yingzhen Qu, Jeffrey
Zhang, Dean Bogdanovic, Kiran Koushik, 2016-03-21,

<draft-ietf-ospf-yang-04.txt>
This document defines a YANG data model that can be used to configure
and manage OSPF.
"Signaling Entropy Label Capability Using OSPF", Xiaohu Xu, Sriganesh
Kini, Siva Sivabalan, Clarence Filsfils, Stephane Litkowski, 2016-05-04,
<draft-ietf-ospf-mpls-elc-02.txt>
Multi Protocol Label Switching (MPLS) has defined a mechanism to load
balance traffic flows using Entropy Labels (EL). An ingress LSR
cannot insert ELs for packets going into a given tunnel unless an
egress LSR has indicated via signaling that it can process ELs on
that tunnel. This draft defines a mechanism to signal that
capability using OSPF. This mechanism is useful when the label
advertisement is also done via OSPF.
"OSPF Extensions for Flow Specification", LQD, Jianjie You, Nan Wu, Peng
Fan, Keyur Patel, Acee Lindem, 2016-04-14,
<draft-ietf-ospf-flowspec-extensions-01.txt>
Dissemination of the Traffic flow information was first introduced in
the BGP protocol [RFC5575]. FlowSpec routes are used to distribute
traffic filtering rules that are used to filter Denial-of-Service
(DoS) attacks. For the networks that only deploy an IGP (Interior
Gateway Protocol) (e.g., OSPF), it is required that the IGP is
extended to distribute Flow Specification or FlowSpec routes.
This document discusses the use cases for distributing flow
specification (FlowSpec) routes using OSPF. Furthermore, this
document defines a OSPF FlowSpec Opaque Link State Advertisement
(LSA) encoding format that can be used to distribute FlowSpec routes,
its validation procedures for imposing the filtering information on
the routers, and a capability to indicate the support of FlowSpec
functionality.
"OSPF Link Overload", Shraddha Hegde, Hannes Gredler, Mohan Nanduri,
Luay Jalil, 2016-01-06, <draft-ietf-ospf-link-overload-01.txt,.pdf>
When a link is being prepared to be taken out of service, the traffic
needs to be diverted from both ends of the link. Increasing the
metric to the highest metric on one side of the link is not
sufficient to divert the traffic flowing in the other direction.
It is useful for routers in an
able to advertise a link being
impending maintenance activity
used by the network devices to

OSPFv2 or OSPFv3 routing domain to be

in an overload state to indicate
on the link. This information can be
re-route the traffic effectively.

This document describes the protocol extensions to disseminate link

overload information in OSPFv2 and OSPFv3.
Peer-to-Peer Session Initiation Protocol (p2psip)
------------------------------------------------"Concepts and Terminology for Peer to Peer SIP", David Bryan, Philip
Matthews, Eunsoo Shim, Dean Willis, Spencer Dawkins, 2016-04-21,
<draft-ietf-p2psip-concepts-09.txt>
This document defines concepts and terminology for the use of the

Session Initiation Protocol in a peer-to-peer environment where the

traditional proxy-registrar and message routing functions are
replaced by a distributed mechanism. These mechanisms may be
implemented using a distributed hash table or other distributed data
mechanism with similar external properties. This document includes a
high-level view of the functional relationships between the network
elements defined herein, a conceptual model of operations, and an
outline of the related problems addressed by the P2PSIP working group
and the RELOAD protocol and SIP usage document defined by the working
group.
"A SIP Usage for RELOAD", Cullen Jennings, Bruce Lowekamp, Eric
Rescorla, Salman Baset, Henning Schulzrinne, Thomas Schmidt, 2016-04-27,
<draft-ietf-p2psip-sip-21.txt>
This document defines a SIP Usage for REsource LOcation And Discovery
(RELOAD). The SIP Usage provides the functionality of a SIP proxy or
registrar in a fully-distributed system and includes a lookup service
for Address of Records (AORs) stored in the overlay. It also defines
Globally Routable User Agent URIs (GRUUs) that allow the
registrations to map an AOR to a specific node reachable through the
overlay. After such initial contact of a peer, the RELOAD AppAttach
method is used to establish a direct connection between nodes through
which SIP messages are exchanged.
"P2P Overlay Diagnostics", Haibin Song, Jiang Xingfeng, Roni Even, David
Bryan, Yi Sun, 2016-03-25, <draft-ietf-p2psip-diagnostics-22.txt>
This document describes mechanisms for P2P overlay diagnostics. It
defines extensions to the RELOAD base protocol to collect diagnostic
information, and details the protocol specifications for these
extensions. Useful diagnostic information for connection and node
status monitoring is also defined. The document also describes the
usage scenarios and provides examples of how these methods are used
to perform diagnostics.
"A Usage for Shared Resources in RELOAD (ShaRe)", Alexander Knauf,
Thomas Schmidt, Gabriel Hege, Matthias Waehlisch, 2016-03-20,
<draft-ietf-p2psip-share-08.txt>
This document defines a RELOAD Usage for managing shared write access
to RELOAD Resources. Shared Resources in RELOAD (ShaRe) form a basic
primitive for enabling various coordination and notification schemes
among distributed peers. Access in ShaRe is controlled by a
hierarchical trust delegation scheme maintained within an access
list. A new USER-CHAIN-ACL access policy allows authorized peers to
write a Shared Resource without owning its corresponding certificate.
This specification also adds mechanisms to store Resources with a
variable name which is useful whenever peer-independent rendezvous
processes are required.
Pseudowire And LDP-enabled Services (pals)
-----------------------------------------"LDP Extensions for Pseudowire Binding to LSP Tunnels", Mach Chen, Wei
Cao, Attila Takacs, Ping Pan, 2015-12-03,
<draft-ietf-pals-mpls-tp-pw-over-bidir-lsp-06.txt>
Many transport services require that user traffic, in the form of
Pseudowires (PW), be delivered on a single co-routed bidirectional

LSP or two LSPs that share the same routes. In addition, the user
traffic may traverse through multiple transport networks.
This document defines an optional extension to LDP that enables the
binding between PWs and the underlying LSPs.
"Pseudowire Setup and Maintenance using the Label Distribution
Protocol", Luca Martini, Giles Heron, 2016-02-04,
<draft-ietf-pals-rfc4447bis-03.txt>
Layer 2 services (such as Frame Relay, Asynchronous Transfer Mode,
and Ethernet) can be "emulated" over an MPLS backbone by
encapsulating the Layer 2 Protocol Data Units (PDU) and then
transmitting them over "pseudowires". It is also possible to use
pseudowires to provide low-rate Time Division Multiplexed and
Synchronous Optical NETworking circuit emulation over an MPLS-enabled
network. This document specifies a protocol for establishing and
maintaining the pseudowires, using extensions to the Label
Distribution Protocol (LDP). Procedures for encapsulating Layer 2
PDUs are specified in a set of companion documents.
This document has been written to address errata in a previous
version of this standard.
"Dual-Homing Coordination for MPLS Transport Profile (MPLS-TP)
Pseudowires Protection", Weiqiang Cheng, Lei Wang, Han Li, Kai Liu,
Shahram Davari, Jie Dong, Alessandro D'Alessandro, 2016-03-20,
<draft-ietf-pals-mpls-tp-dual-homing-coordination-02.txt>
In some scenarios, the MPLS Transport Profile (MPLS-TP) Pseudowires
(PWs) are provisioned through either static configuration or
management plane, where a dynamic control plane is not available. A
fast protection mechanism for MPLS-TP PWs is needed to protect
against the failure of Attachment Circuit (AC), the failure of
Provider Edge (PE) and also the failure in the Packet Switched
Network (PSN). The framework and typical scenarios of dual-homing PW
local protection are described in [draft-ietf-pals-mpls-tp-dualhoming-protection]. This document proposes a dual-homing
coordination mechanism for MPLS-TP PWs, which is used for state
exchange and switchover coordination between the dual-homing PEs for
dual-homing PW local protection.
"Dual-Homing Protection for MPLS and MPLS-TP Pseudowires", Weiqiang
Cheng, Lei Wang, Han Li, Kai Liu, Shahram Davari, Jie Dong, Alessandro
D'Alessandro, 2016-03-20,
<draft-ietf-pals-mpls-tp-dual-homing-protection-02.txt>
This document describes a framework and several scenarios for
pseudowire (PW) dual-homing local protection. A Dual-Node
Interconnection (DNI) PW is provisioned between the dual-homing
Provider Edge (PE) nodes for carrying traffic when failure occurs in
the Attachment Circuit (AC) or PW side. In order for the dual-homing
PE nodes to determine the forwarding state of AC, PW and the DNI PW,
necessary state exchange and coordination between the dual-homing PEs
are needed. The PW dual-homing local protection mechanism is
complementary to the existing PW protection mechanisms.
"Protocol Independent Multicast (PIM) over Virtual Private LAN Service
(VPLS)", Olivier Dornon, Jayant Kotalwar, Venu Hemige, Ray Qiu, Jeffrey
Zhang, 2016-04-15, <draft-ietf-pals-vpls-pim-snooping-02.txt>

This document describes the procedures and recommendations for

Virtual Private LAN Service (VPLS) Provider Edges (PEs) to facilitate
replication of multicast traffic to only certain ports (behind which
there are interested Protocol Independent Multicast (PIM) routers
and/or Internet Group Management Protocol (IGMP) hosts) via Protocol
Independent Multicast (PIM) snooping and proxying.
With PIM snooping, PEs passively listen to certain PIM control
messages to build control and forwarding states while transparently
flooding those messages. With PIM proxying, Provider Edges (PEs) do
not flood PIM Join/Prune messages but only generate their own and
send out of certain ports, based on the control states built from
downstream Join/Prune messages. PIM proxying is required when PIM
Join suppression is enabled on the Customer Equipment (CE) devices
and useful to reduce PIM control traffic in a VPLS domain.
The document also describes PIM relay, which can be viewed as lightweight proxying, where all downstream Join/Prune messages are simply
forwarded out of certain ports but not flooded to avoid triggering
PIM Join suppression on CE devices.
"Multi-chassis Passive Optical Network (PON) Protection in MPLS",
Yuanlong Jiang, Yong Luo, Edwin Mallette, Yimin Shen, Guangtao Zhou,
2016-03-18, <draft-ietf-pals-mc-pon-03.txt>
MPLS is being deployed deeper into operator networks, often to or
past the access network node. Separately network access nodes such
as Passive Optical Network (PON) Optical Line Terminations (OLTs)
have evolved to support first-mile access protection, where one or
more physical OLTs provide first-mile diversity to the customer edge.
Multi-homing support is needed on the MPLS-enabled PON OLT to
provide resiliency for provided services. This document describes
the multi-chassis PON protection architecture in MPLS and also
specifies the Inter-Chassis Communication Protocol (ICCP) extension
to support it.
"PW Endpoint Fast Failure Protection", Yimin Shen, Rahul Aggarwal, Wim
Henderickx, Yuanlong Jiang, 2016-01-27,
<draft-ietf-pals-endpoint-fast-protection-02.txt>
This document specifies a fast mechanism for protecting pseudowires
against egress endpoint failures, including egress attachment circuit
failure, egress PE failure, multi-segment PW terminating PE failure,
and multi-segment PW switching PE failure. Operating on the basis of
multi-homed CE, redundant PWs, upstream label assignment and context
specific label switching, the mechanism enables local repair to be
performed by the router upstream adjacent to a failure. The router
can restore a PW in the order of tens of milliseconds, by rerouting
traffic around the failure to a protector through a pre-established
bypass tunnel. Therefore, the mechanism can be used to reduce
traffic loss before global repair reacts to the failure and the
network converges on the topology changes due to the failure.
"Seamless BFD for VCCV", Vengada Govindan, Carlos Pignataro, 2016-04-29,
<draft-ietf-pals-seamless-vccv-03.txt>
This document extends the procedures and Connectivity Verification
(CV) types already defined for Bidirectional Forwarding Detection
(BFD) for Virtual Circuit Connectivity Verification (VCCV) to define

Seamless BFD (S-BFD) for VCCV. This document updates RFC 5885,
extending the CV Values and the Capability Selection.
"Pseudowire Congestion Considerations", Yaakov Stein, David Black, Bob
Briscoe, 2016-04-21, <draft-ietf-pals-congcons-02.txt,.pdf>
Pseudowires (PWs) have become a common mechanism for tunneling
traffic, and may be found in unmanaged scenarios competing for
network resources both with other PWs and with non-PW traffic, such
as TCP/IP flows. It is thus worthwhile specifying under what
conditions such competition is acceptable, i.e., the PW traffic does
not significantly harm other traffic or contribute more than it
should to congestion. We conclude that PWs transporting responsive
traffic behave as desired without the need for additional mechanisms.
For inelastic PWs (such as TDM PWs) we derive a bound under which
such PWs consume no more network capacity than a TCP flow. For TDM
PWs, we find that the level of congestion at which the PW can no
longer deliver acceptable TDM service is never significantly greater,
and typically much lower, than this bound. Therefore, as long as the
PW is shut down when it can no longer deliver acceptable TDM service,
it will never do significantly more harm than even a single TCP flow.
If the TDM service does not automatically shut down, a mechanism to
block persistently unacceptable TDM pseudowires is required.
"MPLS LSP PW status refresh reduction for Static Pseudowires", Luca
Martini, George Swallow, Elisa Bellagamba, 2016-02-04,
<draft-ietf-pals-status-reduction-00.txt>
This document describes a method for generating an aggregated
pseudowire status message on Multi-Protocol Label Switching (MPLS)
network Label Switched Path (LSP).
The method for transmitting the pseudowire (PW) status information is
not new, however this protocol extension allows a Service Provider
(SP) to reliably monitor the individual PW status while not
overwhelming the network of multiple periodic status messages. This
is achieved by sending a single cumulative summary status
verification message for all the PWs grouped in the same LSP.
"Signaling Root-Initiated Point-to-Multipoint Pseudowire using LDP",
Siva Sivabalan, Sami Boutros, Luca Martini, Maciek Konstantynowicz,
Gianni Vecchio, Yuji Kamite, Lizhong Jin, 2016-03-21,
<draft-ietf-pals-p2mp-pw-00.txt>
This document specifies a mechanism to signal Point-to-Multipoint
(P2MP) Pseudowires (PW) tree using LDP. Such a mechanism is suitable
for any Layer 2 VPN service requiring P2MP connectivity over an IP or
MPLS enabled PSN. A P2MP PW established via the proposed mechanism is
root initiated.
Audio/Video Transport Payloads (payload)
---------------------------------------"How to Write an RTP Payload Format", Magnus Westerlund, 2015-05-04,
<draft-ietf-payload-rtp-howto-14.txt>
This document contains information on how to best write an RTP
payload format specification. It provides reading tips, design
practices, and practical tips on how to produce an RTP payload format
specification quickly and with good results. A template is also

included with instructions.

"RTP Payload Format for Flexible Forward Error Correction (FEC)", Varun,
Ali Begen, Mo Zanaty, Giridhar Mandyam, 2016-03-21,
<draft-ietf-payload-flexible-fec-scheme-02.txt,.pdf>
This document defines new RTP payload formats for the Forward Error
Correction (FEC) packets that are generated by the non-interleaved
and interleaved parity codes from a source media encapsulated in RTP.
These parity codes are systematic codes, where a number of repair
symbols are generated from a set of source symbols. These repair
symbols are sent in a repair flow separate from the source flow that
carries the source symbols. The non-interleaved and interleaved
parity codes which are defined in this specification offer a good
protection against random and bursty packet losses, respectively, at
a cost of decent complexity. Moreover, alternate FEC codes may be
used with the payload formats presented. The RTP payload formats
that are defined in this document address the scalability issues
experienced with the earlier specifications including RFC 2733, RFC
5109 and SMPTE 2022-1, and offer several improvements. Due to these
changes, the new payload formats are not backward compatible with the
earlier specifications, but endpoints that do not implement the
scheme can still work by simply ignoring the FEC packets.
"RTP Payload for SMPTE ST 291 Ancillary Data", Thomas Edwards,
2016-03-21, <draft-ietf-payload-rtp-ancillary-03.txt>
This memo describes an RTP Payload format for SMPTE Ancillary data,
as defined by SMPTE ST 291-1. SMPTE Ancillary data is generally used
along with professional video formats to carry a range of ancillary
data types, including time code, Closed Captioning, and the Active
Format Description (AFD).
"RTP Payload Format for VP9 Video", Justin Uberti, Stefan Holmer, Magnus
Flodman, Jonathan Lennox, Danny Hong, 2016-03-21,
<draft-ietf-payload-vp9-02.txt>
This memo describes an RTP payload format for the VP9 video codec.
The payload format has wide applicability, as it supports
applications from low bit-rate peer-to-peer usage, to high bit-rate
video conferences. It includes provisions for temporal and spatial
scalability.
"RTP Payload Format for MELPe Codec", Victor Demjanenko, David
Satterlee, 2016-02-08, <draft-ietf-payload-melpe-01.txt>
This document describes the RTP payload format for the Mixed
Excitation Linear Prediction Enhanced (MELPe) speech coder. MELPe's
three different speech encoding rates and sample frames sizes are
supported. Comfort noise procedures and packet loss concealment are
detailed. Also, within the document there are included necessary
details for the use of MELP with SDP.
INTERNET DRAFT

RTP Payload Format for the MELPe Codec February 8, 2016

Path Computation Element (pce)

-----------------------------"Extensions to the Path Computation Element communication Protocol
(PCEP) for Inter-Layer MPLS and GMPLS Traffic Engineering", Eiji Oki,

Tomonori Takeda, Adrian Farrel, Fatai Zhang, 2016-04-25,

<draft-ietf-pce-inter-layer-ext-09.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.
MPLS and GMPLS networks may be constructed from layered service
networks. It is advantageous for overall network efficiency to
provide end-to-end traffic engineering across multiple network layers
through a process called inter-layer traffic engineering. PCE is a
candidate solution for such requirements.
The PCE communication Protocol (PCEP) is designed as a communication
protocol between Path Computation Clients (PCCs) and PCEs. This
document presents PCEP extensions for inter-layer traffic engineering.
"PCEP Extensions for Stateful PCE", Edward Crabbe, Ina Minei, Jan
Medved, Robert Varga, 2016-03-20, <draft-ietf-pce-stateful-pce-14.txt>
The Path Computation Element Communication Protocol (PCEP) provides
mechanisms for Path Computation Elements (PCEs) to perform path
computations in response to Path Computation Clients (PCCs) requests.
Although PCEP explicitly makes no assumptions regarding the
information available to the PCE, it also makes no provisions for PCE
control of timing and sequence of path computations within and across
PCEP sessions. This document describes a set of extensions to PCEP
to enable stateful control of MPLS-TE and GMPLS LSPs via PCEP.
"Domain Subobjects for Path Computation Element (PCE) Communication
Protocol (PCEP).", Dhruv Dhody, Udayasree Palle, Ramon Casellas,
2015-12-07, <draft-ietf-pce-pcep-domain-sequence-12.txt>
The ability to compute shortest constrained Traffic Engineering Label
Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and
Generalized MPLS (GMPLS) networks across multiple domains has been
identified as a key requirement. In this context, a domain is a
collection of network elements within a common sphere of address
management or path computational responsibility such as an Interior
Gateway Protocol (IGP) area or an Autonomous System (AS). This
document specifies a representation and encoding of a DomainSequence, which is defined as an ordered sequence of domains
traversed to reach the destination domain to be used by Path
Computation Elements (PCEs) to compute inter-domain constrained
shortest paths across a predetermined sequence of domains . This
document also defines new subobjects to be used to encode domain
identifiers.
"Extensions to the Path Computation Element Communication Protocol
(PCEP) to compute service aware Label Switched Path (LSP).", Dhruv
Dhody, Qin Wu, Vishwas Manral, Zafar Ali, Kenji Kumaki, 2016-03-17,
<draft-ietf-pce-pcep-service-aware-09.txt>
In certain networks, such as, but not limited to, financial
information networks (e.g. stock market data providers), network
performance criteria (e.g. latency) are becoming as critical to data
path selection as other metrics and constraints. These metrics are
associated with the Service Level Agreement (SLA) between customers
and service providers. The Link Bandwidth Utilization (the total

bandwidth of a link in current use for the forwarding) is another

important factor to consider during path computation.
IGP Traffic Engineering (TE) Metric extensions describes mechanisms
with which network performance information is distributed via OSPF
and IS-IS respectively. The Path Computation Element Communication
Protocol (PCEP) provides mechanisms for Path Computation Elements
(PCEs) to perform path computations in response to Path Computation
Clients (PCCs) requests. This document describes the extension to
PCEP to carry Latency, Latency Variation, Packet Loss, and Link
Bandwidth Utilization as constraints for end to end path computation.
"PCEP Extension for WSON Routing and Wavelength Assignment", Young Lee,
Ramon Casellas, 2016-02-11, <draft-ietf-pce-wson-rwa-ext-04.txt>
This document provides the Path Computation Element communication
Protocol (PCEP) extensions for the support of Routing and Wavelength
Assignment (RWA) in Wavelength Switched Optical Networks (WSON).
Lightpath provisioning in WSONs requires a routing and wavelength
assignment (RWA) process. From a path computation perspective,
wavelength assignment is the process of determining which wavelength
can be used on each hop of a path and forms an additional routing
constraint to optical light path computation.
"Secure Transport for PCEP", Diego Lopez, Oscar Gonzalez de Dios, Wenson
Wu, Dhruv Dhody, 2016-03-08, <draft-ietf-pce-pceps-09.txt>
The Path Computation Element Communication Protocol (PCEP) defines
the mechanisms for the communication between a Path Computation
Client (PCC) and a Path Computation Element (PCE), or among PCEs.
This document describe the usage of Transport Layer Security (TLS) to
enhance PCEP security, hence the PCEPS acronym proposed for it. The
additional security mechanisms are provided by the transport protocol
supporting PCEP, and therefore they do not affect the flexibility and
extensibility of PCEP.
"Optimizations of Label Switched Path State Synchronization Procedures
for a Stateful PCE", Edward Crabbe, Ina Minei, Jan Medved, Robert Varga,
Xian Zhang, Dhruv Dhody, 2016-04-27,
<draft-ietf-pce-stateful-sync-optimizations-05.txt>
A stateful Path Computation Element (PCE) has access to not only the
information disseminated by the network's Interior Gateway Protocol
(IGP), but also the set of active paths and their reserved resources
for its computation. The additional Label Switched Path (LSP) state
information allows the PCE to compute constrained paths while
considering individual LSPs and their interactions. This requires a
reliable state synchronization mechanism between the PCE and the
network, PCE and path computation clients (PCCs), and between
cooperating PCEs. The basic mechanism for state synchronization is
part of the stateful PCE specification. This draft presents
motivations for optimizations to the base state synchronization
procedure and specifies the required Path Computation Element
Communication Protocol (PCEP) extensions.
"Path Computation Element Communication Protocol (PCEP) Extensions for
remote-initiated GMPLS LSP Setup", Zafar Ali, Siva Sivabalan, Clarence
Filsfils, Robert Varga, Victor Lopez, Oscar Gonzalez de Dios, Xian
Zhang, 2016-03-21, <draft-ietf-pce-remote-initiated-gmpls-lsp-02.txt>

Draft [I-D. draft-ietf-pce-pce-initiated-lsp] specifies procedures

that can be used for creation and deletion of PCE-initiated LSPs in
the active stateful PCE model. However, this specification focuses
on MPLS networks, and does not cover remote instantiation of paths
in GMPLS-controlled networks. This document complements [I-D.
draft-ietf-pce-pce-initiated-lsp] by addressing the requirements
for remote-initiated GMPLS LSPs.
"PCEP Extensions for Segment Routing", Siva Sivabalan, Jan Medved,
Clarence Filsfils, Edward Crabbe, Victor Lopez, Jeff Tantsura, Wim
Henderickx, Jonathan Hardwick, 2016-03-21,
<draft-ietf-pce-segment-routing-07.txt>
Segment Routing (SR) enables any head-end node to select any path
without relying on a hop-by-hop signaling technique (e.g., LDP or
RSVP-TE). It depends only on "segments" that are advertised by LinkState Interior Gateway Protocols (IGPs). 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). This document specifies extensions to the Path
Computation Element Protocol (PCEP) that allow a stateful PCE to
compute and initiate Traffic Engineering (TE) paths, as well as a PCC
to request a path subject to certain constraint(s) and optimization
criteria in SR networks.
"Update to Include Route Object (IRO) specification in Path Computation
Element communication Protocol (PCEP)", Dhruv Dhody, 2016-04-21,
<draft-ietf-pce-iro-update-07.txt>
The Path Computation Element Communication Protocol (PCEP) provides
for communications between a Path Computation Client (PCC) and a PCE,
or between two PCEs. RFC 5440 defines the Include Route Object (IRO)
to specify network elements to be traversed in the computed path.
The specification did not specify if the IRO contains an ordered or
un-ordered list of sub-objects. During recent discussions, it was
determined that there was a need to define a standard representation
to ensure interoperability. It was also noted that there is a
benefit in handling of an attribute of the IRO's sub-object, the
Loose hop bit (L bit).
This document updates RFC 5440 regarding the IRO specification.
"PCEP Extensions for Establishing Relationships Between Sets of LSPs",
Ina Minei, Edward Crabbe, Siva Sivabalan, Hariharan Ananthakrishnan,
Xian Zhang, Yosuke Tanaka, 2015-11-26,
<draft-ietf-pce-association-group-00.txt>
This document introduces a generic mechanism to create a grouping of
LSPs in the context of a PCE. This grouping can then be used to
define associations between sets of LSPs or between a set of LSPs and
a set of attributes (such as configuration parameters or behaviors),
and is equally applicable to the active and passive modes of a
stateful PCE as well as a stateless PCE.
Port Control Protocol (pcp)
--------------------------"PCP Third Party ID Option", Andreas Ripke, Rolf Winter, Thomas Dietz,
Juergen Quittek, Rafael Silva, 2016-03-09,
<draft-ietf-pcp-third-party-id-option-08.txt>

This document describes a new Port Control Protocol (PCP) option

called THIRD_PARTY_ID option. It is designed to be used together
with the THIRD_PARTY option specified in RFC 6887.
The THIRD_PARTY_ID
situations where a
THIRD_PARTY option
requested mappings

option serves to identify a third party in

third party's IP address contained in the
does not provide sufficient information to create
in a PCP-controlled device.

Protocols for IP Multicast (pim)

-------------------------------"Explicit RPF Vector", Javed Asghar, IJsbrand Wijnands, Sowmya
Krishnaswamy, Apoorva Karan, Vishal Arya, 2016-04-26,
<draft-ietf-pim-explicit-rpf-vector-09.txt>
The PIM Reverse Path Forwarding (RPF) Vector TLV defined in RFC 5496
can be included in a PIM Join Attribute such that the RPF neighbor is
selected based on the unicast reachability of the RPF Vector instead
of the Source or Randezvous Point associated with the multicast tree.
This document defines a new RPF Vector Attribute type such that an
explicit RPF neighbor list can be encoded in the PIM Join Attribute,
bypassing the unicast route lookup.
"Hierarchical Join/Prune Attributes", Stig Venaas, Jesus Arango, Isidor
Kouvelas, 2016-04-25, <draft-ietf-pim-hierarchicaljoinattr-08.txt>
This document defines a hierachical method of encoding Join
attributes, providing a more efficient encoding when the same
attribute values need to be specified for multiple sources in a PIM
Join/Prune message. This document updates RFC 5384 by renaming the
Encoding Type registry specified there.
"PIM flooding mechanism and source discovery", IJsbrand Wijnands, Stig
Venaas, Michael Brig, Anders Jonasson, 2016-03-17,
<draft-ietf-pim-source-discovery-bsr-04.txt>
PIM Sparse-Mode uses a Rendezvous Point and shared trees to forward
multicast packets from new sources. Once last hop routers receive
packets from a new source, they may join the Shortest Path Tree for
the source for optimal forwarding. This draft defines a new protcol
that provides a way to support PIM Sparse Mode (SM) without the need
for PIM registers, RPs or shared trees. Multicast source information
is flooded throughout the multicast domain using a new generic PIM
flooding mechanism. This allows last hop routers to learn about new
sources without receiving initial data packets.
"A YANG data model for Protocol-Independent Multicast (PIM)", Xufeng
Liu, Pete McAllister, Anish Peter, 2016-02-10,
<draft-ietf-pim-yang-00.txt>
This document defines a YANG data model that can be used to configure
Protocol Independent Multicast (PIM) devices.
"PIM DR Improvement", Zheng Zhang, fangwei hu, BenChong Xu, 2016-03-02,
<draft-ietf-pim-dr-improvement-00.txt>
PIM is worldly deployed multicast protocol. This document will

improve the stability of PIM protocol, decrease the lost of multicast

packets when the PIM DR (Designed Router) is down.
Peer to Peer Streaming Protocol (ppsp)
-------------------------------------"PPSP Tracker Protocol-Base Protocol (PPSP-TP/1.0)", Rui Cruz, Mario
Nunes, Gu Yingjie, Jinwei Xia, Rachel Huang, Joao Taveira, Deng Lingli,
2015-12-30, <draft-ietf-ppsp-base-tracker-protocol-12.txt>
This document specifies the base Peer-to-Peer Streaming ProtocolTracker Protocol (PPSP-TP/1.0), an application-layer control
(signaling) protocol for the exchange of meta information between
trackers and peers. The specification outlines the architecture of
the protocol and its functionality, and describes message flows,
message processing instructions, message formats, formal syntax and
semantics. The PPSP Tracker Protocol enables cooperating peers to
form content streaming overlay networks to support near real-time
Structured Media content delivery (audio, video, associated timed
text and metadata), such as adaptive multi-rate, layered (scalable)
and multi-view (3D) videos, in live, time-shifted and on-demand
modes.
Preparation and Comparison of Internationalized Strings (precis)
---------------------------------------------------------------"Preparation, Enforcement, and Comparison of Internationalized Strings
Representing Nicknames", Peter Saint-Andre, 2016-05-05,
<draft-ietf-precis-7700bis-01.txt>
This document describes methods for handling Unicode strings
representing memorable, human-friendly names (called "nicknames",
"display names", or "petnames") for people, devices, accounts,
websites, and other entities. This document obsoletes RFC 7700.
"Preparation, Enforcement, and Comparison of Internationalized Strings
Representing Usernames and Passwords", Peter Saint-Andre, Alexey
Melnikov, 2016-05-05, <draft-ietf-precis-7613bis-01.txt>
This document describes updated methods for handling Unicode strings
representing usernames and passwords. The previous approach was
known as SASLprep (RFC 4013) and was based on stringprep (RFC 3454).
The methods specified in this document provide a more sustainable
approach to the handling of internationalized usernames and
passwords. The preparation, enforcement, and comparison of
internationalized strings (PRECIS) framework, RFC 7564, obsoletes RFC
3454, and this document obsoletes RFC 7613.
"PRECIS Framework: Preparation, Enforcement, and Comparison of
Internationalized Strings in Application Protocols", Peter Saint-Andre,
Marc Blanchet, 2016-05-05, <draft-ietf-precis-7564bis-01.txt>
Application protocols using Unicode characters in protocol strings
need to properly handle such strings in order to enforce
internationalization rules for strings placed in various protocol
slots (such as addresses and identifiers) and to perform valid
comparison operations (e.g., for purposes of authentication or
authorization). This document defines a framework enabling
application protocols to perform the preparation, enforcement, and
comparison of internationalized strings ("PRECIS") in a way that

depends on the properties of Unicode characters and thus is agile

with respect to versions of Unicode. As a result, this framework
provides a more sustainable approach to the handling of
internationalized strings than the previous framework, known as
Stringprep (RFC 3454). This document obsoletes RFC 7564.
RADIUS EXTensions (radext)
-------------------------"Larger Packets for RADIUS over TCP", Sam Hartman, 2016-04-12,
<draft-ietf-radext-bigger-packets-07.txt>
The RADIUS over TLS experiment described in RFC 6614 has opened
RADIUS to new use cases where the 4096-octet maximum size limit of
RADIUS packet proves problematic. This specification extends the
RADIUS over TCP experiment (RFC 6613) to permit larger RADIUS
packets. This specification compliments other ongoing work to permit
fragmentation of RADIUS authorization information. This document
registers a new RADIUS code, an action which requires IESG approval.
"RADIUS Extensions for IP Port Configuration and Reporting", Dean Cheng,
Jouni Korhonen, Mohamed Boucadair, Senthil Sivakumar, 2016-03-17,
<draft-ietf-radext-ip-port-radius-ext-09.txt>
This document defines three new RADIUS attributes. For devices that
implementing IP port ranges, these attributes are used to communicate
with a RADIUS server in order to configure and report TCP/UDP ports
and ICMP identifiers, as well as mapping behavior for specific hosts.
This mechanism can be used in various deployment scenarios such as
Carrier-Grade NAT, IPv4/IPv6 translators, Provider WLAN Gateway, etc.
"Data Types in the Remote Authentication Dial-In User Service Protocol
(RADIUS)", Alan DeKok, 2016-05-06, <draft-ietf-radext-datatypes-03.txt>
RADIUS specifications have used data types for two decades without
defining them as managed entities. During this time, RADIUS
implementations have named the data types, and have used them in
attribute definitions. This document updates the specifications to
better follow established practice. We do this by naming the data
types defined in RFC 6158, which have been used since at least RFC
2865. We provide an IANA registry for the data types, and update the
RADIUS Attribute Type registry to include a "Data Type" field for
each attribute. Finally, we recommend that authors of RADIUS
specifications use these types in preference to existing practice.
"Dynamic Authorization Proxying in Remote Authorization Dial-In User
Service Protocol (RADIUS)", Alan DeKok, Jouni Korhonen, 2016-01-11,
<draft-ietf-radext-coa-proxy-00.txt>
RFC 5176 defines Change of Authorization (CoA) and Disconnect Message
(DM) behavior for RADIUS. Section 3.1 of that document suggests that
proxying these messages is possible, but gives no guidance as to how
that is done. This specification corrects that omission.
"Considerations regarding the correct use of EAP-Response/Identity",
Stefan Winter, 2016-03-21,
<draft-ietf-radext-populating-eapidentity-00.txt>
There are some subtle considerations for an EAP peer regarding the
content of the EAP-Response/Identity packet when authenticating with

EAP to an EAP server. This document describes two such

considerations and suggests workarounds to the associated problems.
Real-time Applications and Infrastructure Area (rai)
---------------------------------------------------"Considerations for Information Services and Operator Services Using
SIP", John Haluska, Richard Ahern, Marty Cruze, Chris Blackwell,
2011-08-15, <draft-haluska-sipping-directory-assistance-11.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.
Registration Protocols Extensions (regext)
-----------------------------------------"Key Relay Mapping for the Extensible Provisioning Protocol", M.
Groeneweg, Antoin Verschuren, rikribbers, 2015-12-07,
<draft-ietf-eppext-keyrelay-11.txt>
This document describes an Extensible Provisioning Protocol (EPP)
mapping for a key relay object that relays DNSSEC key material
between EPP clients using the poll queue defined in RFC5730.
This key relay mapping will help facilitate changing the DNS operator
of a domain while keeping the DNSSEC chain of trust intact.
"ICANN TMCH functional specifications", Gustavo Lozano, 2016-04-22,
<draft-ietf-regext-tmch-func-spec-00.txt>

This document describes the requirements, the architecture and the

interfaces between the ICANN Trademark Clearinghouse (TMCH) and
Domain Name Registries as well as between the ICANN TMCH and Domain
Name Registrars for the provisioning and management of domain names
during Sunrise and Trademark Claims Periods.
"Launch Phase Mapping for the Extensible Provisioning Protocol (EPP)",
James Gould, Wil Tan, Gavin Brown, 2016-04-25,
<draft-ietf-regext-launchphase-00.txt>
This document describes an Extensible Provisioning Protocol (EPP)
extension mapping for the provisioning and management of domain name
registrations and applications during the launch of a domain name
registry.
"Third Party DNS operator to Registrars/Registries Protocol", Jacques
Latour, lafur Gumundsson, Paul Wouters, Matthew Pounsett, 2016-04-26,
<draft-ietf-regext-dnsoperator-to-rrr-protocol-00.txt>
There are several problems that arise in the standard
Registrant/Registrar/Registry model when the operator of a zone is
neither the Registrant nor the Registrar for the delegation.
Historically the issues have been minor, and limited to difficulty
guiding the Registrant through the initial changes to the NS records
for the delegation. As this is usually a one time activity when the
operator first takes charge of the zone it has not been treated as a
serious issue.
When the domain on the other hand uses DNSSEC it necessary for the
Registrant in this situation to make regular (sometimes annual)
changes to the delegation in order to track KSK rollover, by updating
the delegation's DS record(s). Under the current model this is prone
to Registrant error and significant delays. Even when the Registrant
has outsourced the operation of DNS to a third party the registrant
still has to be in the loop to update the DS record.
There is a need for a simple protocol that allows a third party DNS
operator to update DS and NS records in a trusted manner for a
delegation without involving the registrant for each operation.
The protocol described in this draft is REST based, and when used
through an authenticated channel can be used to establish the DNSSEC
Initial Trust (to turn on DNSSEC or bootstrap DNSSEC). Once DNSSEC
trust is established this channel can be used to trigger maintenance
of delegation records such as DS, NS, and glue records. The protocol
is kept as simple as possible.
RTP Media Congestion Avoidance Techniques (rmcat)
------------------------------------------------"Congestion Control Requirements for Interactive Real-Time Media",
Randell Jesup, Zaheduzzaman Sarker, 2014-12-12,
<draft-ietf-rmcat-cc-requirements-09.txt>
Congestion control is needed for all data transported across the
Internet, in order to promote fair usage and prevent congestion
collapse. The requirements for interactive, point-to-point real-time
multimedia, which needs low-delay, semi-reliable data delivery, are
different from the requirements for bulk transfer like FTP or bursty
transfers like Web pages. Due to an increasing amount of RTP-based

real-time media traffic on the Internet (e.g. with the introduction

of the Web Real-Time Communication (WebRTC)), it is especially
important to ensure that this kind of traffic is congestion
controlled.
This document describes a set of requirements that can be used to
evaluate other congestion control mechanisms in order to figure out
their fitness for this purpose, and in particular to provide a set of
possible requirements for real-time media congestion avoidance
technique.
"Evaluating Congestion Control for Interactive Real-time Media", Varun,
Joerg Ott, Stefan Holmer, 2016-03-21,
<draft-ietf-rmcat-eval-criteria-05.txt,.pdf>
The Real-time Transport Protocol (RTP) is used to transmit media in
telephony and video conferencing applications. This document
describes the guidelines to evaluate new congestion control
algorithms for interactive point-to-point real-time media.
"Test Cases for Evaluating RMCAT Proposals", Zaheduzzaman Sarker, Varun,
Xiaoqing Zhu, Michael Ramalho, 2016-03-10,
<draft-ietf-rmcat-eval-test-03.txt>
The Real-time Transport Protocol (RTP) is used to transmit media in
multimedia telephony applications, these applications are typically
required to implement congestion control. This document describes
the test cases to be used in the performance evaluation of such
congestion control algorithms.
"NADA: A Unified Congestion Control Scheme for Real-Time Media",
Xiaoqing Zhu, Rong Pan, Michael Ramalho, Sergio de la Cruz, Paul Jones,
Jian Fu, Stefano D'Aronco, Charles Ganzhorn, 2016-03-18,
<draft-ietf-rmcat-nada-02.txt>
This document describes NADA (network-assisted dynamic adaptation), a
novel congestion control scheme for interactive real-time media
applications, such as video conferencing. In the proposed scheme,
the sender regulates its sending rate based on either implicit or
explicit congestion signaling, in a unified approach. The scheme can
benefit from explicit congestion notification (ECN) markings from
network nodes. It also maintains consistent sender behavior in the
absence of such markings, by reacting to queuing delays and packet
losses instead.
"Self-Clocked Rate Adaptation for Multimedia", Ingemar Johansson,
Zaheduzzaman Sarker, 2016-02-08, <draft-ietf-rmcat-scream-cc-03.txt>
This memo describes a rate adaptation algorithm for conversational
media services such as video. The solution conforms to the packet
conservation principle and uses a hybrid loss and delay based
congestion control algorithm. The algorithm is evaluated over both
simulated Internet bottleneck scenarios as well as in a LTE (Long
Term Evolution) system simulator and is shown to achieve both low
latency and high video throughput in these scenarios.
"Shared Bottleneck Detection for Coupled Congestion Control for RTP
Media.", David Hayes, Simone Ferlin, Michael Welzl, Kristian Hiorth,
2016-03-21, <draft-ietf-rmcat-sbd-04.txt>

This document describes a mechanism to detect whether end-to-end data

flows share a common bottleneck. It relies on summary statistics
that are calculated by a data receiver based on continuous
measurements and regularly fed to a grouping algorithm that runs
wherever the knowledge is needed. This mechanism complements the
coupled congestion control mechanism in draft-ietf-rmcat-coupled-cc.
"Evaluation Test Cases for Interactive Real-Time Media over Wireless
Networks", Zaheduzzaman Sarker, Ingemar Johansson, Xiaoqing Zhu, Jian
Fu, Wei-Tian Tan, Michael Ramalho, 2015-11-05,
<draft-ietf-rmcat-wireless-tests-01.txt>
It is evident that to ensure seamless and robust user experience
across all type of access networks multimedia communication suits
should adapt to the changing network conditions. There is an ongoing
effort in IETF RMCAT working group to standardize rate adaptive
algorithm(s) to be used in the real-time interactive communication.
In this document test cases are described to evaluate the
performances of the proposed endpoint adaptation solutions in LTE
networks and Wi-Fi networks. The proposed algorithms should be
evaluated using the test cases defined in this document to select
most optimal solutions.
"Coupled congestion control for RTP media", Safiqul Islam, Michael
Welzl, Stein Gjessing, 2016-04-14, <draft-ietf-rmcat-coupled-cc-02.txt>
When multiple congestion controlled RTP sessions traverse the same
network bottleneck, it can be beneficial to combine their controls
such that the total on-the-wire behavior is improved. This document
describes such a method for flows that have the same sender, in a way
that is as flexible and simple as possible while minimizing the
amount of changes needed to existing RTP applications. It specifies
how to apply the method for both the NADA and Google congestion
control algorithms.
"Congestion Control and Codec interactions in RTP Applications", Mo
Zanaty, Varun Singh, Suhas Nandakumar, Zaheduzzaman Sarker, 2016-03-18,
<draft-ietf-rmcat-cc-codec-interactions-02.txt>
Interactive real-time media applications that use the Real-time
Transport Protocol (RTP) over the User Datagram Protocol (UDP) must
use congestion control techniques above the UDP layer since it
provides none. This memo describes the interactions and conceptual
interfaces necessary between the application components that relate
to congestion control, specifically the media codec control layer,
and the components dedicated to congestion control functions.
"Modeling Video Traffic Sources for RMCAT Evaluations", Xiaoqing Zhu,
Sergio de la Cruz, Zaheduzzaman Sarker, 2016-01-15,
<draft-ietf-rmcat-video-traffic-model-00.txt>
This document describes two reference video traffic source models for
evaluating RMCAT candidate algorithms. The first model statistically
characterizes the behavior of a live video encoder in response to
changing requests on target video rate. The second model is tracedriven, and emulates the encoder output by scaling the pre-encoded
video frame sizes from a widely used video test sequence. Both
models are designed to strike a balance between simplicity,
repeatability, and authenticity in modeling the interactions between
a video traffic source and the congestion control module.

Routing Over Low power and Lossy networks (roll)

-----------------------------------------------"Applicability Statement for the Routing Protocol for Low Power and
Lossy Networks (RPL) in AMI Networks", Nancy Cam-Winget, Jonathan Hui,
Daniel Popa, 2016-04-25, <draft-ietf-roll-applicability-ami-13.txt>
This document discusses the applicability of RPL in Advanced Metering
Infrastructure (AMI) networks.
"ROLL Applicability Statement Template", Michael Richardson, 2016-05-03,
<draft-ietf-roll-applicability-template-09.txt>
This document is a template applicability statement for the Routing
over Low-power and Lossy Networks (ROLL) WG. This document is not
for publication, but rather is to be used as a template.
"When to use RFC 6553, 6554 and IPv6-in-IPv6", Ines Robles, Michael
Richardson, Pascal Thubert, 2016-04-05,
<draft-ietf-roll-useofrplinfo-04.txt>
This document looks at different data flows through LLN networks
where RPL is used to establish routing. The document enumerates the
cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 encapsulation is
required. This analysis provides the basis on which to design
efficient compression of these headers.
"6LoWPAN Routing Header", Pascal Thubert, Carsten Bormann, Laurent
Toutain, Robert Cragie, 2016-03-21,
<draft-ietf-roll-routing-dispatch-00.txt>
This specification introduces a new 6LoWPAN dispatch type for use in
6LoWPAN Route-Over topologies, that initially covers the needs of RPL
(RFC6550) data packets compression. Using this dispatch type, this
specification defines a method to compress RPL Option (RFC6553)
information and Routing Header type 3 (RFC6554), an efficient IP-inIP technique and is extensible for more applications.
Real-Time Communication in WEB-browsers (rtcweb)
-----------------------------------------------"Overview: Real Time Protocols for Browser-based Applications", Harald
Alvestrand, 2016-01-21, <draft-ietf-rtcweb-overview-15.txt>
This document gives an overview and context of a protocol suite
intended for use with real-time applications that can be deployed in
browsers - "real time communication on the Web".
It intends to serve as a starting and coordination point to make sure
all the parts that are needed to achieve this goal are findable, and
that the parts that belong in the Internet protocol suite are fully
specified and on the right publication track.
This document is an Applicability Statement - it does not itself
specify any protocol, but specifies which other specifications WebRTC
compliant implementations are supposed to follow.
This document is a work item of the RTCWEB working group.

"Web Real-Time Communication (WebRTC): Media Transport and Use of RTP",

Colin Perkins, Magnus Westerlund, Joerg Ott, 2016-03-17,
<draft-ietf-rtcweb-rtp-usage-26.txt>
The Web Real-Time Communication (WebRTC) framework provides support
for direct interactive rich communication using audio, video, text,
collaboration, games, etc. between two peers' web-browsers. This
memo describes the media transport aspects of the WebRTC framework.
It specifies how the Real-time Transport Protocol (RTP) is used in
the WebRTC context, and gives requirements for which RTP features,
profiles, and extensions need to be supported.
"Javascript Session Establishment Protocol", Justin Uberti, Cullen
Jennings, Eric Rescorla, 2016-03-21, <draft-ietf-rtcweb-jsep-14.txt>
This document describes the mechanisms for allowing a Javascript
application to control the signaling plane of a multimedia session
via the interface specified in the W3C RTCPeerConnection API, and
discusses how this relates to existing signaling protocols.
"WebRTC Data Channels", Randell Jesup, Salvatore Loreto, Michael Tuexen,
2015-01-04, <draft-ietf-rtcweb-data-channel-13.txt>
The WebRTC framework specifies protocol support for direct
interactive rich communication using audio, video, and data between
two peers' web-browsers. This document specifies the non-media data
transport aspects of the WebRTC framework. It provides an
architectural overview of how the Stream Control Transmission
Protocol (SCTP) is used in the WebRTC context as a generic transport
service allowing WEB-browsers to exchange generic data from peer to
peer.
"WebRTC Audio Codec and Processing Requirements", Jean-Marc Valin, Cary
Bran, 2016-04-21, <draft-ietf-rtcweb-audio-11.txt>
This document outlines the audio codec and processing requirements
for WebRTC endpoints.
"WebRTC Data Channel Establishment Protocol", Randell Jesup, Salvatore
Loreto, Michael Tuexen, 2015-01-04,
<draft-ietf-rtcweb-data-protocol-09.txt>
The WebRTC framework specifies protocol support for direct
interactive rich communication using audio, video, and data between
two peers' web-browsers. This document specifies a simple protocol
for establishing symmetric Data Channels between the peers. It uses
a two way handshake and allows sending of user data without waiting
for the handshake to complete.
"Transports for WebRTC", Harald Alvestrand, 2016-03-21,
<draft-ietf-rtcweb-transports-12.txt>
This document describes the data transport protocols used by WebRTC,
including the protocols used for interaction with intermediate boxes
such as firewalls, relays and NAT boxes.
"Application Layer Protocol Negotiation for Web Real-Time Communications
(WebRTC)", Martin Thomson, 2016-05-05, <draft-ietf-rtcweb-alpn-04.txt>
This document specifies two Application Layer Protocol Negotiation

(ALPN) labels for use with Web Real-Time Communications (WebRTC).

The "webrtc" label identifies regular WebRTC communications: a DTLS
session that is used establish keys for Secure Real-time Transport
Protocol (SRTP) or to establish data channels using SCTP over DTLS.
The "c-webrtc" label describes the same protocol, but the peers also
agree to maintain the confidentiality of the media by not sharing it
with other applications.
"Additional WebRTC audio codecs for interoperability.", Stephane Proust,
2016-04-22, <draft-ietf-rtcweb-audio-codecs-for-interop-06.txt>
To ensure a baseline level of interoperability between WebRTC
endpoints, a minimum set of required codecs is specified. However,
to maximize the possibility to establish the session without the need
for audio transcoding, it is also recommended to include in the offer
other suitable audio codecs that are available to the browser.
This document provides some guidelines on the suitable codecs to be
considered for WebRTC endpoints to address the most relevant
interoperability use cases.
"WebRTC Forward Error Correction Requirements", Justin Uberti,
2016-03-20, <draft-ietf-rtcweb-fec-03.txt>
This document provides information and requirements for how Forward
Error Correction (FEC) should be used by WebRTC applications.
"Recursively Encapsulated TURN (RETURN) for Connectivity and Privacy in
WebRTC", Benjamin Schwartz, Justin Uberti, 2016-01-26,
<draft-ietf-rtcweb-return-01.txt>
In the context of WebRTC, the concept of a local TURN proxy has been
suggested, but not reviewed in detail. WebRTC applications are
already using TURN to enhance connectivity and privacy. This
document explains how local TURN proxies and WebRTC applications can
work together.
"WebRTC Gateways", Harald Alvestrand, Uwe Rauschenbach, 2016-01-21,
<draft-ietf-rtcweb-gateways-02.txt>
This document describes interoperability considerations for a class
of WebRTC-compatible endpoints called "WebRTC gateways", which
interconnect between WebRTC endpoints and devices that are not WebRTC
endpoints.
"SDP for the WebRTC", Suhas Nandakumar, Cullen Jennings, 2016-03-18,
<draft-ietf-rtcweb-sdp-01.txt>
The Web Real-Time Communication [WebRTC] working group is charged to
provide protocol support for direct interactive rich communication
using audio, video and data between two peers' web browsers. With in
the WebRTC framework, Session Description protocol (SDP) [RFC4566] is
used for negotiating session capabilities between the peers. Such a
negotiation happens based on the SDP Offer/Answer exchange mechanism
described in [RFC3264].
This document provides an informational reference in describing the
role of SDP and the Offer/Answer exchange mechanism for the most
common WebRTC use-cases.

This SDP examples provided in this document is still a work in

progress, but it aims to align closest to the evolving standards
work.
"WebRTC IP Address Handling Recommendations", Justin Uberti, Guo-wei
Shieh, 2016-03-20, <draft-ietf-rtcweb-ip-handling-01.txt>
This document provides best practices for how IP addresses should be
handled by WebRTC applications.
Routing Area (rtg)
-----------------"A Record of Discussions of Graceful Restart Extensions for
Bidirectional Forwarding Detection (BFD)", Palanivelan Appanasamy,
2011-11-17, <draft-palanivelan-bfd-v2-gr-13.txt>
This document is a historical record of discussions about extending
the Bidirectional Forwarding Detection (BFD) protocol to provide
additional capabilities to handle Graceful Restart.
These discussions took place in the context of the IETF's BFD working
group, and the consensus in that group was that these extensions
should not be made.
This document presents a summary of the challenges to BFD in
surviving a graceful restart, and outlines a potential protocol
solution that was discussed and rejected within the BFD working
group. The purpose of this document is to provide a record of the
work done so that future effort will not be wasted. This document
does not propose or document any extensions to BFD, and there is no
intention that it should be implemented in its current form.
"ForCES Inter-FE LFB", Damascane Joachimpillai, Jamal Hadi Salim,
2016-04-26, <draft-ietf-forces-interfelfb-04.txt>
This document describes how to extend the ForCES LFB topology across
FEs by defining the Inter-FE LFB Class. The Inter-FE LFB Class
provides the ability to pass data and metadata across FEs without
needing any changes to the ForCES specification. The document
focuses on Ethernet transport.
Routing Area Working Group (rtgwg)
---------------------------------"IP MIB for IP Fast-Reroute", Alia Atlas, Kiran Koushik, Stephane
Litkowski, 2016-02-09, <draft-ietf-rtgwg-ipfrr-ip-mib-08.txt>
This draft 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 relevant for IP routes
using IP Fast-Reroute [RFC5714]
"An Architecture for IP/LDP Fast-Reroute Using Maximally Redundant
Trees", Alia Atlas, Chris Bowers, Gabor Envedi, 2016-02-05,
<draft-ietf-rtgwg-mrt-frr-architecture-10.txt>
This document defines the architecture for IP and LDP Fast-Reroute
using Maximally Redundant Trees (MRT-FRR). MRT-FRR is a technology
that gives link-protection and node-protection with 100% coverage in

any network topology that is still connected after the failure.

"Operational management of Loop Free Alternates", Stephane Litkowski,
Bruno Decraene, Clarence Filsfils, Kamran Raza, Martin Horneffer,
2015-06-25, <draft-ietf-rtgwg-lfa-manageability-11.txt>
Loop Free Alternates (LFA), as defined in RFC 5286 is an IP Fast
ReRoute (IP FRR) mechanism enabling traffic protection for IP traffic
(and MPLS LDP traffic by extension). Following first deployment
experiences, this document provides operational feedback on LFA,
highlights some limitations, and proposes a set of refinements to
address those limitations. It also proposes required management
specifications.
This proposal is also applicable to remote LFA solution.
"An Algorithm for Computing Maximally Redundant Trees for IP/LDP
Fast-Reroute", Gabor Envedi, Andras Csaszar, Alia Atlas, Chris Bowers,
Abishek Gopalan, 2016-02-16, <draft-ietf-rtgwg-mrt-frr-algorithm-09.txt>
A solution for IP and LDP Fast-Reroute using Maximally Redundant
Trees is presented in draft-ietf-rtgwg-mrt-frr-architecture. This
document defines the associated MRT Lowpoint algorithm that is used
in the Default MRT profile to compute both the necessary Maximally
Redundant Trees with their associated next-hops and the alternates to
select for MRT-FRR.
"Remote-LFA Node Protection and Manageability", Shraddha Hegde, Chris
Bowers, Hannes Gredler, Stephane Litkowski, 2015-12-10,
<draft-ietf-rtgwg-rlfa-node-protection-05.txt,.pdf>
The loop-free alternates computed following the current Remote-LFA
specification guarantees only link-protection. The resulting RemoteLFA nexthops (also called PQ-nodes), may not guarantee nodeprotection for all destinations being protected by it.
This document describes procedures for determining if a given PQ-node
provides node-protection for a specific destination or not. The
document also shows how the same procedure can be utilised for
collection of complete characteristics for alternate paths.
Knowledge about the characteristics of all alternate path is
precursory to apply operator defined policy for eliminating paths not
fitting constraints.
"Use of BGP for routing in large-scale data centers", Petr Lapukhov,
Ariff Premji, Jon Mitchell, 2016-04-27,
<draft-ietf-rtgwg-bgp-routing-large-dc-10.txt>
Some network operators build and operate data centers that support
over one hundred thousand servers. In this document, such data
centers are referred to as "large-scale" to differentiate them from
smaller infrastructures. Environments of this scale have a unique
set of network requirements with an emphasis on operational
simplicity and network stability. This document summarizes
operational experience in designing and operating large-scale data
centers using BGP as the only routing protocol. The intent is to
report on a proven and stable routing design that could be leveraged
by others in the industry.
"SPF Back-off algorithm for link state IGPs", Bruno Decraene, Stephane

Litkowski, Hannes Gredler, Acee Lindem, P. Francois, 2015-12-17,

<draft-ietf-rtgwg-backoff-algo-02.txt>
This document defines a standard algorithm to back-off link-state IGP
SPF computations.
Having one standard algorithm improves interoperability by reducing
the probability and/or duration of transient forwarding loops during
the IGP convergence when the IGP reacts to multiple proximate IGP
events.
"Link State protocols SPF trigger and delay algorithm impact on IGP
micro-loops", Stephane Litkowski, Bruno Decraene, Martin Horneffer,
2015-12-14, <draft-ietf-rtgwg-spf-uloop-pb-statement-02.txt>
A micro-loop is a packet forwarding loop that may occur transiently
among two or more routers in a hop-by-hop packet forwarding paradigm.
In this document, we are trying to analyze the impact of using
different Link State IGP implementations in a single network in
regards of micro-loops. The analysis is focused on the SPF triggers
and SPF delay algorithm.
"Encapsulation Considerations", Erik Nordmark, Albert Tian, Jesse Gross,
Jon Hudson, Lawrence Kreeger, Pankaj Garg, Patricia Thaler, Tom Herbert,
2016-03-21, <draft-ietf-rtgwg-dt-encap-01.txt>
The IETF Routing Area director has chartered a design team to look at
common issues for the different data plane encapsulations being
discussed in the NVO3 and SFC working groups and also in the BIER
BoF, and also to look at the relationship between such encapsulations
in the case that they might be used at the same time. The purpose of
this design team is to discover, discuss and document considerations
across the different encapsulations in the different WGs/BoFs so that
we can reduce the number of wheels that need to be reinvented in the
future.
"A YANG Data Model for Routing Information Protocol (RIP)", Xufeng Liu,
Prateek Sarda, Vikram Choudhary, 2016-02-02,
<draft-ietf-rtgwg-yang-rip-01.txt>
This document describes a data model for the Routing Information
Protocol (RIP). Both RIP version 2 and RIPng are covered.
"Routing Policy Configuration Model for Service Provider Networks",
Anees Shaikh, Rob Shakir, Kevin D'Souza, Chris Chase, 2016-04-06,
<draft-ietf-rtgwg-policy-model-01.txt>
This document defines a YANG data model for configuring and managing
routing policies in a vendor-neutral way and based on actual
operational practice. The model provides a generic policy framework
which can be augmented with protocol-specific policy configuration.
"Destination/Source Routing", David Lamparter, Anton Smirnov,
2016-05-02, <draft-ietf-rtgwg-dst-src-routing-02.txt>
This note specifies using packets' source addresses in route lookups
as additional qualifier to be used in route lookup. This applies to
IPv6 [RFC2460] in general with specific considerations for routing
protocol left for separate documents.

"Microloop prevention by introducing a local convergence delay",

Stephane Litkowski, Bruno Decraene, Clarence Filsfils, P. Francois,
2016-04-05, <draft-ietf-rtgwg-uloop-delay-01.txt>
This document describes a mechanism for link-state routing protocols
to prevent local transient forwarding loops in case of link failure.
This mechanism Proposes a two-steps convergence by introducing a
delay between the convergence of the node adjacent to the topology
change and the network wide convergence.
As this mechanism delays the IGP convergence it may only be used for
planned maintenance or when fast reroute protects the traffic between
the link failure and the IGP convergence.
The proposed mechanism will be limited to link down event in order to
keep simplicity.
Simulations using real network topologies have been performed and
show that local loops are a significant portion (>50%) of the total
forwarding loops.
"Routing Key Chain YANG Data Model", Acee Lindem, Yingzhen Qu, Derek
Yeung, Helen Chen, Jeffrey Zhang, Yi Yang, 2016-03-15,
<draft-ietf-rtgwg-yang-key-chain-02.txt>
This document describes the key chain YANG data model. A key chain
is a list of elements each containing a key, send lifetime, accept
lifetime, and algorithm. By properly overlapping the send and accept
lifetimes of multiple key chain elements, keys and algorithms may be
gracefully updated. By representing them in a YANG data model, key
distribution can be automated. Key chains are commonly used for
routing protocol authentication and other applications. In some
applications, the protocols do not use the key chain element key
directly, but rather a key derivation function is used to derive a
short-lived key from the key chain element key.
"Abstract", Ahmed Bashandy, Clarence Filsfils, Pradosh Mohapatra,
2015-12-08, <draft-ietf-rtgwg-bgp-pic-00.txt>
In the network comprising thousands of iBGP peers exchanging millions
of routes, many routes are reachable via more than one path. Given
the large scaling targets, it is desirable to restore traffic after
failure in a time period that does not depend on the number of BGP
prefixes. In this document we proposed an architecture by which
traffic can be re-routed to ECMP or pre-calculated backup paths in a
timeframe that does not depend on the number of BGP prefixes. The
objective is achieved through organizing the forwarding chains in a
hierarchical manner and sharing forwarding elements among the maximum
possible number of routes. The proposed technique achieves prefix
independent convergence while ensuring incremental deployment,
complete transparency and automation, and zero management and
provisioning effort. It is noteworthy to mention that the benefits of
BGP-PIC are hinged on the existence of more than one path whether as
ECMP or primary-backup.
Security Automation and Continuous Monitoring (sacm)
---------------------------------------------------"Secure Automation and Continuous Monitoring (SACM) Terminology", Henk

Birkholz, Jarrett Lu, Nancy Cam-Winget, 2016-03-21,

<draft-ietf-sacm-terminology-09.txt>
This memo documents terminology used in the documents produced by
SACM (Security Automation and Continuous Monitoring).
"Security Automation and Continuous Monitoring (SACM) Requirements",
Nancy Cam-Winget, Lisa Lorenzin, 2016-03-17,
<draft-ietf-sacm-requirements-13.txt>
This document defines the scope and set of requirements for the
Secure Automation and Continuous Monitoring (SACM) architecture, data
model and transport protocols. The requirements and scope are based
on the agreed upon use cases.
"SACM Information Model", D. Waltermire, Kim Watson, Clifford Kahn, Lisa
Lorenzin, Michael Cokus, Daniel Haynes, 2016-03-18,
<draft-ietf-sacm-information-model-04.txt,.pdf>
This document defines the information model for SACM.
"SACM Vulnerability Assessment Scenario", Chris Coffin, Brant Cheikes,
Charles Schmidt, Daniel Haynes, Jessica Fitzgerald-McKay, D. Waltermire,
2016-01-22, <draft-coffin-sacm-vuln-scenario-01.txt>
This document provides a core narrative that walks through an
automated enterprise vulnerability assessment scenario. It is
aligned with the SACM use cases and begins with an enterprise
ingesting vulnerability description data, followed by identifying
endpoints on the network and collecting and storing information about
them to enable posture assessment, and finally ends with assessing
these endpoints against the vulnerability description data to
determine which ones are affected. Processes that specifically
overlap between this scenario and SACM use cases will be noted where
applicable. Specifically, the relationship between this document and
the SACM use case building block capabilities and the usage scenarios
will be covered.
"Endpoint Compliance Profile", Daniel Haynes, Jessica Fitzgerald-McKay,
Lisa Lorenzin, 2016-03-07, <draft-haynes-sacm-ecp-00.txt>
This document specifies the Endpoint Compliance Profile, a high-level
specification that describes a specific combination and application
of NEA and TNC protocols and interfaces specifically designed to
support ongoing assessment of endpoint posture and the controlled
exposure of collected posture information to appropriate security
applications. This document is a subset of the Trusted Computing
Group's Endpoint Compliance Profile Version 1.0 specification.
"SWID Message and Attributes for PA-TNC", Chris Coffin, Daniel Haynes,
Charles Schmidt, Jessica Fitzgerald-McKay, 2016-03-07,
<draft-coffin-sacm-nea-swid-patnc-00.txt>
This document specifies the SWID Message and Attributes for PA-TNC.
It extends the PA-TNC specification [RFC5792] by providing specific
attributes and message exchanges to allow endpoints to report their
software inventory information to a NEA server (as described in
[RFC5209]) using SWID tags [SWID].
Source Address Validation Improvements (savi)

--------------------------------------------"SAVI for Mixed Address Assignment Methods Scenario", Jun Bi, Guang Yao,
Joel Halpern, Eric Levy-Abegnoli, 2015-11-15,
<draft-ietf-savi-mix-10.txt>
In networks that use multiple techniques for address assignment, the
appropriate Source Address Validation Improvement (SAVI) methods must
be used to prevent spoofing of addresses assigned by each such
technique. This document reviews how multiple SAVI methods can
coexist in a single SAVI device and collisions are resolved when the
same binding entry is discovered by two or more methods.
Software Defined Networking (sdnrg)
----------------------------------"Cooperating Layered Architecture for SDN", Luis Contreras, Carlos
Bernardos, Diego Lopez, Mohamed Boucadair, Paola Iovanna, 2016-03-21,
<draft-irtf-sdnrg-layered-sdn-00.txt>
Software Defined Networking proposes the separation of the control
plane from the data plane in the network nodes and its logical
centralization on a control entity. Most of the network intelligence
is moved to this functional entity. Typically, such entity is seen
as a compendium of interacting control functions in a vertical, tight
integrated fashion. The relocation of the control functions from a
number of distributed network nodes to a logical central entity
conceptually places together a number of control capabilities with
different purposes. As a consequence, the existing solutions do not
provide a clear separation between transport control and services
that relies upon transport capabilities.
This document describes a proposal named Cooperating Layered
Architecture for SDN. The idea behind that is to differentiate the
control functions associated to transport from those related to
services, in such a way that they can be provided and maintained
independently, and can follow their own evolution path.
Security Area (sec)
------------------"Domain-based signing and encryption using S/MIME", William Ottaway,
Alexey Melnikov, 2014-03-05, <draft-melnikov-smime-msa-to-mda-04.txt>
The S/MIME protocols Message Specification (RFC 5751), Cryptographic
Message Syntax (RFC 5652), S/MIME Certificate Handling (RFC 5750) and
Enhanced Security Services for S/MIME (RFC 2634) specify a consistent
way to securely send and receive MIME messages providing end to end
integrity, authentication, non-repudiation and confidentiality. This
document identifies a number of interoperability, technical,
procedural and policy related issues that may result in end-to-end
security services not being achievable. To resolve such issues, this
document profiles domain-based signing and encryption using S/MIME,
such as specifying how S/MIME signing and encryption can be applied
between a Message Submission Agent (MSA) and a Message Delivery Agent
(MDA) or between 2 Message Transfer Agents (MTA).
This document is also registering 2 URI scheme: "smtp" and "submit"
which are used for designating SMTP/SMTP Submission servers
(respectively), as well as SMTP/Submission client accounts.

Service Function Chaining (sfc)

------------------------------"Service Function Chaining Use Cases In Data Centers", Surendra,
Mudassir Tufail, Sumandra Majee, Claudiu Captari, Shunsuke Homma,
2016-01-28, <draft-ietf-sfc-dc-use-cases-04.txt>
Data center operators deploy a variety of layer 4 through layer 7
service functions in both physical and virtual form factors. Most
traffic originating, transiting, or terminating in the data center is
subject to treatment by multiple service functions.
This document describes use cases that demonstrate the applicability
of Service Function Chaining (SFC) within a data center environment
and provides SFC requirements for data center centric use cases, with
primary focus on Enterprise data centers.
"Service Function Chaining Use Cases in Mobile Networks", Walter
Haeffner, Jeffrey Napper, Martin Stiemerling, Diego Lopez, Jim Uttaro,
2016-04-13, <draft-ietf-sfc-use-case-mobility-06.txt>
This document provides some exemplary use cases for service function
chaining in mobile service provider networks. The objective of this
draft is not to cover all conceivable service chains in detail.
Rather, the intention is to localize and explain the application
domain of service chaining within mobile networks as far as it is
required to complement the problem statement [RFC7498] and
architecture framework [ietf-sfc-arch] of the working group.
Service function chains typically reside in a LAN segment which links
the mobile access network to the actual application platforms located
in the carrier's datacenters or somewhere else in the Internet.
Service function chains (SFC) ensure a fair distribution of network
resources according to agreed service policies, enhance the
performance of service delivery or take care of security and privacy.
SFCs may also include Value Added Services (VAS). Commonly, SFCs are
typical middle box based services.
General considerations and specific use cases are presented in this
document to demonstrate the different technical requirements of these
goals for service function chaining in mobile service provider
networks.
The specification of service function chaining for mobile networks
must take into account an interaction between service function chains
and the 3GPP Policy and Charging Control (PCC) environment.
"Network Service Header", Paul Quinn, Uri Elzur, 2016-03-21,
<draft-ietf-sfc-nsh-04.txt>
This draft describes a Network Service Header (NSH) inserted onto
encapsulated packets or frames to realize service function paths.
NSH also provides a mechanism for metadata exchange along the
instantiated service path. NSH is the SFC encapsulation as per SFC
Architecture [SFC-arch]
"Service Function Chaining Operation, Administration and Maintenance
Framework", Sam Aldrin, Ram (Ramki) Krishnan, Nobo Akiya, Carlos
Pignataro, Anoop Ghanwani, 2016-02-18,

<draft-ietf-sfc-oam-framework-01.txt>
This document provides reference framework for Operations,
Administration and Maintenance (OAM) for Service Function
Chaining (SFC).
"Service Function Chaining (SFC) Control Plane Components &
Requirements", Mohamed Boucadair, 2016-04-21,
<draft-ietf-sfc-control-plane-04.txt>
This document describes requirements for conveying information
between Service Function Chaining (SFC) control elements and SFC
functional elements. Also, this document identifies a set of control
interfaces to interact with SFC-aware elements to establish, maintain
or recover service function chains. This document does not specify
protocols nor extensions to existing protocols.
This document exclusively focuses on SFC deployments that are under
the responsibility of a single administrative entity. Inter-domain
considerations are out of scope.
Secure Inter-Domain Routing (sidr)
---------------------------------"Securing RPSL Objects with RPKI Signatures", kistel, Brian Haberman,
2016-03-10, <draft-ietf-sidr-rpsl-sig-10.txt>
This document describes a method to allow parties to electronically
sign Routing Policy Specification Language objects and validate such
electronic signatures. This allows relying parties to detect
accidental or malicious modifications on such objects. It also
allows parties who run Internet Routing Registries or similar
databases, but do not yet have Routing Policy System Security-based
authentication of the maintainers of certain objects, to verify that
the additions or modifications of such database objects are done by
the legitimate holder(s) of the Internet resources mentioned in those
objects. This document updates RFC 2622 and RFC 4012 to add the
signature attribute to supported RPSL objects.
"A Publication Protocol for the Resource Public Key Infrastructure
(RPKI)", Samuel Weiler, Anuja Sonalker, Rob Austein, 2016-03-21,
<draft-ietf-sidr-publication-08.txt>
This document defines a protocol for publishing Resource Public Key
Infrastructure (RPKI) objects. Even though the RPKI will have many
participants issuing certificates and creating other objects, it is
operationally useful to consolidate the publication of those objects.
This document provides the protocol for doing so.
"BGP Prefix Origin Validation State Extended Community", Pradosh
Mohapatra, Keyur Patel, John Scudder, David Ward, Randy Bush,
2015-12-14, <draft-ietf-sidr-origin-validation-signaling-08.txt>
This document defines a new BGP opaque extended community to carry
the origination AS validation state inside an autonomous system.
IBGP speakers that receive this validation state can configure local
policies allowing it to influence their decision process.
"BGPsec Protocol Specification", Matthew Lepinski, Kotikalapudi Sriram,
2016-03-16, <draft-ietf-sidr-bgpsec-protocol-15.txt>

This document describes BGPsec, an extension to the Border Gateway

Protocol (BGP) that provides security for the path of autonomous
systems through which a BGP update message passes. BGPsec is
implemented via a new optional non-transitive BGP path attribute that
carries a digital signature produced by each autonomous system that
propagates the update message.
"BGPsec Operational Considerations", Randy Bush, 2015-12-15,
<draft-ietf-sidr-bgpsec-ops-07.txt>
Deployment of the BGPsec architecture and protocols has many
operational considerations. This document attempts to collect and
present the most critical and universal. It is expected to evolve as
BGPsec is formalized and initially deployed.
"BGPsec Algorithms, Key Formats, & Signature Formats", spt, 2016-04-21,
<draft-ietf-sidr-bgpsec-algs-15.txt>
This document specifies the algorithms, algorithm parameters,
asymmetric key formats, asymmetric key size and signature format used
in BGPsec (Border Gateway Protocol Security). This document updates
the Profile for Algorithms and Key Sizes for Use in the Resource
Public Key Infrastructure (ID.sidr-rfc6485bis).
"A Profile for BGPsec Router Certificates, Certificate Revocation Lists,
and Certification Requests", Mark Reynolds, spt, Stephen Kent,
2016-03-21, <draft-ietf-sidr-bgpsec-pki-profiles-16.txt>
This document defines a standard profile for X.509 certificates used
to enable validation of Autonomous System (AS) paths in the Border
Gateway Protocol (BGP), as part of an extension to that protocol
known as BGPsec. BGP is the standard for inter-domain routing in the
Internet; it is the "glue" that holds the Internet together. BGPsec
is being developed as one component of a solution that addresses the
requirement to provide security for BGP. The goal of BGPsec is to
provide full AS path validation based on the use of strong
cryptographic primitives. The end-entity (EE) certificates specified
by this profile are issued (to routers within an Autonomous System).
Each of these certificates is issued under a Resource Public Key
Infrastructure (RPKI) Certification Authority (CA) certificate.
These CA certificates and EE certificates both contain the AS
Identifier Delegation extension. An EE certificate of this type
asserts that the router(s) holding the corresponding private key are
authorized to emit secure route advertisements on behalf of the
AS(es) specified in the certificate. This document also profiles the
format of certification requests, and specifies Relying Party (RP)
certificate path validation procedures for these EE certificates.
This document extends the RPKI; therefore, this documents updates the
RPKI Resource Certificates Profile (RFC 6487).
"BGPsec Router Certificate Rollover", Roque Gagliano, Keyur Patel, Brian
Weis, 2016-03-21, <draft-ietf-sidr-bgpsec-rollover-05.txt>
BGPsec will need to address the impact from regular and emergency
rollover processes for the BGPsec End-Entity (EE) certificates that
will be performed by Certificate Authorities (CAs) participating at
the Resource Public Key Infrastructure (RPKI). Rollovers of BGPsec
EE certificates must be carefully managed in order to synchronize
distribution of router public keys and the usage of those pubic keys

by BGPsec routers. This document provides general recommendations

for that process, as well as describing reasons why the rollover of
BGPsec EE certificates might be necessary.
"BGPSec Considerations for AS Migration", Wesley George, Sandra Murphy,
2016-04-18, <draft-ietf-sidr-as-migration-05.txt>
This document discusses considerations and methods for supporting and
securing a common method for AS-Migration within the BGPSec protocol.
"An Out-Of-Band Setup Protocol For RPKI Production Services", Rob
Austein, 2016-04-11, <draft-ietf-sidr-rpki-oob-setup-04.txt>
This note describes a simple out-of-band protocol to ease setup of
the RPKI provisioning and publication protocols between two parties.
The protocol is encoded in a small number of XML messages, which can
be passed back and forth by any mutually agreeable secure means.
This setup protocol is not part of the provisioning or publication
protocol, rather, it is intended to simplify configuration of these
protocols by setting up relationships and exchanging BPKI keying
material.
"RPKI Local Trust Anchor Use Cases", Randy Bush, 2015-12-15,
<draft-ietf-sidr-lta-use-cases-04.txt>
There are a number of critical circumstances where a localized
routing domain needs to augment or modify its view of the Global
RPKI. This document attempts to outline a few of them.
"The Profile for Algorithms and Key Sizes for use in the Resource Public
Key Infrastructure", Geoff Huston, George Michaelson, 2016-03-08,
<draft-ietf-sidr-rfc6485bis-05.txt>
This document specifies the algorithms, algorithms' parameters,
asymmetric key formats, asymmetric key size, and signature format for
the Resource Public Key Infrastructure (RPKI) subscribers that
generate digital signatures on certificates, Certificate Revocation
Lists (CRLs), Cryptographic Message Syntax (CMS) signed objects and
certification requests as well as for the relying parties (RPs) that
verify these digital signatures.
"The Resource Public Key Infrastructure (RPKI) to Router Protocol",
Randy Bush, Rob Austein, 2016-03-03,
<draft-ietf-sidr-rpki-rtr-rfc6810-bis-07.txt>
In order to verifiably validate the origin Autonomous Systems and
Autonomous System Paths of BGP announcements, routers need a simple
but reliable mechanism to receive Resource Public Key Infrastructure
(RFC 6480) prefix origin data and router keys from a trusted cache.
This document describes a protocol to deliver validated prefix origin
data and router keys to routers.
This document describes version 1 of the rpki-rtr protocol.
"RPKI Validation Reconsidered", Geoff Huston, George Michaelson, Carlos
Martinez, Tim Bruijnzeels, Andrew Newton, Alain Aina, 2016-03-21,
<draft-ietf-sidr-rpki-validation-reconsidered-03.txt>
This document proposes and alternative to the certificate validation

procedure specified in RFC6487 that reduces aspects of operational

fragility in the management of certificates in the RPKI.
"RPKI Repository Delta Protocol", Tim Bruijnzeels, Oleg Muravskiy, Bryan
Weber, Rob Austein, David Mandelberg, 2016-03-21,
<draft-ietf-sidr-delta-protocol-02.txt>
In the Resource Public Key Infrastructure (RPKI), certificate
authorities publish certificates, including end entity certificates,
Certificate Revocation Lists (CRL), and RPKI signed objects to
repositories. Relying Parties (RP) retrieve the published
information from those repositories. This document specifies a delta
protocol which provides relying parties with a mechanism to query a
repository for incremental updates, thus enabling the RP to keep its
state in sync with the repository.
"Simplified Local internet nUmber Resource Management with the RPKI",
David Mandelberg, 2016-04-13, <draft-ietf-sidr-slurm-01.txt>
The Resource Public Key Infrastructure (RPKI) is a global
authorization infrastructure that allows the holder of Internet
Number Resources (INRs) to make verifiable statements about those
resources. Network operators, e.g., Internet Service Providers
(ISPs), can use the RPKI to validate BGP route origination
assertions. In the future, ISPs also will be able to use the RPKI to
validate the path of a BGP route. Some ISPs locally use BGP with
private address space or private AS numbers (see RFC6890). These
local BGP routes cannot be verified by the global RPKI, and SHOULD be
considered invalid based on the global RPKI (see RFC6491). The
mechanisms described below provide ISPs with a way to make local
assertions about private (reserved) INRs while using the RPKI's
assertions about all other INRs.
"RPKI Certificate Tree Validation by a Relying Party Tool", Oleg
Muravskiy, Tim Bruijnzeels, 2016-03-21,
<draft-ietf-sidr-rpki-tree-validation-00.txt>
This document currently describes the approach to validate the
content of the RPKI certificate tree, as used by the RIPE NCC RPKI
Validator. This approach is independent of a particular object
retrieval mechanism. This allows it to be used with repositories
available over the rsync protocol, the RPKI Repository Delta
Protocol, and repositories that use a mix of both.
This algorithm does not rely on content of repository directories,
but uses the Authority Key Identifier (AKI) field of a manifest and a
certificate revocation list (CRL) objects to discover manifest and
CRL objects issued by a particular Certificate Authority (CA). It
further uses the hashes of manifest entries to discover other objects
issued by the CA.
If the working group finds that algorithm outlined here is useful for
other implementations, we may either update future revisions of this
document to be less specific to the RIPE NCC RPKI Validator
implementation, or we may use this document as a starting point of a
generic validation document and keep this as a detailed description
of the actual RIPE NCC RPKI Validator implementation.
"Adverse Actions by a Certification Authority (CA) or Repository Manager
in the Resource Public Key Infrastructure (RPKI)", Stephen Kent, Di Ma,

2016-04-15, <draft-ietf-sidr-adverse-actions-00.txt>
This document analyzes actions by or against a CA or independent
repository manager in the RPKI that can adversely affect the Internet
Number Resources (INRs) associated with that CA or its subordinate
CAs. The analysis is based on examination of the data items in the
RPKI repository, as controlled by a CA (or independent repository
manager) and fetched by Relying Parties (RPs). The analysis is
performed from the perspective of an affected INR holder. The
analysis does not purport to be comprehensive; it does represent an
orderly way to analyze a number of ways that errors by or attacks
against a CA or repository manager can affect the RPKI and routing
decisions based on RPKI data.
Session Initiation Protocol Core (sipcore)
-----------------------------------------"Locating Session Initiation Protocol (SIP) Servers in a Dual-Stack IP
Network", oej, Gonzalo Salgueiro, Vijay Gurbani, Dale Worley,
2016-05-02, <draft-ietf-sipcore-dns-dual-stack-06.txt>
RFC 3263 defines how a Session Initiation Protocol (SIP)
implementation, given a SIP Uniform Resource Identifier (URI), should
locate the next-hop SIP server using Domain Name System (DNS)
procedures. As SIP networks increasingly transition from IPv4-only
to dual-stack, a quality user experience must be ensured for dualstack SIP implementations. This document updates the DNS procedures
described in RFC 3263 for dual-stack SIP implementations in
preparation for forthcoming specifications for applying Happy
Eyeballs principles to SIP.
SIP Recording (siprec)
---------------------"Session Initiation Protocol (SIP) Recording Metadata", Ram R,
Parthasarathi Ravindran, Paul Kyzivat, 2016-04-04,
<draft-ietf-siprec-metadata-22.txt>
Session recording is a critical requirement in many communications
environments such as call centers and financial trading. In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons. Recording of a session
is typically performed by sending a copy of a media stream to a
recording device. This document describes the metadata model as
viewed by Session Recording Server(SRS) and the Recording metadata
format.
"Session Recording Protocol", Leon Portman, Henry Lum, Charles Eckel,
Alan Johnston, Andrew Hutton, 2015-09-25,
<draft-ietf-siprec-protocol-18.txt>
This document specifies the use of the Session Initiation Protocol
(SIP), the Session Description Protocol (SDP), and the Real Time
Protocol (RTP) for delivering real-time media and metadata from a
Communication Session (CS) to a recording device. The Session
Recording Protocol specifies the use of SIP, SDP, and RTP to
establish a Recording Session (RS) between the Session Recording
Client (SRC), which is on the path of the CS, and a Session Recording
Server (SRS) at the recording device. This document considers only
active recording, where the SRC purposefully streams media to an SRS

and all participating user agents are notified of the recording.

Passive recording, where a recording device detects media directly
from the network (e.g., using port-mirroring techniques), is outside
the scope of this document. In addition, lawful intercept is outside
the scope of this document.
"Session Initiation Protocol (SIP) Recording Call Flows", Ram R,
Parthasarathi Ravindran, Paul Kyzivat, 2016-01-30,
<draft-ietf-siprec-callflows-06.txt>
Session recording is a critical requirement in many communications
environments such as call centers and financial trading. In some of
these environments, all calls must be recorded for regulatory,
compliance, and consumer protection reasons. Recording of a session
is typically performed by sending a copy of a media stream to a
recording device. This document lists call flows that has snapshot
of metadata sent from a Session Recording Client to Session Recording
Server. This is purely an informational document that is written to
support the model defined in the metadata draft.
Selection of Language for Internet Media (slim)
----------------------------------------------"Negotiating Human Language in Real-Time Communications", Randall
Gellens, 2016-03-21, <draft-ietf-slim-negotiating-human-language-01.txt>
Users have various human (natural) language needs, abilities, and
preferences regarding spoken, written, and signed languages. When
establishing interactive communication ("calls") there needs to be a
way to negotiate (communicate and match) the caller's language and
media needs with the capabilities of the called party. This is
especially important with emergency calls, where a call can be
handled by a call taker capable of communicating with the user, or a
translator or relay operator can be bridged into the call during
setup, but this applies to non-emergency calls as well (as an
example, when calling a company call center).
This document describes the need and a solution using new SDP stream
attributes.
"SLIM Use Cases", N Rooney, 2016-04-07,
<draft-ietf-slim-use-cases-01.txt>
Use cases for selection of language for internet media.
Softwires (softwire)
-------------------"Delivery of IPv4 Multicast Services to IPv4 Clients over an IPv6
Multicast Network", Jacni Qin, Mohamed Boucadair, Christian Jacquenet,
Yiu Lee, Qian Wang, 2016-02-26,
<draft-ietf-softwire-dslite-multicast-11.txt>
This document specifies a solution for the delivery of IPv4 multicast
services to IPv4 clients over an IPv6 multicast network. The
solution relies upon a stateless IPv4-in-IPv6 encapsulation scheme
and uses the IPv6 multicast distribution tree to deliver IPv4
multicast traffic. The solution is particularly useful for the
delivery of multicast service offerings to DS-Lite serviced
customers.

"Softwire Mesh Multicast", Mingwei Xu, Yong Cui, Jianping Wu, Shu Yang,
Chris Metz, Greg Shepherd, 2016-04-04,
<draft-ietf-softwire-mesh-multicast-12.txt>
The Internet needs to support IPv4 and IPv6 packets. Both address
families and their related protocol suites support multicast of the
single-source and any-source varieties. During IPv6 transition,
there will be scenarios where a backbone network running one IP
address family internally (referred to as internal IP or I-IP) will
provide transit services to attached client networks running another
IP address family (referred to as external IP or E-IP). It is
expected that the I-IP backbone will offer unicast and multicast
transit services to the client E-IP networks.
Softwire Mesh is a solution to E-IP unicast and multicast support
across an I-IP backbone. This document describes the mechanism for
supporting Internet-style multicast across a set of E-IP and I-IP
networks supporting softwire mesh.
"DHCPv6 Option for IPv4-Embedded Multicast and Unicast IPv6 Prefixes",
Mohamed Boucadair, Jacni Qin, Tina Tsou, Xiaohong Deng, 2016-02-26,
<draft-ietf-softwire-multicast-prefix-option-10.txt>
This document defines Dynamic Host Configuration Protocol version 6
(DHCPv6) Option for multicast IPv4 service continuity solutions,
aiming to convey the IPv6 prefixes to be used to build unicast and
multicast IPv4-embedded IPv6 addresses.
"Softwire Mesh Management Information Base (MIB)", Yong Cui, Jiang Dong,
Peng Wu, Mingwei Xu, Antti Yla-Jaaski, 2015-12-19,
<draft-ietf-softwire-mesh-mib-14.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 a softwire mesh.
"DS-Lite Management Information Base (MIB) for AFTRs", Yu Fu, Sheng
Jiang, Jiang Dong, Yuchi Chen, 2016-01-03,
<draft-ietf-softwire-dslite-mib-15.txt>
This memo defines a portion of the Management Information Base (MIB)
for using with network management protocols in the Internet
community. In particular, it defines managed objects for Address
Family Transition Routers (AFTRs) of Dual-Stack Lite (DS-Lite).
"Unified IPv4-in-IPv6 Softwire CPE", Mohamed Boucadair, Ian Farrer,
2016-04-22, <draft-ietf-softwire-unified-cpe-04.txt>
In IPv6-only provider networks, transporting IPv4 packets
encapsulated in IPv6 is a common solution to the problem of IPv4
service continuity. A number of differing functional approaches have
been developed for this, each having their own specific
characteristics. As these approaches share a similar functional
architecture and use the same data plane mechanisms, this memo
describes a specification whereby a single CPE can interwork with all
of the standardized and proposed approaches to providing encapsulated
IPv4 in IPv6 services.
"Definitions of Managed Objects for MAP-E", Yu Fu, Sheng Jiang, Bing

Liu, Jiang Dong, Yuchi Chen, 2015-12-17,

<draft-ietf-softwire-map-mib-05.txt>
This memo defines a portion of the Management Information Base (MIB)
for using with network management protocols in the Internet
community. In particular, it defines managed objects for MAP
encapsulation (MAP-E) mode.
"RADIUS Attribute for MAP", Sheng Jiang, Yu Fu, Bing Liu, Peter Deacon,
2015-12-23, <draft-ietf-softwire-map-radius-05.txt>
Mapping of Address and Port (MAP) is a stateless mechanism for
running IPv4 over IPv6-only infrastructure. It provides both IPv4
and IPv6 connectivity services simultaneously during the IPv4/IPv6
co-existing period. The Dynamic Host Configuration Protocol for IPv6
(DHCPv6) MAP options has been defined to configure MAP Customer Edge
(CE). However, in many networks, the configuration information may
be stored in Authentication Authorization and Accounting (AAA)
servers while user configuration is mainly from Broadband Network
Gateway (BNG) through DHCPv6 protocol. This document defines a
Remote Authentication Dial In User Service (RADIUS) attribute that
carries MAP configuration information from AAA server to BNG. The
MAP RADIUS attribute are designed following the simplify principle.
It provides just enough information to form the correspondent DHCPv6
MAP option.
Source Packet Routing in Networking (spring)
-------------------------------------------"SPRING Problem Statement and Requirements", Stefano Previdi, Clarence
Filsfils, Bruno Decraene, Stephane Litkowski, Martin Horneffer, Rob
Shakir, 2016-04-06, <draft-ietf-spring-problem-statement-08.txt>
The ability for a node to specify a forwarding path, other than the
normal shortest path, that a particular packet will traverse,
benefits a number of network functions. Source-based routing
mechanisms have previously been specified for network protocols, but
have not seen widespread adoption. In this context, the term
'source' means 'the point at which the explicit route is imposed' and
therefore it is not limited to the originator of the packet (i.e.:
the node imposing the explicit route may be the ingress node of an
operator's network).
This document outlines various use cases, with their requirements,
that need to be taken into account by the Source Packet Routing in
Networking (SPRING) architecture for unicast traffic. Multicast usecases and requirements are out of scope of this document.
"Use-cases for Resiliency in SPRING", P. Francois, Clarence Filsfils,
Bruno Decraene, Rob Shakir, 2016-04-06,
<draft-ietf-spring-resiliency-use-cases-03.txt>
This document describes the use cases for resiliency in SPRING
networks.
"IPv6 SPRING Use Cases", John Brzozowski, John Leddy, Ida Leung, Stefano
Previdi, W. Townsley, Christian Martin, Clarence Filsfils, Roberta
Maglione, 2016-03-03, <draft-ietf-spring-ipv6-use-cases-06.txt>
Source Packet Routing in Networking (SPRING) architecture leverages

the source routing paradigm. A node steers a packet through a

controlled set of instructions, called segments, by prepending the
packet with SPRING header. A segment can represent any instruction,
topological or service-based. A segment can have a local semantic to
the SPRING node or global within the SPRING domain. SPRING allows to
enforce a flow through any topological path and service chain while
maintaining per-flow state only at the ingress node to the SPRING
domain.
The objective of this document is to illustrate some use cases that
need to be taken into account by the Source Packet Routing in
Networking (SPRING) architecture.
"Segment Routing Architecture", Clarence Filsfils, Stefano Previdi,
Bruno Decraene, Stephane Litkowski, Rob Shakir, 2015-12-15,
<draft-ietf-spring-segment-routing-07.txt>
Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through an ordered list of instructions, called
segments. A segment can represent any instruction, topological or
service-based. A segment can have a local semantic to an SR node or
global within an SR domain. SR allows to enforce a flow through any
topological path and service chain while maintaining per-flow state
only at the ingress node to the SR domain.
Segment Routing can be directly applied to the MPLS architecture with
no change on the forwarding plane. A segment is encoded as an MPLS
label. An ordered list of segments is encoded as a stack of labels.
The segment to process is on the top of the stack. Upon completion
of a segment, the related label is popped from the stack.
Segment Routing can be applied to the IPv6 architecture, with a new
type of routing header. A segment is encoded as an IPv6 address. An
ordered list of segments is encoded as an ordered list of IPv6
addresses in the routing header. The active segment is indicated by
the Destination Address of the packet. The next active segment is
indicated by a pointer in the new routing header.
"Segment Routing with MPLS data plane", Clarence Filsfils, Stefano
Previdi, Ahmed Bashandy, Bruno Decraene, Stephane Litkowski, Martin
Horneffer, Rob Shakir, Jeff Tantsura, Edward Crabbe, 2016-03-18,
<draft-ietf-spring-segment-routing-mpls-04.txt>
Segment Routing (SR) leverages the source routing paradigm. A node
steers a packet through a controlled set of instructions, called
segments, by prepending the packet with an SR header. A segment can
represent any instruction, topological or service-based. SR allows
to enforce a flow through any topological path and service chain
while maintaining per-flow state only at the ingress node to the SR
domain.
Segment Routing can be directly applied to the MPLS architecture with
no change in the forwarding plane. This drafts describes how Segment
Routing operates on top of the MPLS data plane.
"OAM Requirements for Segment Routing Network", Nagendra Kumar, Carlos
Pignataro, Nobo Akiya, Ruediger Geib, Greg Mirsky, Stephane Litkowski,
2015-12-31, <draft-ietf-spring-sr-oam-requirement-01.txt>
This document describes a list of functional requirement for OAM in

Segment Routing (SR) based network.

"YANG Data Model for Segment Routing", Stephane Litkowski, Yingzhen Qu,
Jeff Tantsura, 2016-03-18, <draft-ietf-spring-sr-yang-02.txt>
This document defines a YANG data model ([RFC6020]) for segment
routing ([I-D.ietf-spring-segment-routing]) configuration and
operation. This YANG model is intended to be used on network
elements to configure or operate segment routing. This document
defines also generic containers that SHOULD be reused by IGP protocol
modules to support segment routing.
"BGP-Prefix Segment in large-scale data centers", Clarence Filsfils,
Stefano Previdi, Jon Mitchell, exa, Petr Lapukhov, 2016-04-13,
<draft-ietf-spring-segment-routing-msdc-01.txt>
This document describes the motivation and benefits for applying
segment routing in the data-center. It describes the design to
deploy segment routing in the data-center, for both the MPLS and IPv6
dataplanes.
"Segment Routing Conflict Resolution", Les Ginsberg, Peter Psenak,
Stefano Previdi, Martin Pilka, 2016-04-12,
<draft-ginsberg-spring-conflict-resolution-01.txt>
In support of Segment Routing (SR) routing protocols advertise a
variety of identifiers used to define the segments which direct
forwarding of packets. In cases where the information advertised by
a given protocol instance is either internally inconsistent or
conflicts with advertisements from another protocol instance a means
of achieving consistent forwarding behavior in the network is
required. This document defines the policies used to resolve these
occurrences.
"A Scalable and Topology-Aware MPLS Dataplane Monitoring System",
Ruediger Geib, Clarence Filsfils, Carlos Pignataro, Nagendra Kumar,
2016-04-25, <draft-ietf-spring-oam-usecase-03.txt>
This document describes features of a path monitoring system and
related use cases. Segment based routing enables a scalable and
simple method to monitor data plane liveliness of the complete set of
paths belonging to a single domain. The MPLS monitoring system adds
features to the traditional MPLS ping and LSP trace, in a very
complementary way. MPLS topology awareness reduces management and
control plane involvement of OAM measurements while enabling new OAM
features.
"Segment Routing interworking with LDP", Clarence Filsfils, Stefano
Previdi, Ahmed Bashandy, Bruno Decraene, Stephane Litkowski, 2016-04-14,
<draft-ietf-spring-segment-routing-ldp-interop-01.txt>
A Segment Routing (SR) node steers a packet through a controlled set
of instructions, called segments, by prepending the packet with an SR
header. A segment can represent any instruction, topological or
service-based. SR allows to enforce a flow through any topological
path and service chain while maintaining per-flow state only at the
ingress node to the SR domain.
The Segment Routing architecture can be directly applied to the MPLS
data plane with no change in the forwarding plane. This drafts

describes how Segment Routing operates in a network where LDP is

deployed and in the case where SR-capable and non-SR-capable nodes
coexist.
"Segment Routing Centralized BGP Peer Engineering", Clarence Filsfils,
Stefano Previdi, exa, Daniel Ginsburg, Dmitry Afanasiev, 2016-03-21,
<draft-ietf-spring-segment-routing-central-epe-01.txt>
Segment Routing (SR) leverages source routing. A node steers a
packet through a controlled set of instructions, called segments, by
prepending the packet with an SR header. A segment can represent any
instruction topological or service-based. SR allows to enforce a
flow through any topological path and service chain while maintaining
per-flow state only at the ingress node of the SR domain.
The Segment Routing architecture can be directly applied to the MPLS
dataplane with no change on the forwarding plane. It requires minor
extension to the existing link-state routing protocols.
This document illustrates the application of Segment Routing to solve
the BGP Peer Engineering (BGP-PE) requirement. The SR-based BGP-PE
solution allows a centralized (SDN) controller to program any egress
peer policy at ingress border routers or at hosts within the domain.
This document is on the informational track.
Secure Telephone Identity Revisited (stir)
-----------------------------------------"Authenticated Identity Management in the Session Initiation Protocol
(SIP)", Jon Peterson, Cullen Jennings, Eric Rescorla, Chris Wendt,
2016-03-21, <draft-ietf-stir-rfc4474bis-08.txt>
The baseline security mechanisms in the Session Initiation Protocol
(SIP) are inadequate for cryptographically assuring the identity of
the end users that originate SIP requests, especially in an
interdomain context. This document defines a mechanism for securely
identifying originators of SIP requests. It does so by defining a
SIP header field for conveying a signature used for validating the
identity, and for conveying a reference to the credentials of the
signer.
"Secure Telephone Identity Credentials: Certificates", Jon Peterson,
spt, 2016-03-21, <draft-ietf-stir-certificates-03.txt>
In order to prevent the impersonation of telephone numbers on the
Internet, some kind of credential system needs to exist that
cryptographically proves authority over telephone numbers. This
document describes the use of certificates in establishing authority
over telephone numbers, as a component of a broader architecture for
managing telephone numbers as identities in protocols like SIP.
"Persona Assertion Token", Chris Wendt, Jon Peterson, 2016-03-23,
<draft-ietf-stir-passport-01.txt>
This document defines a token format for verifying with nonrepudiation the sender of and authorization to send information
related to the originator of personal communications. A
cryptographic signature is defined to protect the integrity of the
information used to identify the originator of a personal
communications session (e.g. the telephone number or URI) and verify

the accuracy of this information at the destination. The

cryptographic signature is defined with the intention that it can
confidently verify the originating persona even when the signature is
sent to the destination party over an unsecure channel. The Persona
Assertion Token (PASSporT) is particularly useful for many personal
communications applications over IP networks and other multi-hop
interconnection scenarios where the originating and destination
parties may not have a direct trusted relationship.
SIP-TO-XMPP (stox)
-----------------"Interworking between the Session Initiation Protocol (SIP) and the
Extensible Messaging and Presence Protocol (XMPP): Presence", Peter
Saint-Andre, 2016-04-28, <draft-ietf-stox-7248bis-08.txt>
This document defines a bidirectional protocol mapping for the
exchange of presence information between the Session Initiation
Protocol (SIP) and the Extensible Messaging and Presence Protocol
(XMPP). This document obsoletes RFC 7248.
Sip Traversal Required for Applications to Work (straw)
------------------------------------------------------"Guidelines to support RTCP end-to-end in Back-to-Back User Agents
(B2BUAs)", Lorenzo Miniero, Sergio Murillo, Victor Pascual, 2016-04-19,
<draft-ietf-straw-b2bua-rtcp-10.txt>
SIP Back-to-Back User Agents (B2BUAs) are often envisaged to also be
on the media path, rather than just intercepting signalling. This
means that B2BUAs often implement an RTP/RTCP stack as well, whether
to act as media transcoders or to just passthrough the media
themselves, thus leading to separate multimedia sessions that the
B2BUA correlates and bridges together. If not disciplined, though,
this behaviour can severely impact the communication experience,
especially when statistics and feedback information contained in RTCP
messages get lost because of mismatches in the reported data.
This document defines the proper behaviour B2BUAs should follow when
also acting on the signalling/media plane in order to preserve the
end-to-end functionality of RTCP.
"DTLS-SRTP Handling in Session Initiation Protocol (SIP) Back-to-Back
User Agents (B2BUAs)", Ram R, Tirumaleswar Reddy, Gonzalo Salgueiro,
Victor Pascual, Parthasarathi Ravindran, 2016-04-04,
<draft-ietf-straw-b2bua-dtls-srtp-12.txt>
Session Initiation Protocol (SIP) Back-to-Back User Agents (B2BUA)
exist on the signaling and media paths between the endpoints. This
document describes the behavior of B2BUAs when Secure Real-time
Transport (SRTP) security context is set up with the Datagram
Transport Layer Security (DTLS) protocol.
Sunsetting IPv4 (sunset4)
------------------------"Analysis of NAT64 Port Allocation Methods for Shared IPv4 Addresses",
Gang Chen, Weibo Li, Tina Tsou, Jing Huang, Tom Taylor, JF Tremblay,
2016-01-18, <draft-ietf-sunset4-nat64-port-allocation-02.txt>

This document enumerates methods of port assignment in Carrier Grade

NATs (CGNs), focused particularly on NAT64 environments. Different
NAT port allocation methods have been categorized and described. A
series of port allocation design principle has been proposed to
facilitate the implementations and deployment.
Simplified Use of Policy Abstractions (supa)
-------------------------------------------"Generic Policy Information Model for Simplified Use of Policy
Abstractions (SUPA)", John Strassner, Joel Halpern, Jason Coleman,
2016-03-21, <draft-strassner-supa-generic-policy-info-model-05.txt>
This document defines an information model for representing
policies using a common extensible framework that is independent
of language, protocol, repository. It is also independent of the
level of abstraction of the content and meaning of a policy.
Transport Services (taps)
------------------------"Services provided by IETF transport protocols and congestion control
mechanisms", Gorry Fairhurst, Brian Trammell, Mirja Khlewind,
2016-03-04, <draft-ietf-taps-transports-10.txt>
This document describes, surveys, classifies and compares the
protocol mechanisms provided by existing IETF protocols, as
background for determining a common set of transport services. It
examines the Transmission Control Protocol (TCP), Multipath TCP, the
Stream Control Transmission Protocol (SCTP), the User Datagram
Protocol (UDP), UDP-Lite, the Datagram Congestion Control Protocol
(DCCP), the Internet Control Message Protocol (ICMP), the Realtime
Transport Protocol (RTP), File Delivery over Unidirectional
Transport/Asynchronous Layered Coding Reliable Multicast (FLUTE/ALC),
and NACK-Oriented Reliable Multicast (NORM), Transport Layer Security
(TLS), Datagram TLS (DTLS), and the Hypertext Transport Protocol
(HTTP) when used as a pseudotransport.
"On the Usage of Transport Service Features Provided by IETF Transport
Protocols", Michael Welzl, Michael Tuexen, Naeem Khademi, 2016-01-08,
<draft-ietf-taps-transports-usage-00.txt>
This document describes how transport protocols expose services to
applications and how an application can configure and use the
features of a transport service.
TCP Increased Security (tcpinc)
------------------------------"TCP-ENO: Encryption Negotiation Option", Andrea Bittau, Dan Boneh,
Daniel Giffin, Mark Handley, David Mazieres, Eric Smith, 2016-02-21,
<draft-ietf-tcpinc-tcpeno-01.txt>
Despite growing adoption of TLS [RFC5246], a significant fraction of
TCP traffic on the Internet remains unencrypted. The persistence of
unencrypted traffic can be attributed to at least two factors.
First, some legacy protocols lack a signaling mechanism (such as a
"STARTTLS" command) by which to convey support for encryption, making
incremental deployment impossible. Second, legacy applications
themselves cannot always be upgraded, requiring a way to implement

encryption transparently entirely within the transport layer. The

TCP Encryption Negotiation Option (TCP-ENO) addresses both of these
problems through a new TCP option kind providing out-of-band, fully
backward-compatible negotiation of encryption.
"Cryptographic protection of TCP Streams (tcpcrypt)", Andrea Bittau, Dan
Boneh, Daniel Giffin, Mike Hamburg, Mark Handley, David Mazieres, Quinn
Slack, Eric Smith, 2016-02-22, <draft-ietf-tcpinc-tcpcrypt-01.txt>
This document specifies tcpcrypt, a cryptographic protocol that
protects TCP payload data and is negotiated by means of the TCP
Encryption Negotiation Option (TCP-ENO) [I-D.ietf-tcpinc-tcpeno].
Tcpcrypt coexists with middleboxes by tolerating resegmentation,
NATs, and other manipulations of the TCP header. The protocol is
self-contained and specifically tailored to TCP implementations,
which often reside in kernels or other environments in which large
external software dependencies can be undesirable. Because of option
size restrictions, the protocol requires one additional one-way
message latency to perform key exchange. However, this cost is
avoided between two hosts that have recently established a previous
tcpcrypt connection.
"Using TLS to Protect TCP Streams", Eric Rescorla, 2016-05-03,
<draft-ietf-tcpinc-use-tls-01.txt>
This document defines the use of TLS [RFC5246] with the TCP-ENO
option [I-D.bittau-tcpinc-tcpeno].
TCP Maintenance and Minor Extensions (tcpm)
------------------------------------------"TCP Extended Data Offset Option", Joseph Touch, Wesley Eddy,
2016-04-25, <draft-ietf-tcpm-tcp-edo-05.txt>
TCP segments include a Data Offset field to indicate space for TCP
options but the size of the field can limit the space available for
complex options such as SACK and Multipath TCP and can limit the
combination of such options supported in a single connection. This
document updates RFC 793 with an optional TCP extension to that
space to support the use of multiple large options. It also explains
why the initial SYN of a connection cannot be extending a single
segment.
"CUBIC for Fast Long-Distance Networks", Injong Rhee, Lisong Xu, Sangtae
Ha, Alexander Zimmermann, Lars Eggert, Richard Scheffenegger,
2016-01-18, <draft-ietf-tcpm-cubic-01.txt,.pdf>
CUBIC is an extension to the current TCP standards. The protocol
differs from the current TCP standards only in the congestion window
adjustment function in the sender side. In particular, it uses a
cubic function instead of a linear window increase of the current TCP
standards to improve scalability and stability under fast and long
distance networks. BIC-TCP, a predecessor of CUBIC, has been a
default TCP adopted by Linux since year 2005 and has already been
deployed globally and in use for several years by the Internet
community at large. CUBIC is using a similar window growth function
as BIC-TCP and is designed to be less aggressive and fairer to TCP in
bandwidth usage than BIC-TCP while maintaining the strengths of BICTCP such as stability, window scalability and RTT fairness. Through
extensive testing in various Internet scenarios, we believe that

CUBIC is safe for deployment and testing in the global Internet. The
intent of this document is to provide the protocol specification of
CUBIC for a third party implementation and solicit the community
feedback through experimentation on the performance of CUBIC.
"Transmission Control Protocol Specification", Wesley Eddy, 2016-03-21,
<draft-ietf-tcpm-rfc793bis-02.txt>
This document specifies the Internet's Transmission Control Protocol
(TCP). TCP is an important transport layer protocol in the Internet
stack, and has continuously evolved over decades of use and growth of
the Internet. Over this time, a number of changes have been made to
TCP as it was specified in RFC 793, though these have only been
documented in a piecemeal fashion. This document collects and brings
those changes together with the protocol specification from RFC 793.
This document obsoletes RFC 793 and several other RFCs (TODO: list
all actual RFCs when finished).
RFC EDITOR NOTE: If approved for publication as an RFC, this should
be marked additionally as "STD: 7" and replace RFC 793 in that role.
"More Accurate ECN Feedback in TCP", Bob Briscoe, Mirja Khlewind,
Richard Scheffenegger, 2015-12-14, <draft-ietf-tcpm-accurate-ecn-00.txt>
Explicit Congestion Notification (ECN) is a mechanism where network
nodes can mark IP packets instead of dropping them to indicate
incipient congestion to the end-points. Receivers with an ECNcapable transport protocol feed back this information to the sender.
ECN is specified for TCP in such a way that only one feedback signal
can be transmitted per Round-Trip Time (RTT). Recently, new TCP
mechanisms like Congestion Exposure (ConEx) or Data Center TCP
(DCTCP) need more accurate ECN feedback information whenever more
than one marking is received in one RTT. This document specifies an
experimental scheme to provide more than one feedback signal per RTT
in the TCP header. Given TCP header space is scarce, it overloads
the three existing ECN-related flags in the TCP header and provides
additional information in a new TCP option.
"Retransmission Timeout Considerations", Mark Allman, 2016-04-15,
<draft-ietf-tcpm-rto-consider-03.txt>
Each implementation of a retransmission timeout mechanism represents
a balance between correctness and timeliness and therefore no
implementation suits all situations. This document provides
high-level requirements for retransmission timeout schemes
appropriate for general use in the Internet. Within the
requirements, implementations have latitude to define particulars
that best address each situation.
Terminology
Traffic Engineering Architecture and Signaling (teas)
----------------------------------------------------"Problem Statement and Architecture for Information Exchange Between
Interconnected Traffic Engineered Networks", Adrian Farrel, John Drake,
Nabil Bitar, George Swallow, Daniele Ceccarelli, Xian Zhang, 2016-04-26,
<draft-ietf-teas-interconnected-te-info-exchange-05.txt>
In Traffic Engineered (TE) systems, it is sometimes desirable to

establish an end-to-end TE path with a set of constraints (such as

bandwidth) across one or more network from a source to a destination.
TE information is the data relating to nodes and TE links that is
used in the process of selecting a TE path. TE information is
usually only available within a network. We call such a zone of
visibility of TE information a domain. An example of a domain may be
an IGP area or an Autonomous System.
In order to determine the potential to establish a TE path through a
series of connected networks, it is necessary to have available a
certain amount of TE information about each network. This need not
be the full set of TE information available within each network, but
does need to express the potential of providing TE connectivity. This
subset of TE information is called TE reachability information.
This document sets out the problem statement for the exchange of TE
information between interconnected TE networks in support of end-toend TE path establishment and describes the best current practice
architecture to meet this problem statement. For reasons that are
explained in the document, this work is limited to simple TE
constraints and information that determine TE reachability.
"RSVP-TE Signaling Procedure for End-to-End GMPLS Restoration and
Resource Sharing", Xian Zhang, zhenghaomian@huawei.com, Rakesh Gandhi,
Zafar Ali, Gabriele Galimberti, Pawel Brzozowski, 2016-02-10,
<draft-ietf-teas-gmpls-resource-sharing-proc-04.txt>
In transport networks, there are requirements where Generalized
Multi-Protocol Label Switching (GMPLS) end-to-end recovery scheme
needs to employ restoration Label Switched Path (LSP) while keeping
resources for the working and/or protecting LSPs reserved in the
network after the failure occurs.
This document reviews how the LSP association is to be provided using
Resource Reservation Protocol - Traffic Engineering (RSVP-TE)
signaling in the context of GMPLS end-to-end recovery scheme when
using restoration LSP where failed LSP is not torn down. In
addition, this document discusses resource sharing-based setup and
teardown of LSPs as well as LSP reversion procedures for transport
networks. No new signaling extensions are defined by this document,
and it is strictly informative in nature.
"RSVP Extensions For Re-optimization of Loosely Routed
Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs)",
Tarek Saad, Rakesh Gandhi, Zafar Ali, Robert Venator, Yuji Kamite,
2016-03-11, <draft-ietf-teas-p2mp-loose-path-reopt-05.txt>
For a Traffic Engineered (TE) Point-to-Multipoint (P2MP) Label
Switched Path (LSP), it is preferable in some cases to re-evaluate
and re-optimize the entire P2MP-TE LSP by re-signaling all its
Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism
for an ingress Label Switched Router (LSR) to trigger a new path
re-evaluation request and a mechanism for a mid-point LSR to notify
an availability of a preferred path, operate on an individual or a
sub-group of S2L sub-LSP(s) basis only.
This document defines Resource Reservation Protocol (RSVP) signaling
extensions to allow an ingress node of a P2MP-TE LSP to request the
re-evaluation of the entire LSP tree containing one or more S2L
sub-LSPs whose paths are loose (or abstract) hop expanded, and for a

mid-point LSR to notify to the ingress node that a preferable tree

exists for the entire P2MP-TE LSP. For re-optimizing a group of S2L
sub-LSP(s) in a tree, an S2L sub-LSP descriptor list can be used to
signal one or more S2L sub-LSPs in an RSVP message. This document
defines fragment identifier for the S2L sub-LSP descriptor list when
the RSVP message needs to be fragmented due to large number of S2L
sub-LSPs in the message when performing sub-group based
re-optimization.
"Domain Subobjects for Resource ReserVation Protocol - Traffic
Engineering (RSVP-TE)", Dhruv Dhody, Udayasree Palle, Venugopal
Kondreddy, Ramon Casellas, 2015-11-19,
<draft-ietf-teas-rsvp-te-domain-subobjects-05.txt>
The Resource ReserVation Protocol - Traffic Engineering (RSVP-TE)
specification and the Generalized Multiprotocol Label Switching
(GMPLS) extensions to RSVP-TE allow abstract nodes and resources to
be explicitly included in a path setup. Further Exclude Routes
extensions to RSVP-TE allow abstract nodes and resources to be
explicitly excluded in a path setup.
This document specifies new subobjects to include or exclude 4-Byte
Autonomous System (AS) and Interior Gateway Protocol (IGP) area
during path setup.
"Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path
Diversity using Exclude Route", Zafar Ali, George Swallow, Fatai Zhang,
Dieter Beller, 2016-03-21, <draft-ietf-teas-lsp-diversity-04.txt>
RFC 4874 specifies methods by which path exclusions can be
communicated during RSVP-TE signaling in networks where precise
explicit paths are not computed by the LSP source node. This
document specifies procedures for additional route exclusion
subobject based on Paths currently existing or expected to exist
within the network.
"Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) extension
for recording TE Metric of a Label Switched Path", Zafar Ali, George
Swallow, Clarence Filsfils, Matt Hartley, Kenji Kumaki, Ruediger Kunze,
2016-03-21, <draft-ietf-teas-te-metric-recording-04.txt>
There are many scenarios in which Traffic Engineering (TE) metrics
such as cost, delay and delay variation associated with the TE link
formed by Label Switched Path (LSP) are not available to the
ingress and egress nodes. This draft provides extensions for the
Resource ReserVation Protocol- Traffic Engineering (RSVP-TE) to
support automatic collection of cost, delay and delay variation
information for the TE link formed by a LSP.
"RSVP-TE Extensions for Collecting SRLG Information", Fatai Zhang, Oscar
Gonzalez de Dios, Matt Hartley, Zafar Ali, Cyril Margaria, 2016-04-04,
<draft-ietf-teas-rsvp-te-srlg-collect-05.txt>
This document provides extensions for the Resource ReserVation
Protocol-Traffic Engineering (RSVP-TE), including GMPLS, to support
automatic collection of Shared Risk Link Group (SRLG) information for
the TE link formed by a Label Switched Path (LSP).
"Extensions to Resource Reservation Protocol For Fast Reroute of Traffic
Engineering GMPLS LSPs", Mike Taillon, Tarek Saad, Rakesh Gandhi, Zafar

Ali, Manav Bhatia, Lizhong Jin, 2016-01-26,

<draft-ietf-teas-gmpls-lsp-fastreroute-04.txt>
This document defines Resource Reservation Protocol - Traffic
Engineering (RSVP-TE) signaling extensions to support Fast Reroute
(FRR) of Packet Switched Capable (PSC) Generalized Multi-Protocol
Label Switching (GMPLS) Label Switched Paths (LSPs). These signaling
extensions allow the coordination of bidirectional bypass tunnel
assignment protecting a common facility in both forward and reverse
directions of a co-routed bidirectional LSP. In addition, these
extensions enable the re-direction of bidirectional traffic and
signaling onto bypass tunnels that ensure co-routedness of data and
signaling paths in the forward and reverse directions after FRR to
avoid RSVP soft-state timeout.
"Extensions to RSVP-TE for LSP Egress Local Protection", Huaimo Chen,
Autumn Liu, Tarek Saad, Fengman Xu, Lu Huang, Ning So, 2016-03-18,
<draft-ietf-teas-rsvp-egress-protection-04.txt>
This document describes extensions to Resource Reservation Protocol Traffic Engineering (RSVP-TE) for locally protecting egress nodes of
a Traffic Engineered (TE) Label Switched Path (LSP), which is a
Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP.
"Extensions to RSVP-TE for LSP Ingress Local Protection", Huaimo Chen,
Raveendra Torvi, 2016-04-15,
<draft-ietf-teas-rsvp-ingress-protection-06.txt>
This document describes extensions to Resource Reservation Protocol Traffic Engineering (RSVP-TE) for locally protecting the ingress node
of a Traffic Engineered (TE) Label Switched Path (LSP), which is a
Point-to-Point (P2P) LSP or a Point-to-Multipoint (P2MP) LSP.
"Performance-based Path Selection for Explicitly Routed LSPs using TE
Metric Extensions", Alia Atlas, John Drake, Spencer Giacalone, Stefano
Previdi, 2015-10-01, <draft-ietf-teas-te-express-path-05.txt>
In certain networks, it is critical to consider network performance
criteria when selecting the path for an explicitly routed RSVP-TE
LSP. Such performance criteria can include latency, jitter, and loss
or other indications such as the conformance to link performance
objectives and non-RSVP TE traffic load. This specification
describes how a path computation function may use network performance
data, such as is advertised via the OSPF and ISIS TE metric
extensions (defined outside the scope of this document) to perform
such path selections.
"YANG Data Model for TE Topologies", Xufeng Liu, Igor Bryskin, Vishnu
Pavan Beeram, Tarek Saad, Himanshu Shah, Oscar Gonzalez de Dios,
2016-03-21, <draft-ietf-teas-yang-te-topo-04.txt>
This document defines a YANG data model for representing, retrieving
and manipulating TE Topologies. The model serves as a base model that
other technology specific TE Topology models can augment.
"A YANG Data Model for Resource Reservation Protocol (RSVP)", Vishnu
Pavan Beeram, Tarek Saad, Rakesh Gandhi, Xufeng Liu, Himanshu Shah, Xia
Chen, Raqib Jones, Bin Wen, 2016-03-21,
<draft-ietf-teas-yang-rsvp-03.txt>

This document defines a YANG data model for the configuration and
management of RSVP Protocol. The model defines generic RSVP protocol
building blocks that can be augmented and used by other RSVP
extension models such as RVSP extensions to Traffic-Engineering
(RSVP-TE). The model covers the RSVP protocol configuration,
operational state, remote procedural calls, and event notifications
data.
"A YANG Data Model for Traffic Engineering Tunnels and Interfaces",
Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Pavan Beeram, Himanshu
Shah, Xia Chen, Raqib Jones, Bin Wen, 2016-03-20,
<draft-ietf-teas-yang-te-03.txt>
This document defines a YANG data model for the configuration and
management of Traffic Engineering (TE) interfaces, tunnels and Label
Switched Paths (LSPs). The model is divided into YANG modules that
classify data into generic, device-specific, technology agnostic, and
technology-specific elements. The model also includes module(s) that
contain reusable TE data types and data groupings.
This model covers the configuration, operational state, remote
procedural calls, and event notifications data.
"Requirements for Abstraction and Control of TE Networks", Young Lee,
Dhruv Dhody, Sergio Belotti, Khuzema Pithewan, Daniele Ceccarelli,
2016-04-13, <draft-ietf-teas-actn-requirements-02.txt>
This draft provides a set of requirements for abstraction and
control of TE networks.
"Implementation Recommendations to Improve the Scalability of RSVP-TE
Deployments", Vishnu Pavan Beeram, Ina Minei, Rob Shakir, Dante Pacella,
Tarek Saad, 2016-03-21, <draft-ietf-teas-rsvp-te-scaling-rec-01.txt>
The scale at which RSVP-TE Label Switched Paths (LSPs) get deployed
is growing continually and the onus is on RSVP-TE implementations
across the board to keep up with this increasing demand.
This document makes a set of implementation recommendations to help
RSVP-TE deployments push the envelope on scaling and advocates the
use of a couple of techniques - "Refresh Interval Independent RSVP
(RI-RSVP)" and "Per-Peer flow-control" - for improving scaling.
Timing over IP Connection and Transfer of Clock (tictoc)
-------------------------------------------------------"Precision Time Protocol Version 2 (PTPv2) Management Information Base",
Vinay Shankarkumar, Laurent Montini, Tim Frost, Greg Dowd, 2016-04-21,
<draft-ietf-tictoc-ptp-mib-09.txt>
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing networks using
Precision Time Protocol, specified in IEEE Std. 1588(TM)-2008.
This memo specifies a MIB module in a manner that is both compliant
to the SMIv2, and semantically identical to the peer SMIv1
definitions.
"Enterprise Profile for the Precision Time Protocol With Mixed Multicast

and Unicast Messages", Doug Arnold, Heiko Gerstung, 2016-01-22,

<draft-ietf-tictoc-ptp-enterprise-profile-06.txt>
This document describes a profile for the use of the Precision
Time Protocol in an IPV4 or IPv6 Enterprise information system
environment. The profile uses the End to End Delay Measurement
Mechanism, allows both multicast and unicast Delay Request and Delay
Response Messages.
"Multi-Path Time Synchronization", Alex Shpiner, Richard Tse, Craig
Schelp, Tal Mizrahi, 2016-04-18,
<draft-ietf-tictoc-multi-path-synchronization-04.txt>
Clock synchronization protocols are very widely used in IP-based
networks. The Network Time Protocol (NTP) has been commonly deployed
for many years, and the last few years have seen an increasingly
rapid deployment of the Precision Time Protocol (PTP). As timesensitive applications evolve, clock accuracy requirements are
becoming increasingly stringent, requiring the time synchronization
protocols to provide high accuracy. Slave Diversity is a recently
introduced approach, where the master and slave clocks (also known as
server and client) are connected through multiple network paths, and
the slave combines the information received through all paths to
obtain a higher clock accuracy compared to the conventional one-path
approach. This document describes a multi-path approach to PTP and
NTP over IP networks, allowing the protocols to run concurrently over
multiple communication paths between the master and slave clocks. The
multi-path approach can significantly contribute to clock accuracy,
security and fault tolerance. The Multi-Path Precision Time Protocol
(MPPTP) and Multi-Path Network Time Protocol (MPNTP) define an
additional layer that extends the existing PTP and NTP without the
need to modify these protocols. MPPTP and MPNTP also allow backward
compatibility with nodes that do not support the multi-path
extension.
"YANG Data Model for IEEE 1588v2", Yuanlong Jiang, Xian Liu, Jinchun Xu,
rodney.cummings@ni.com, 2016-03-14,
<draft-jlx-tictoc-1588v2-yang-04.txt>
This document defines a YANG data model for the configuration of
IEEE 1588-2008 devices and clocks, and also retrieval of the
configuration information, data set and running states of IEEE
1588-2008 clocks.
Transport Layer Security (tls)
-----------------------------"Transport Layer Security (TLS) Cached Information Extension", Stefan
Santesson, Hannes Tschofenig, 2016-01-26,
<draft-ietf-tls-cached-info-22.txt>
Transport Layer Security (TLS) handshakes often include fairly static
information, such as the server certificate and a list of trusted
certification authorities (CAs). This information can be of
considerable size, particularly if the server certificate is bundled
with a complete certificate chain (i.e., the certificates of
intermediate CAs up to the root CA).
This document defines an extension that allows a TLS client to inform
a server of cached information, allowing the server to omit already

available information.
"Secure Password Ciphersuites for Transport Layer Security (TLS)", Dan
Harkins, Dave Halasz, 2016-02-25, <draft-ietf-tls-pwd-07.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
ciphersuites are all based on an authentication and key exchange
protocol that is resistant to off-line dictionary attack.
"The Transport Layer Security (TLS) Protocol Version 1.3", Eric
Rescorla, 2016-03-22, <draft-ietf-tls-tls13-12.txt>
This document specifies Version 1.3 of the Transport Layer Security
(TLS) protocol. The TLS protocol allows client/server applications
to communicate over the Internet in a way that is designed to prevent
eavesdropping, tampering, and message forgery.
"Negotiated Finite Field Diffie-Hellman Ephemeral Parameters for TLS",
Daniel Kahn Gillmor, 2015-06-01,
<draft-ietf-tls-negotiated-ff-dhe-10.txt>
Traditional finite-field-based Diffie-Hellman (DH) key exchange
during the TLS handshake suffers from a number of security,
interoperability, and efficiency shortcomings. These shortcomings
arise from lack of clarity about which DH group parameters TLS
servers should offer and clients should accept. This document offers
a solution to these shortcomings for compatible peers by using a
section of the TLS "EC Named Curve Registry" to establish common
finite-field DH parameters with known structure and a mechanism for
peers to negotiate support for these groups.
This draft updates TLS versions 1.0 [RFC2246], 1.1 [RFC4346], and 1.2
[RFC5246], as well as the TLS ECC extensions [RFC4492].
"Elliptic Curve Cryptography (ECC) Cipher Suites for Transport Layer
Security (TLS) Versions 1.2 and Earlier", Yoav Nir, Simon Josefsson,
Manuel Pgouri-Gonnard, 2016-03-21, <draft-ietf-tls-rfc4492bis-07.txt>
This document describes key exchange algorithms based on Elliptic
Curve Cryptography (ECC) for the Transport Layer Security (TLS)
protocol. In particular, it specifies the use of Ephemeral Elliptic
Curve Diffie-Hellman (ECDHE) key agreement in a TLS handshake and the
use of Elliptic Curve Digital Signature Algorithm (ECDSA) and Edwards
Digital Signature Algorithm (EdDSA) as new authentication mechanisms.
"Transport Layer Security (TLS) False Start", Adam Langley, Nagendra
Modadugu, Bodo Moeller, 2015-11-02, <draft-ietf-tls-falsestart-01.txt>
This document specifies an optional behavior of TLS client
implementations, dubbed False Start. It affects only protocol
timing, not on-the-wire protocol data, and can be implemented
unilaterally. A TLS False Start reduces handshake latency to one
round trip.
"ChaCha20-Poly1305 Cipher Suites for Transport Layer Security (TLS)",
Adam Langley, Wan-Teh Chang, Nikos Mavrogiannopoulos, Joachim
Strombergson, Simon Josefsson, 2015-12-16,
<draft-ietf-tls-chacha20-poly1305-04.txt>

This document describes the use of the ChaCha stream cipher and
Poly1305 authenticator in the Transport Layer Security (TLS) and
Datagram Transport Layer Security (DTLS) protocols.
Token Binding (tokbind)
----------------------"The Token Binding Protocol Version 1.0", Andrey Popov, Magnus Nystrom,
Dirk Balfanz, Adam Langley, Jeff Hodges, 2016-04-04,
<draft-ietf-tokbind-protocol-05.txt>
This document specifies Version 1.0 of the Token Binding protocol.
The Token Binding protocol allows client/server applications to
create long-lived, uniquely identifiable TLS [RFC5246] bindings
spanning multiple TLS sessions and connections. Applications are
then enabled to cryptographically bind security tokens to the TLS
layer, preventing token export and replay attacks. To protect
privacy, the TLS Token Binding identifiers are only transmitted
encrypted and can be reset by the user at any time.
"Token Binding over HTTP", Andrey Popov, Magnus Nystrom, Dirk Balfanz,
Adam Langley, Jeff Hodges, 2016-03-21, <draft-ietf-tokbind-https-03.txt>
This document describes a collection of mechanisms that allow HTTP
servers to cryptographically bind authentication tokens (such as
cookies and OAuth tokens) to a TLS [RFC5246] connection.
We describe both _first-party_ as well as _federated_ scenarios. In
a first-party scenario, an HTTP server issues a security token (such
as a cookie) to a client, and expects the client to send the security
token back to the server at a later time in order to authenticate.
Binding the token to the TLS connection between client and server
protects the security token from theft, and ensures that the security
token can only be used by the client that it was issued to.
Federated token bindings, on the other hand, allow servers to
cryptographically bind security tokens to a TLS [RFC5246] connection
that the client has with a _different_ server than the one issuing
the token.
This Internet-Draft is a companion document to The Token Binding
Protocol [TBPROTO]
"Transport Layer Security (TLS) Extension for Token Binding Protocol
Negotiation", Andrey Popov, Magnus Nystrom, Dirk Balfanz, Adam Langley,
2016-01-08, <draft-ietf-tokbind-negotiation-02.txt>
This document specifies a Transport Layer Security (TLS) [RFC5246]
extension for the negotiation of Token Binding protocol
[I-D.ietf-tokbind-protocol] version and key parameters.
TURN Revised and Modernized (tram)
---------------------------------"TURN Server Auto Discovery", Prashanth Patil, Tirumaleswar Reddy, Dan
Wing, 2016-04-18, <draft-ietf-tram-turn-server-discovery-07.txt>
Current Traversal Using Relays around NAT (TURN) server discovery
mechanisms are relatively static and limited to explicit

configuration. These are usually under the administrative control of

the application or TURN service provider, and not the enterprise,
ISP, or the network in which the client is located. Enterprises and
ISPs wishing to provide their own TURN servers need auto discovery
mechanisms that a TURN client could use with no or minimal
configuration. This document describes three such mechanisms for
TURN server discovery.
"Traversal Using Relays around NAT (TURN): Relay Extensions to Session
Traversal Utilities for NAT (STUN)", Tirumaleswar Reddy, Alan Johnston,
Philip Matthews, Jonathan Rosenberg, 2016-01-10,
<draft-ietf-tram-turnbis-08.txt>
If a host is located behind a NAT, then in certain situations it can
be impossible for that host to communicate directly with other hosts
(peers). In these situations, it is necessary for the host to use
the services of an intermediate node that acts as a communication
relay. This specification defines a protocol, called TURN (Traversal
Using Relays around NAT), that allows the host to control the
operation of the relay and to exchange packets with its peers using
the relay. TURN differs from some other relay control protocols in
that it allows a client to communicate with multiple peers using a
single relay address.
The TURN protocol was designed to be used as part of the ICE
(Interactive Connectivity Establishment) approach to NAT traversal,
though it also can be used without ICE.
"Session Traversal Utilities for NAT (STUN)", Marc Petit-Huguenin,
Gonzalo Salgueiro, Jonathan Rosenberg, Dan Wing, Rohan Mahy, Philip
Matthews, 2016-01-28, <draft-ietf-tram-stunbis-06.txt>
Session Traversal Utilities for NAT (STUN) is a protocol that serves
as a tool for other protocols in dealing with Network Address
Translator (NAT) traversal. It can be used by an endpoint to
determine the IP address and port allocated to it by a NAT. It can
also be used to check connectivity between two endpoints, and as a
keep-alive protocol to maintain NAT bindings. STUN works with many
existing NATs, and does not require any special behavior from them.
STUN is not a NAT traversal solution by itself. Rather, it is a tool
to be used in the context of a NAT traversal solution.
This document obsoletes RFC 5389.
"Discovery of path characteristics using STUN", Tirumaleswar Reddy, Dan
Wing, Paal-Erik Martinsen, Varun Singh, 2016-01-28,
<draft-ietf-tram-stun-path-data-03.txt>
A host with multiple interfaces needs to choose the best interface
for communication. Oftentimes, this decision is based on a static
configuration and does not consider the path characteristics, which
may affect the user experience.
This document describes a mechanism for an endpoint to discover the
path characteristics using Session Traversal Utilities for NAT (STUN)
messages. The measurement information can then be used to influence
the endpoint's Interactive Connectivity Establishment (ICE) candidate
pair selection algorithm.

"Path MTU Discovery Using Session Traversal Utilities for NAT (STUN)",
Marc Petit-Huguenin, Gonzalo Salgueiro, 2016-01-26,
<draft-ietf-tram-stun-pmtud-01.txt>
This document describes a Session Traversal Utilities for NAT (STUN)
usage for Path MTU Discovery (PMTUD) between a client and a server.
"Mobility with TURN", Dan Wing, Prashanth Patil, Tirumaleswar Reddy,
Paal-Erik Martinsen, 2016-04-04, <draft-ietf-tram-turn-mobility-02.txt>
It is desirable to minimize traffic disruption caused by changing IP
address during a mobility event. One mechanism to minimize
disruption is to expose a shorter network path to the mobility event
so only the local network elements are aware of the changed IP
address but the remote peer is unaware of the changed IP address.
This draft provides such an IP address mobility solution using
Traversal Using Relays around NAT (TURN). This is achieved by
allowing a client to retain an allocation on the TURN server when the
IP address of the client changes.
Public Notary Transparency (trans)
----------------------------------"Certificate Transparency", Ben Laurie, Adam Langley, Emilia Kasper,
Eran Messeri, Rob Stradling, 2016-04-11,
<draft-ietf-trans-rfc6962-bis-14.txt>
This document describes a protocol for publicly logging the existence
of Transport Layer Security (TLS) certificates as they are issued or
observed, in a manner that allows anyone to audit certification
authority (CA) activity and notice the issuance of suspect
certificates as well as to audit the certificate logs themselves.
The intent is that eventually clients would refuse to honor
certificates that do not appear in a log, effectively forcing CAs to
add all issued certificates to the logs.
Logs are network services that implement the protocol operations for
submissions and queries that are defined in this document.
"Attack Model and Threat for Certificate Transparency", Stephen Kent,
2016-04-14, <draft-ietf-trans-threat-analysis-05.txt>
This document describes an attack model and discusses threats for
the Web PKI context in which security mechanisms to detect misissuance of web site certificates are being developed. The model
provides an analysis of detection and remediation mechanisms for
both syntactic and semantic mis-issuance. The model introduces an
outline of attacks to organize the discussion. The model also
describes the roles played by the elements of the Certificate
Transparency (CT) system, to establish a context for the model.
"Gossiping in CT", Linus Nordberg, Daniel Kahn Gillmor, Tom Ritter,
2016-03-21, <draft-ietf-trans-gossip-02.txt>
The logs in Certificate Transparency are untrusted in the sense that
the users of the system don't have to trust that they behave
correctly since the behaviour of a log can be verified to be correct.
This document tries to solve the problem with logs presenting a

"split view" of their operations. It describes three gossiping

mechanisms for Certificate Transparency: SCT Feedback, STH
Pollination and Trusted Auditor Relationship.
Transparent Interconnection of Lots of Links (trill)
---------------------------------------------------"TRILL: RBridge Channel Tunnel Protocol", Donald Eastlake, Mohammed
Umair, Li Yizhou, 2016-03-18, <draft-ietf-trill-channel-tunnel-08.txt>
The IETF TRILL (Transparent Interconnection of Lots of Links)
protocol includes an optional mechanism (specified in RFC 7178),
called RBridge Channel, for the transmission of typed messages
between TRILL switches in the same campus and the transmission of
such messages between TRILL switches and end stations on the same
link. This document specifies two optional extensions to the RBridge
Channel protocol: (1) a standard method to tunnel a variety of
payload types by encapsulating them in an RBridge Channel message;
and (2) a method to support security facilities for RBridge Channel
messages. This document updates RFC 7178.
"TRILL: Interface Addresses APPsub-TLV", Donald Eastlake, Li Yizhou,
2016-02-09, <draft-ietf-trill-ia-appsubtlv-07.txt>
This document specifies a TRILL (Transparent Interconnection of Lots
of Links) IS-IS application sub-TLV that enables the reporting by a
TRILL switch of sets of addresses. Each set of addresses reports all
of the addresses that designate the same interface (port) and also
reports the TRILL switch by which that interface is reachable. For
example, a 48-bit MAC (Media Access Control) address, IPv4 address,
and IPv6 address can be reported as all corresponding to the same
interface reachable by a particular TRILL switch. Such information
could be used in some cases to synthesize responses to or by-pass the
need for the Address Resolution Protocol (ARP), the IPv6 Neighbor
Discovery (ND) protocol, or the flooding of unknown MAC addresses.
"TRILL Resilient Distribution Trees", Mingui Zhang, Tissa Senevirathne,
Janardhanan Pathangi, Ayan Banerjee, Anoop Ghanwani, 2015-12-30,
<draft-ietf-trill-resilient-trees-04.txt>
TRILL protocol provides multicast data forwarding based on IS-IS link
state routing. Distribution trees are computed based on the link
state information through Shortest Path First calculation. When a
link on the distribution tree fails, a campus-wide reconvergence of
this distribution tree will take place, which can be time consuming
and may cause considerable disruption to the ongoing multicast
service.
This document specifies how to build backup distribution trees to
protect links on the primary distribution tree. Since the backup
distribution tree is built up ahead of the link failure, when a link
on the primary distribution tree fails, the pre-installed backup
forwarding table will be utilized to deliver multicast packets
without waiting for the campus-wide reconvergence. This minimizes the
service disruption. This document updates RFC 6325.
"TRILL: Edge Directory Assist Mechanisms", Donald Eastlake, Linda
Dunbar, Radia Perlman, Li Yizhou, 2016-02-03,
<draft-ietf-trill-directory-assist-mechanisms-07.txt>

This document describes mechanisms for providing directory service to

TRILL (Transparent Interconnection of Lots of Links) edge switches.
The directory information provided can be used in reducing multidestination traffic, particularly ARP/ND and unknown unicast
flooding. It can also be used to detect traffic with forged source
addresses.
"TRILL (Transparent Interconnection of Lots of Links) over IP", Margaret
Cullen, Donald Eastlake, Mingui Zhang, Dacheng Zhang, 2016-04-17,
<draft-ietf-trill-over-ip-06.txt>
The TRILL (Transparent Interconnection of Lots of Links) protocol
supports both point-to-point and multi-access links and is designed
so that a variety of link protocols can be used between TRILL switch
ports. This document standardizes methods for encapsulating TRILL in
IP (v4 or v6) so as to use IP as a TRILL link protocol in a unified
TRILL campus. It updates RFC 7177 and updates RFC 7178.
"TRILL Distributed Layer 3 Gateway", Hao Weiguo, Li Yizhou, Andrew Qu,
Muhammad Durrani, Ponkarthick Sivamurugan, Liang Xia, 2016-05-03,
<draft-ietf-trill-irb-12.txt>
The base TRILL protocol provides optimal pair-wise data frame
forwarding for layer 2 intra-subnet traffic but not for layer 3
inter-subnet traffic. A centralized gateway solution is typically
used for layer 3 inter-subnet traffic forwarding but has the
following issues:
"TRILL Smart Endnodes", Radia Perlman, fangwei hu, Donald Eastlake,
Kesava Krupakaran, Ting Liao, 2016-02-16,
<draft-ietf-trill-smart-endnodes-03.txt>
This draft addresses the problem of the size and freshness of the
endnode learning table in edge RBridges, by allowing endnodes to
volunteer for endnode learning and encapsulation/decapsulation. Such
an endnode is known as a "Smart Endnode". Only the attached RBridge
can distinguish a "Smart Endnode" from a "normal endnode". The smart
endnode uses the nickname of the attached RBridge, so this solution
does not consume extra nicknames. The solution also enables Fine
Grained Label aware endnodes.
"Directory Assisted TRILL Encapsulation", Linda Dunbar, Donald Eastlake,
Radia Perlman, Igor Gashinsky, 2016-02-19,
<draft-ietf-trill-directory-assisted-encap-02.txt>
This draft describes how data center networks can benefit from nonRBridge nodes performing TRILL encapsulation with assistance from a
directory service.
"Centralized Replication for Active-Active BUM Traffic", Hao Weiguo, Li
Yizhou, Muhammad Durrani, Sujay Gupta, Andrew Qu, Tao Han, 2016-03-07,
<draft-ietf-trill-centralized-replication-05.txt>
In TRILL active-active access, an RPF check failure issue may occur
when using the pseudo-nickname mechanism specified in RFC 7781. This
draft describes a solution to resolve this RPF check failure issue
through centralized replication. All ingress RBridges send BUM
(Broadcast, Unknown unicast and Mutlicast) traffic to a centralized
node with unicast TRILL encapsulation. When the centralized node
receives the BUM traffic, it decapsulates the packets and forwards

them to all destination RBridges using a distribution tree

established as per TRILL base protocol RFC 6325. To avoid RPF check
failure on a RBridge sitting between the ingress RBridge and the
centralized replication node, some change in the RPF calculation
algorithm is required. RPF calculation on each RBridge should use
the centralized node as the ingress RBridge, instead of the real
ingress RBridge, which is denoted as RBv in RFC 7781, to perform the
calculation.
"TRILL YANG Data Model", Hao Weiguo, Li Yizhou, Deepak Kumar, Muhammad
Durrani, Hongjun Zhai, Liang Xia, 2015-12-20,
<draft-ietf-trill-yang-04.txt>
This document defines a YANG data model for TRILL protocol.
"Transparent Interconnection of Lots of Links (TRILL): MTU Negotiation",
Mingui Zhang, Xudong Zhang, Donald Eastlake, Radia Perlman, Somnath
Chatterjee, 2016-05-02, <draft-ietf-trill-mtu-negotiation-03.txt>
The base IETF TRILL protocol has a TRILL campus-wide MTU feature,
specified in RFC 6325 and RFC 7177, that assures that link state
changes can be successfully flooded throughout the campus while being
able to take advantage of a campus-wide capability to support jumbo
packets. This document specifies optional updates to that MTU feature
to take advantage, for appropriate link-local packets, of link-local
MTUs that exceed the TRILL campus MTU. In addition, it specifies an
efficient algorithm for local MTU testing.
"TRILL: ARP/ND Optimization", Li Yizhou, Donald Eastlake, Linda Dunbar,
Radia Perlman, 2016-04-22, <draft-ietf-trill-arp-optimization-06.txt>
This document describes mechanisms to optimize the ARP (Address
Resolution Protocol) and ND (Neighbor Discovery) traffic in TRILL
campus. Such optimization reduces packet flooding over a TRILL
campus.
"TRILL: Data Label based Tree Selection for Multi-destination Data", Li
Yizhou, Donald Eastlake, Hao Weiguo, Hao Chen, Somnath Chatterjee,
2016-04-11, <draft-ietf-trill-tree-selection-04.txt>
TRILL uses distribution trees to deliver multi-destination frames.
Multiple trees can be used by an ingress RBridge for flows regardless
of the VLAN, Fine Grained Label (FGL), and/or multicast group of the
flow. Different ingress RBridges may choose different distribution
trees for TRILL Data packets in the same VLAN, FGL, and/or multicast
group. To avoid unnecessary link utilization, distribution trees
should be pruned based on VLAN and/or FGL and/or multicast
destination address. If any VLAN, FGL, or multicast group can be sent
on any tree, for typical fast path hardware, the amount of pruning
information is multiplied by the number of trees, but there is a
limited hardware capacity for such pruning information.
This document specifies an optional facility to restrict the TRILL
Data packets sent on particular distribution trees by VLAN, FGL,
and/or multicast group thus reducing the total amount of pruning
information so that it can more easily be accommodated by fast path
hardware.
"TRILL Support of Point to Multipoint BFD", Mingui Zhang, Juniper
Networks, Vengada Govindan, 2015-12-02,

<draft-ietf-trill-p2mp-bfd-01.txt>
Point to multipoint (P2MP) BFD is designed to verify multipoint
connectivity. This document specifies the support of P2MP BFD in
TRILL. Similar to TRILL point-to-point BFD, BFD Control packets in
TRILL P2MP BFD are transmitted using RBridge Channel message.
"Alternatives for Multilevel TRILL (Transparent Interconnection of Lots
of Links)", Radia Perlman, Donald Eastlake, Mingui Zhang, Anoop
Ghanwani, Hongjun Zhai, 2016-04-19,
<draft-ietf-trill-rbridge-multilevel-02.txt>
Extending TRILL to multiple levels has challenges that are not
addressed by the already-existing capability of IS-IS to have
multiple levels. One issue is with the handling of multi-destination
packet distribution trees. Another issue is with TRILL switch
nicknames. There have been two proposed approaches. One approach,
which we refer to as the "unique nickname" approach, gives unique
nicknames to all the TRILL switches in the multilevel campus, either
by having the level-1/level-2 border TRILL switches advertise which
nicknames are not available for assignment in the area, or by
partitioning the 16-bit nickname into an "area" field and a "nickname
inside the area" field. The other approach, which we refer to as the
"aggregated nickname" approach, involves hiding the nicknames within
areas, allowing nicknames to be reused in different areas, by having
the border TRILL switches rewrite the nickname fields when entering
or leaving an area. Each of those approaches has advantages and
disadvantages. This informational document suggests allowing a choice
of approach in each area. This allows the simplicity of the unique
nickname approach in installations in which there is no danger of
running out of nicknames and allows the complexity of hiding the
nicknames in an area to be phased into larger installations on a perarea basis.
"Transparent Interconnection of Lots of Links (TRILL) Single Area Border
RBridge Nickname for Multilevel", Mingui Zhang, Donald Eastlake, Radia
Perlman, Margaret Cullen, Hongjun Zhai, 2016-02-15,
<draft-ietf-trill-multilevel-single-nickname-01.txt>
A major issue in multilevel TRILL is how to manage RBridge nicknames.
In this document, the area border RBridge uses a single nickname in
both Level 1 and Level 2. RBridges in Level 2 must obtain unique
nicknames but RBridges in different Level 1 areas may have the same
nicknames.
"TRILL: Multi-Topology", Donald Eastlake, Mingui Zhang, Ayan Banerjee,
Vishwas Manral, 2016-02-28, <draft-ietf-trill-multi-topology-01.txt>
This document specifies extensions to the IETF TRILL (Transparent
Interconnection of Lots of Links) protocol to support multi-topology
routing of unicast and multi-destination traffic based on IS-IS
(Intermediate System to Intermediate System) multi-topology specified
in RFC 5120. This document updates RFC 6325 and RFC 7177.
"TRILL: Appointed Forwarders", Donald Eastlake, Li Yizhou, Mohammed
Umair, Ayan Banerjee, fangwei hu, 2016-01-05,
<draft-ietf-trill-rfc6439bis-01.txt>
TRILL supports multi-access LAN (Local Area Network) links where a
single link can have multiple end stations and TRILL switches

attached. Where multiple TRILL switches are attached to a link,

native traffic to and from end stations on that link is handled by a
subset of those TRILL switches called "Appointed Forwarders", with
the intent that native traffic in each VLAN be handled by at most one
TRILL switch. This document clarifies and updates the Appointed
Forwarder mechanism. It updates RFC 6325, updates RFC 7177, and
obsoletes RFC 6439.
"Data Center Interconnect using TRILL", Mohammed Umair, Kingston Smiler,
Shaji Ravindranathan, Lucy Yong, Donald Eastlake, 2016-02-24,
<draft-ietf-trill-dci-00.txt>
This document describes a TRILL based Data Center Interconnect (DCI)
solution. TRILL is predominantly used inside a data center for
providing intra-data center switching optimally by utilizing multiple
links. This draft described a way to use TRILL to extend a network
across different data center via MPLS service provider network using
Virtual TRILL Service/Switch Domain (VTSD) as described in draft
[VTSD].
"TRILL Transparent Transport over MPLS", Mohammed Umair, Kingston
Smiler, Donald Eastlake, Lucy Yong, 2016-03-10,
<draft-ietf-trill-transport-over-mpls-00.txt>
This document specifies how to interconnect multiple Transparent
Interconnection of Lots of links (TRILL) sites with an intervening
MPLS network using existing TRILL and VPLS standards. This draft
addresses two problems as follows:
1) Providing connection between more than two TRILL sites that
are separated by MPLS provider network.
2) Providing a single logical virtualized TRILL network for
different tenants that are separated by an MPLS provider network.
Transport Area (tsv)
-------------------"QUIC: A UDP-Based Secure and Reliable Transport for HTTP/2", Ryan
Hamilton, Jana Iyengar, Ian Swett, Alyssa Wilk, 2016-01-13,
<draft-tsvwg-quic-protocol-02.txt>
QUIC (Quick UDP Internet Connection) is a new multiplexed and secure
transport atop UDP, designed from the ground up and optimized for
HTTP/2 semantics. While built with HTTP/2 as the primary application
protocol, QUIC builds on decades of transport and security
experience, and implements mechanisms that make it attractive as a
modern general-purpose transport. QUIC provides multiplexing and
flow control equivalent to HTTP/2, security equivalent to TLS, and
connection semantics, reliability, and congestion control equivalent
to TCP.
"QUIC Loss Recovery And Congestion Control", Jana Iyengar, Ian Swett,
2015-12-18, <draft-tsvwg-quic-loss-recovery-01.txt>
QUIC (Quick UDP Internet Connection) is a new multiplexed and secure
transport atop UDP, designed from the ground up and optimized for
HTTP/2 semantics. While built with HTTP/2 as the primary application
protocol, QUIC builds on decades of transport and security
experience, and implements mechanisms that make it attractive as a

modern general-purpose transport. QUIC implements the spirit of

known TCP loss recovery mechanisms, described in RFCs, various
Internet-drafts, and also those prevalent in the Linux TCP
implementation. This document describes QUIC loss recovery, and
where applicable, attributes the TCP equivalent in RFCs, Internetdrafts, academic papers, and/or TCP implementations.
"Interface Extensions for TCP-ENO", Andrea Bittau, Dan Boneh, Daniel
Giffin, Mark Handley, David Mazieres, Eric Smith, 2016-03-02,
<draft-bittau-tcpinc-api-01.txt>
TCP-ENO negotiates encryption at the transport layer. It also
defines a few parameters that are intended to be used or configured
by applications. This document specifies operating system interfaces
for access to these TCP-ENO parameters. We describe the interfaces
in terms of socket options, the de facto standard API for adjusting
per-connection behavior in TCP/IP, and sysctl, a popular mechanism
for setting global defaults. Operating systems that lack socket or
sysctl functionality can implement similar interfaces in their native
frameworks, but should ideally adapt their interfaces from those
presented in this document.
Transport Area Working Group (tsvwg)
-----------------------------------"DTLS Encapsulation of SCTP Packets", Michael Tuexen, Randall Stewart,
Randell Jesup, Salvatore Loreto, 2015-01-24,
<draft-ietf-tsvwg-sctp-dtls-encaps-09.txt>
The Stream Control Transmission Protocol (SCTP) is a transport
protocol originally defined to run on top of the network protocols
IPv4 or IPv6. This document specifies how SCTP can be used on top of
the Datagram Transport Layer Security (DTLS) protocol. Using the
encapsulation method described in this document, SCTP is unaware of
the protocols being used below DTLS; hence explicit IP addresses
cannot be used in the SCTP control chunks. As a consequence, the
SCTP associations carried over DTLS can only be single homed.
"GRE-in-UDP Encapsulation", Lucy Yong, Edward Crabbe, Xiaohu Xu, Tom
Herbert, 2016-03-10, <draft-ietf-tsvwg-gre-in-udp-encap-11.txt>
This document describes a method of encapsulating network protocol
packets within GRE and UDP headers. The GRE-in-UDP encapsulation
allows the UDP source port field to be used as an entropy field.
This may be used for load balancing of GRE traffic in transit
networks using existing ECMP mechanisms. This document specifies
GRE-in-UDP tunnel requirements for two applicability scenarios: (1)
general Internet; (2) a traffic-managed controlled environment. The
controlled environment has less restrictive requirements than the
general Internet.
"Stream Schedulers and User Message Interleaving for the Stream Control
Transmission Protocol", Randall Stewart, Michael Tuexen, Salvatore
Loreto, Robin Seggelmann, 2016-03-21,
<draft-ietf-tsvwg-sctp-ndata-05.txt>
The Stream Control Transmission Protocol (SCTP) is a message oriented
transport protocol supporting arbitrary large user messages.
However, the sender can not interleave different user messages which
causes head of line blocking at the sender side. To overcome this

limitation, this document adds a new data chunk to SCTP.

Whenever an SCTP sender is allowed to send a user data, it can
possibly choose from multiple outgoing SCTP streams. Multiple ways
for this selection, called stream schedulers, are defined. Some of
them don't require the support of user message interleaving, some do.
"Guidelines for Adding Congestion Notification to Protocols that
Encapsulate IP", Bob Briscoe, John Kaippallimalil, Patricia Thaler,
2016-03-21, <draft-ietf-tsvwg-ecn-encap-guidelines-05.txt>
The purpose of this document is to guide the design of congestion
notification in any lower layer or tunnelling protocol that
encapsulates IP. The aim is for explicit congestion signals to
propagate consistently from lower layer protocols into IP. Then the
IP internetwork layer can act as a portability layer to carry
congestion notification from non-IP-aware congested nodes up to the
transport layer (L4). Following these guidelines should assure
interworking between new lower layer congestion notification
mechanisms, whether specified by the IETF or other standards bodies.
"DSCP and other packet markings for WebRTC QoS", Paul Jones, Subha
Dhesikan, Cullen Jennings, Dan Druta, 2016-03-18,
<draft-ietf-tsvwg-rtcweb-qos-15.txt>
Many networks, such as service provider and enterprise networks, can
provide different forwarding treatments for individual packets based
on Differentiated Services Code Point (DSCP) values on a per-hop
basis. This document provides the recommended DSCP values for web
browsers to use for various classes of WebRTC traffic.
"Network Transport Circuit Breakers", Gorry Fairhurst, 2016-04-04,
<draft-ietf-tsvwg-circuit-breaker-15.txt>
This document explains what is meant by the term "network transport
Circuit Breaker" (CB). It describes the need for circuit breakers
for network tunnels and applications when using non-congestioncontrolled traffic, and explains where circuit breakers are, and are
not, needed. It also defines requirements for building a circuit
breaker and the expected outcomes of using a circuit breaker within
the Internet.
"Diffserv-Interconnection classes and practice", Ruediger Geib, David
Black, 2016-04-05, <draft-ietf-tsvwg-diffserv-intercon-05.txt>
This document proposes a limited common set of Diffserv PHBs and
codepoints (DSCPs) to be applied at (inter)connections of two
separately administered and operated networks, and explains how this
approach can simplify network configuration and operation. Many
network providers operate MPLS using Treatment Aggregates for traffic
marked with different Diffserv PHBs, and use MPLS for interconnection
with other networks. This document offers a simple interconnection
approach that may simplify operation of Diffserv for network
interconnection among providers that use MPLS and apply the ShortPipe tunnel mode.
"UDP Usage Guidelines", Lars Eggert, Gorry Fairhurst, Greg Shepherd,
2016-05-03, <draft-ietf-tsvwg-rfc5405bis-12.txt>
The User Datagram Protocol (UDP) provides a minimal message-passing

transport that has no inherent congestion control mechanisms. This

document provides guidelines on the use of UDP for the designers of
applications, tunnels and other protocols that use UDP. Congestion
control guidelines are a primary focus, but the document also
provides guidance on other topics, including message sizes,
reliability, checksums, middlebox traversal, the use of ECN, DSCPs,
and ports.
Because congestion control is critical to the stable operation of the
Internet, applications and other protocols that choose to use UDP as
an Internet transport must employ mechanisms to prevent congestion
collapse and to establish some degree of fairness with concurrent
traffic. They may also need to implement additional mechanisms,
depending on how they use UDP.
Some guidance is also applicable to the design of other protocols
(e.g., protocols layered directly on IP or via IP-based tunnels),
especially when these protocols do not themselves provide congestion
control.
This document obsoletes RFC5405 and adds guidelines for multicast UDP
usage.
"Tunnel Congestion Feedback", Xinpeng Wei, Lei Zhu, Lingli Deng,
2015-11-30, <draft-ietf-tsvwg-tunnel-congestion-feedback-01.txt>
This document describes a mechanism to calculate congestion of a
tunnel segment based on RFC6040 recommendations, and a feedback
protocol by which to send the measured congestion of the tunnel from
egress to ingress . A basic model for measuring tunnel congestion
and feedback is described, and a protocol for carrying the feedback
data is outlined.
Uniform Resource Names, Revised (urnbis)
---------------------------------------"Uniform Resource Names (URNs)", Peter Saint-Andre, John Klensin,
2016-04-17, <draft-ietf-urnbis-rfc2141bis-urn-16.txt>
A Uniform Resource Name (URN) is a Uniform Resource Identifier (URI)
that is assigned under the "urn" scheme and a particular URN
namespace, with the intent that the URN will be either a persistent,
location-independent resource identifier or in some cases an abstract
designator that is persistent but that does not identify a resource.
With regard to URN syntax, this document defines the canonical syntax
for URNs (in a way that is consistent with URI syntax), specifies
methods for determining URN equivalence, and discusses URI
conformance. With regard to URN namespaces, this document specifies
a method for defining a URN namespace and associating it with a
namespace identifier, and describes procedures for registering
namespace identifiers with the Internet Assigned Numbers Authority
(IANA). This document obsoletes both RFC 2141 and RFC 3406.
"Uniform Resource Name (URN) Namespace Registration Transition", John
Klensin, Juna Hakala, 2016-02-07,
<draft-ietf-urnbis-ns-reg-transition-06.txt>
The original registration procedure for formal Uniform Resource Name
(URN) namespaces required IETF Consensus. That requirement
discouraged some registrations and increased the risk for problems

that could occur as a result. The requirements have now been changed
in [[RFC 2141bis]]. That document adopts a different model. This
document specifies IANA instructions to adapt selected existing
registrations to the new model. It also obsoletes some previous RFCs
to eliminate any ambiguity about the status of new templates and
updated registrations.
"URN Semantics Clarification", John Klensin, 2016-02-06,
<draft-ietf-urnbis-semantics-clarif-03.txt>
Experience has shown that identifiers associated with persistent
names have properties and requirements that may be somewhat different
from identifiers associated with the locations of objects. This is
especially true when such names are expected to be stable for a very
long time or when they identify large and complex entities. In order
to allow Uniform Resource Names (URNs) to evolve to meet the needs of
the Library, Museum, Publisher, and Information Science communities
and other users, this specification separates URNs from the semantic
constraints that many people believe are part of the specification
for Uniform Resource Identifiers (URIs) in RFC 3986, updating that
document accordingly. The syntax of URNs is still constrained to
that of RFC 3986, so generic URI parsers are unaffected by this
change.
Using TLS in Applications (uta)
------------------------------"Deployable Enhanced Email Privacy (DEEP)", Keith Moore, Chris Newman,
2016-03-17, <draft-ietf-uta-email-deep-04.txt>
This specification defines a set of requirements and facilities
designed to improve email confidentiality between a mail user agent
(MUA) and a mail submission or mail access server. This provides
mechanisms intended to increase use of already deployed Transport
Layer Security (TLS) technology, provide a model for mail user
agent's confidentiality assurance, and enable mail service providers
to advertise improved TLS confidentiality facilities.
IPv6 Operations (v6ops)
----------------------"DHCPv6/SLAAC Interaction Problems on Address and DNS Configuration",
Bing Liu, Sheng Jiang, Xiangyang Gong, Wendong Wang, Enno Rey,
2016-02-06, <draft-ietf-v6ops-dhcpv6-slaac-problem-06.txt>
The IPv6 Neighbor Discovery (ND) Protocol includes an ICMPv6 Router
Advertisement (RA) message. The RA message contains three flags,
indicating the availability of address auto-configuration mechanisms
and other configuration such as DNS-related configuration. These are
the M, O, and A flags, which by definition are advisory, not
prescriptive.
This document describes divergent host behaviors observed in popular
operating systems. It also discusses operational problems that the
divergent behaviors might cause.
"Observations on the Dropping of Packets with IPv6 Extension Headers in
the Real World", Fernando Gont, J. Linkova, Tim Chown, Shucheng LIU,
2015-12-11, <draft-ietf-v6ops-ipv6-ehs-in-real-world-02.txt>

This document presents real-world data regarding the extent to which

packets with IPv6 extension headers are dropped in the Internet (as
originally measured in August 2014 and later in June 2015, with
similar results), and where in the network such dropping occurs. The
aforementioned results serve as a problem statement that is expected
to trigger operational advice on the filtering of IPv6 packets
carrying IPv6 Extension Headers, so that the situation improves over
time. This document also explains how the aforementioned results
were obtained, such that the corresponding measurements can be
reproduced by other members of the community and repeated over time
to observe changes in the handling of packets with IPv6 extension
headers.
"Host address availability recommendations", Lorenzo Colitti, Vinton
Cerf, Stuart Cheshire, David Schinazi, 2016-03-09,
<draft-ietf-v6ops-host-addr-availability-06.txt>
This document recommends that networks provide general-purpose end
hosts with multiple global IPv6 addresses when they attach, and
describes the benefits of and the options for doing so.
"Considerations For Using Unique Local Addresses", Bing Liu, Sheng
Jiang, 2016-02-08, <draft-ietf-v6ops-ula-usage-considerations-00.txt>
This document provides considerations for using IPv6 Unique Local
Addresses (ULAs). Based on an analysis of different ULA usage
scenarios, this document identifies use cases where ULA addresses are
helpful as well as potential problems caused by using them,
Web-Based Push Notifications (webpush)
-------------------------------------"Generic Event Delivery Using HTTP Push", Martin Thomson, Elio Damaggio,
Brian Raymor, 2016-03-21, <draft-ietf-webpush-protocol-04.txt,.pdf>
A simple protocol for the delivery of realtime events to user agents
is described. This scheme uses HTTP/2 server push.
"Message Encryption for Web Push", Martin Thomson, 2016-03-20,
<draft-ietf-webpush-encryption-02.txt>
A message encryption scheme is described for the Web Push protocol.
This scheme provides confidentiality and integrity for messages sent
from an Application Server to a User Agent.
"Voluntary Application Server Identification for Web Push", Martin
Thomson, Peter Beverloo, 2016-04-13, <draft-ietf-webpush-vapid-00.txt>
An application server can voluntarily identify itself to a push
service using the described technique. This identification
information can be used by the push service to attribute requests
that are made by the same application server to a single entity.
This can used to reduce the secrecy for push subscription URLs by
being able to restrict subscriptions to a specific application
server. An application server is further able include additional
information the operator of a push service can use to contact the
operator of the application server.
Metric Blocks for use with RTCP's Extended Report Framework (xrblock)
---------------------------------------------------------------------

"Considerations for Selecting RTCP Extended Report (XR) Metrics for the
WebRTC Statistics API", Varun Singh, Rachel Huang, Roni Even, Dan
Romascanu, Deng Lingli, 2016-03-21,
<draft-ietf-xrblock-rtcweb-rtcp-xr-metrics-03.txt,.pdf>
This document describes monitoring features related to media streams
in Web real-time communication (WebRTC). It provides a list of RTCP
Sender Report, Receiver Report and Extended Report metrics, which may
need to be supported by RTP implementations in some diverse
environments. It also defines a new IANA registry, a list of
identifiers for the WebRTC's statistics API. These identifiers are a
set of RTCP SR, RR, and XR metrics related to the transport of
multimedia flows.
"RTCP XR Report Block for Loss Concealment Metrics Reporting on Video
Applications", Rachel Huang, 2016-03-30,
<draft-ietf-xrblock-rtcp-xr-video-lc-06.txt>
This document defines a new RTCP XR Report Block that allows the
reporting of loss concealment metrics for video applications of RTP.
"RTP Control Protocol (RTCP) Extended Report (XR) Block for Independent
Reporting of Burst/Gap Discard Metric", Varun, Colin Perkins, Alan
Clark, Rachel Huang, 2016-03-21,
<draft-ietf-xrblock-independent-burst-gap-discard-01.txt,.pdf>
This document defines an RTP Control Protocol (RTCP) Extended Report
(XR) block that allows the reporting of burst and gap discard metrics
independently of the burst and gap loss metrics for use in a range of
RTP applications.