The Daily Dose of IETF - Issue 2892

YANG subscribed notifications via SACM Statements (draft-birkholz-sacm-yang-content)

By Henk Birkholz, Nancy Cam-Winget, 2017-07-19 TXT HTML PDF

Abstract: This document summarizes the data model designed at the IETF 99 Hackathon and is intended to grow in to a definition of general XML SACM statements (and later JSON and CBOR, respectively) for virtually every kind of Content Element (e.g. software identifiers, assessment guidance/results, ECA Policy rules, VDD, etc.). The SACM Statement data structure is based on the Information Element (IE) definitions provided by the SACM Information Model. The initial Content Element type transferred are YANG Subscribed Notification acquired via YANG push. In combination with the Origin Metadata Annotation defined in draft-ietf-netmod-revised-datastores the data model defined in this document will ultimately be able to express collected endpoint characteristics, imperative guidance that define and orchestrate assessment instructions, and also the declarative guidance for endpoint attributes.
BGP for Communications among Controllers (draft-chen-idr-com-cntlrs)

By Huaimo Chen, Susan Hares, Yi Yang, Yanhe Fan, Mehmet Toy, Zhenqiang Li, Lei Liu, 2017-07-20 TXT HTML PDF

Abstract: 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.

Diff from 01 to 02 »
IS-IS Topology-Transparent Zone (draft-chen-isis-ttz)

By Huaimo Chen, Renwei Li, Alvaro Retana, So Ning, Vic liu, Mehmet Toy, Lei Liu, 2017-07-20 TXT HTML PDF

Abstract: This document presents a topology-transparent zone in a domain. A zone comprises a group of routers and a number of circuits connecting them. Any router outside of the zone is not aware of the zone. The information about the circuits and routers inside the zone is not distributed to any router outside of the zone. Any link state change such as a circuit down inside the zone is not seen by any router outside of the zone.

Diff from 03 to 04 »
OSPF Abnormal State Information (draft-chen-ospf-abnormal-state-info)

By Huaimo Chen, 2017-07-20 TXT HTML PDF

Abstract: This document describes a couple of options for an OSPF router to advertise its abnormal state information in a routing domain.

Diff from 00 to 01 »
Extensions to OSPF for Temporal LSP (draft-chen-ospf-tts)

By Huaimo Chen, Mehmet Toy, Vic liu, Lei Liu, 2017-07-20 TXT HTML PDF

Abstract: This document specifies extensions to OSPF for distributing Traffic Engineering (TE) information on a link in a sequence of time intervals.

Diff from 01 to 02 »
Extensions to MPLS for Temporal LSP (draft-chen-teas-rsvp-tts)

By Huaimo Chen, Mehmet Toy, Vic liu, Lei Liu, 2017-07-20 TXT HTML PDF

Abstract: This document specifies extensions to RSVP-TE for creating and maintaining a Traffic Engineering (TE) Label Switched Path (LSP) in a time interval or a sequence of time intervals.

Diff from 01 to 02 »
Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO (draft-ietf-alto-cdni-request-routing-alto)

By Jan Seedorf, Yang Yang, Kevin Ma, Jon Peterson, 2017-07-20 TXT HTML PDF

Abstract: The Content Delivery Networks Interconnection (CDNI) WG is defining a set of protocols to inter-connect CDNs, to achieve multiple goals such as extending the reach of a given CDN to areas that are not covered by that particular CDN. One componet that is needed to achieve the goal of CDNI is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI) [RFC7336]. [RFC8008] has defined precisely the semantics of FCI and provided guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. In this document, we define an FCI protocol using the Application Layer Traffic Optimization (ALTO) protocol.

Document details »
ALTO WG »
Extensible Property Maps for the ALTO Protocol (draft-ietf-alto-unified-props-new)

By Wendy Roome, Yang Yang, 2017-07-20 TXT HTML PDF

Abstract: This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to other entity domains, and by presenting those properties as maps, similar to the network and cost maps in ALTO.

Document details »
ALTO WG »
Advertising Segment Routing Policies in BGP (draft-ietf-idr-segment-routing-te-policy)

By Stefano Previdi, Clarence Filsfils, Paul Mattes, Eric Rosen, Steven Lin, 2017-07-20 TXT HTML PDF

Abstract: This document defines a new BGP SAFI with a new NLRI in order to advertise a candidate path of a Segment Routing Policy (SR Policy). An SR Policy is a set of candidate paths consisting of one or more segment lists. The headend of an SR Policy may learn multiple candidate paths for an SR Policy. Candidate paths may be learned via a number of different mechanisms, e.g., CLI, NetConf, PCEP, or BGP. This document specifies the way in which BGP may be used to distribute candidate paths. New sub-TLVs for the Tunnel Encapsulation Attribute are defined.

Document details »
IDR WG »
Requirements for pNFS Layout Types (draft-ietf-nfsv4-layout-types)

By Thomas Haynes, 2017-07-19 TXT HTML PDF

Abstract: This document defines the requirements which individual pNFS layout types need to meet in order to work within the parallel NFS (pNFS) framework as defined in RFC5661. In so doing, it aims to more clearly distinguish between requirements for pNFS as a whole 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. In this regard, this document effectively updates RFC5661.

Diff from 04 to 05 »
Document details »
NFSV4 WG »
RPKI Certificate Tree Validation by the RIPE NCC RPKI Validator (draft-ietf-sidrops-rpki-tree-validation)

By Oleg Muravskiy, Tim Bruijnzeels, 2017-07-20 TXT HTML PDF

Abstract: This document describes the approach to validate the content of the RPKI certificate tree, as it is implemented in 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.

Diff from 00 to 01 »
Document details »
SIDROPS WG »
Considerations for Selecting RTCP Extended Report (XR) Metrics for the WebRTC Statistics API (draft-ietf-xrblock-rtcweb-rtcp-xr-metrics)

By Varun Singh, Rachel Huang, Roni Even, Dan Romascanu, Deng Lingli, 2017-07-20 TXT HTML PDF

Abstract: 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 lists a set 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.

Diff from 05 to 06 »
Document details »
XRBLOCK WG »
Continuous DAD implementation in Solaris (draft-varadhan-continuous-dad)

By Sowmini Varadhan, 2017-07-20 TXT HTML PDF

Abstract: This describes an implementation of IPv6 Duplicate Address Detection (DAD) in Solaris that merges concepts from RFC 5227 to address some of the known issues around DAD robustness and efficiency.

Updated Drafts

Algorithm Negotiation in DNSSEC (draft-huque-dnssec-alg-nego)

By Shumon Huque, Haya Shulman, Shane Kerr, 2017-07-20 TXT HTML PDF

Abstract: This document specifies a DNS extension that allows a DNS client to specify a list of DNSSEC algorithms, in preference order, that the client desires to use. A DNS server upon receipt of this extension can choose to selectively respond with DNSSEC signatures using the most preferred algorithm they support. This mechanism may make it easier for DNS zone operators to support signing zone data simultaneously with multiple DNSSEC algorithms, without significantly increasing the size of DNS responses. It will also allow an easier way to transition to new algorithms while still retaining support for older DNS validators that do not yet support the new algorithms.

Diff from 00 to 01 »
IPv6 Segment Routing Header (SRH) (draft-ietf-6man-segment-routing-header)

By Stefano Previdi, Clarence Filsfils, Kamran Raza, John Leddy, Brian Field, [email protected], [email protected], Satoru Matsushima, Ida Leung, J. Linkova, Ebben Aries, Tomoya Kosugi, Eric Vyncke, David Lebrun, Dirk Steinberg, Robert Raszuk, 2017-07-20 TXT HTML PDF

Abstract: 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.

Diff from 06 to 07 »
Document details »
6MAN WG »
Use cases for DDoS Open Threat Signaling (draft-ietf-dots-use-cases)

By Roland Dobbins, Daniel Migault, Stefan Fouant, Robert Moskowitz, Nik Teague, Liang Xia, Kaname Nishizuka, 2017-07-20 TXT HTML PDF

Abstract: The DDoS Open Threat Signaling (DOTS) effort is intended to provide a protocol that facilitates interoperability between multivendor solutions/services. This document presents use cases to evaluate the interactions expected between the DOTS components as well as DOTS messaging exchanges. The purpose of describing use cases is to identify the interacting DOTS components, how they collaborate and what are the types of information to be exchanged.

Diff from 06 to 07 »
Document details »
DOTS WG »
Using Simulcast in SDP and RTP Sessions (draft-ietf-mmusic-sdp-simulcast)

By Bo Burman, Magnus Westerlund, Suhas Nandakumar, Mo Zanaty, 2017-07-20 TXT HTML PDF

Abstract: 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.

Diff from 09 to 10 »
Document details »
MMUSIC WG »
Parallel NFS (pNFS) Flexible File Layout (draft-ietf-nfsv4-flex-files)

By Benny Halevy, Thomas Haynes, 2017-07-20 TXT HTML PDF

Abstract: 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 which allows 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.

Diff from 11 to 12 »
Document details »
NFSV4 WG »
Allowing Inheritable NFSv4 Access Control Entries to Override the Umask (draft-ietf-nfsv4-umask)

By J. Fields, Andreas Gruenbacher, 2017-07-20 TXT HTML PDF

Abstract: In many environments, inheritable NFSv4 Access Control Entries (ACEs) can be rendered ineffective by the application of the per-process umask. This can be addressed by transmitting the umask and create mode as separate pieces of data, allowing the server to make more intelligent decisions about the permissions to set on new files. This document proposes a protocol extension which accomplishes that.

Diff from 03 to 04 »
State: Approved-announcement to be sent::Point Raised - writeup needed
ID Tracker » ATOM
Document details »
NFSV4 WG »
The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) (draft-ietf-oauth-jwsreq)

By Nat Sakimura, John Bradley, 2017-07-20 TXT HTML PDF

Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward.

Diff from 13 to 14 »
State: IESG Evaluation::AD Followup
ID Tracker » ATOM
Document details »
OAUTH WG »
Framework for Abstraction and Control of Traffic Engineered Networks (draft-ietf-teas-actn-framework)

By Daniele Ceccarelli, Young Lee, 2017-07-20 TXT HTML PDF

Abstract: 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.

Diff from 06 to 07 »
Document details »
TEAS WG »
Transport Layer Security (TLS) Extension for Token Binding Protocol Negotiation (draft-ietf-tokbind-negotiation)

By Andrey Popov, Magnus Nystrom, Dirk Balfanz, Adam Langley, 2017-07-20 TXT HTML PDF

Abstract: This document specifies a Transport Layer Security (TLS) extension for the negotiation of Token Binding protocol version and key parameters.

Diff from 08 to 09 »
Document details »
TOKBIND WG »
The Token Binding Protocol Version 1.0 (draft-ietf-tokbind-protocol)

By Andrey Popov, Magnus Nystrom, Dirk Balfanz, Adam Langley, Jeff Hodges, 2017-07-20 TXT HTML PDF

Abstract: 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 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 Token Binding identifiers are only conveyed over TLS and can be reset by the user at any time.

Diff from 14 to 15 »
Document details »
TOKBIND WG »
TRILL: Address Flush Message (draft-ietf-trill-address-flush)

By Hao Weiguo, Donald Eastlake, Li Yizhou, Mohammed Umair, 2017-07-20 TXT HTML PDF

Abstract: The TRILL (TRansparent Interconnection of Lots of Links) protocol, by default, learns end station addresses from observing the data plane. In particular, it learns local MAC addresses and edge switch port of attachment from the receipt of local data frames and learns remote MAC addresses and edge switch of attachment from the decapsulation of remotely sourced TRILL Data packets.

Diff from 02 to 03 »
Document details »
TRILL WG »
Guidelines for Adding Congestion Notification to Protocols that Encapsulate IP (draft-ietf-tsvwg-ecn-encap-guidelines)

By Bob Briscoe, John Kaippallimalil, Patricia Thaler, 2017-07-20 TXT HTML PDF

Abstract: 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.

Diff from 08 to 09 »
Document details »
TSVWG WG »
Service Function Chaining Service, Subscriber and Host Identification Use Cases and Metadata (draft-sarikaya-sfc-hostid-serviceheader)

By Mohamed Boucadair, Dirk Hugo, Behcet Sarikaya, 2017-07-20 TXT HTML PDF

Abstract: This document discusses considerations related to passing service-, 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 elements of an SFC-enabled domain, the information is stripped from packets so that privacy-sensitive information is not leaked outside an SFC-enabled domain.

Diff from 04 to 05 »
Formal SignWriting (draft-slevinski-formal-signwriting)

By Stephen Slevinski, 2017-07-20 TXT HTML PDF

Abstract: Sutton SignWriting is the universal and complete solution for written sign language. It has been applied by a wide and deep international community of sign language users. Sutton SignWriting 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.

Diff from 02 to 03 »
On the Politics of Standards (draft-tenoever-hrpc-political)

By Niels ten Oever, Andrew Sullivan, 2017-07-20 TXT HTML PDF

Abstract: This document aims to outline different views on the relation between protocols and politics and seeks to answer the question whether protocols are political.

Diff from 00 to 01 »

Expired Drafts

Using a DNS SRV Record to Locate an X.509 Certificate Store (draft-bhjl-x509-srv)

By Brian Haberman, John Levine, 2017-01-16 TXT HTML PDF

Abstract: 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.

State: Expired
The consideration of OPC UA security in constrained environments (draft-wei-ace-opc-ua-security)

By Min Wei, QingQing Huang, ShuaiYong Li, Ping Wang, ShuaiDong Zhang, 2017-01-16 TXT HTML PDF

Abstract: OPC Unified Architecture (OPC UA) is a communication protocol for industrial automation developed by the OPC Foundation. Compared with OPC, OPC UA provides a complete set of security mechanisms to ensure data confidentiality, data integrity and data availability. With the development of industrial internet of things, more and more nodes are expected to be implemented OPC UA, which are resource constrained. This draft discusses OPC UA security mechanisms and the applicability in a constrained environment. An outline of a lightweight security mechanism for OPC UA using in constrained device is proposed.

State: Expired

Drafts Sent to IESG

Use of Multicast Across Inter-Domain Peering Points (draft-ietf-mboned-interdomain-peering-bcp): Active » Publication Requested

By Percy Tarapore, Robert Sayko, Greg Shepherd, Toerless Eckert, Ram Krishnan, 2017-07-17 TXT HTML PDF

Abstract: This document examines the use of Source Specific Multicast (SSM) across inter-domain peering points for a specified set of deployment scenarios. The objective is to describe the setup process for multicast-based delivery across administrative domains for these scenarios and document supporting functionality to enable this process.

State: Publication Requested
ID Tracker » ATOM
Document details »
MBONED WG »

IESG Progress

The OAuth 2.0 Authorization Framework: JWT Secured Authorization Request (JAR) (draft-ietf-oauth-jwsreq): IESG Evaluation::Revised I-D Needed » ::AD Followup

By Nat Sakimura, John Bradley, 2017-07-20 TXT HTML PDF

Abstract: The authorization request in OAuth 2.0 described in RFC 6749 utilizes query parameter serialization, which means that Authorization Request parameters are encoded in the URI of the request and sent through user agents such as web browsers. While it is easy to implement, it means that (a) the communication through the user agents are not integrity protected and thus the parameters can be tainted, and (b) the source of the communication is not authenticated. Because of these weaknesses, several attacks to the protocol have now been put forward.

State: IESG Evaluation::AD Followup
ID Tracker » ATOM
Document details »
OAUTH WG »

Drafts Sent to RFC Editor

Other Status Changes

Extensible Property Maps for the ALTO Protocol (draft-roome-alto-unified-props-new): Active » Replaced by draft-ietf-alto-unified-props-new

By Wendy Roome, Yang Yang, 2017-07-03 TXT HTML PDF

Abstract: This document extends the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by generalizing the concept of "endpoint properties" to other entity domains, and by presenting those properties as maps, similar to the network and cost maps in ALTO.

State: Replaced by draft-ietf-alto-unified-props-new
Content Delivery Network Interconnection (CDNI) Request Routing: CDNI Footprint and Capabilities Advertisement using ALTO (draft-seedorf-cdni-request-routing-alto): Active » Replaced by draft-ietf-alto-cdni-request-routing-alto

By Jan Seedorf, Yang Yang, Kevin Ma, Jon Peterson, 2017-07-03 TXT HTML PDF

Abstract: The Content Delivery Networks Interconnection (CDNI) WG is defining a set of protocols to inter-connect CDNs, to achieve multiple goals such as extending the reach of a given CDN to areas that are not covered by that particular CDN. One componet that is needed to achieve the goal of CDNI is the CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI) [RFC7336]. [RFC8008] has defined precisely the semantics of FCI and provided guidelines on the FCI protocol, but the exact protocol is explicitly outside the scope of that document. In this document, we define an FCI protocol using the Application Layer Traffic Optimization (ALTO) protocol.

State: Replaced by draft-ietf-alto-cdni-request-routing-alto