IETF-Announce List
![[Feed]](feedicon16.png) New RFCs
New and Revived Drafts
- Need for associating email address to device address and phone numbers (draft-httpemaildevphone)
By pradeep xplorer, 2018-12-12 TXT HTML PDF
Abstract: This document describes the need for associating email address to device address and phone numbers
- An ACME Profile for Generating Delegated STAR Certificates (draft-ietf-acme-star-delegation)
By Yaron Sheffer, Diego Lopez, Antonio Pastor, Thomas Fossati, 2018-12-13 TXT HTML PDF
Abstract: This memo proposes a profile of the ACME protocol that allows the owner of an identifier (e.g., a domain name) to delegate to a third party access to a certificate associated with said identifier. A primary use case is that of a CDN (the third party) terminating TLS sessions on behalf of a content provider (the owner of a domain name). The presented mechanism allows the owner of the identifier to retain control over the delegation and revoke it at any time by cancelling the associated STAR certificate renewal with the ACME CA. Another key property of this mechanism is it does not require any modification to the deployed TLS ecosystem.
- Flowspec Indirection-id Redirect (draft-ietf-idr-flowspec-path-redirect)
By Gunter Van de Velde, Keyur Patel, Zhenbin Li, 2018-12-13 TXT HTML PDF
Abstract: This document defines a new extended community known as "FlowSpec Redirect to indirection-id Extended Community". This extended community triggers advanced redirection capabilities to flowspec clients. When activated, this flowspec extended community is used by a flowspec client to retrieve the corresponding next-hop and encoding information within a localised indirection-id mapping table.
- Applicability of the Path Computation Element to Inter-Area and Inter-AS MPLS and GMPLS Traffic Engineering (draft-ietf-pce-inter-area-as-applicability)
By Daniel King, Haomian Zheng, 2018-12-13 TXT HTML PDF
Abstract: The Path Computation Element (PCE) may be used for computing services that traverse multi-area and multi-AS Multiprotocol Label Switching (MPLS) and Generalized MPLS (GMPLS) Traffic Engineered (TE) networks.
- draft-kazuho-quic-authenticated-handshake
No title available; expired document? TXT HTML PDF
Updated Drafts
- Address Protected Neighbor Discovery for Low-power and Lossy Networks (draft-ietf-6lo-ap-nd)
By Pascal Thubert, Mohit Sethi, Rene Struik, Behcet Sarikaya, 2018-12-13 TXT HTML PDF
Abstract: This document specifies an extension to 6LoWPAN Neighbor Discovery (ND) defined in RFC6775 and updated in [I-D.ietf-6lo-rfc6775-update]. The new extension is called Address Protected Neighbor Discovery (AP- ND) and it protects the owner of an address against address theft and impersonation attacks in a low-power and lossy network (LLN). Nodes supporting this extension compute a cryptographic identifier (Crypto- ID) and use it with one or more of their Registered Addresses. The Crypto-ID identifies the owner of the Registered Address and can be used to provide proof of ownership of the Registered Addresses. Once an address is registered with the Crypto-ID and a proof-of-ownership is provided, only the owner of that address can modify the registration information, thereby enforcing Source Address Validation.
- Updates on EVPN BUM Procedures (draft-ietf-bess-evpn-bum-procedure-updates)
By Zhaohui Zhang, Wen Lin, Jorge Rabadan, Keyur Patel, Ali Sajassi, 2018-12-13 TXT HTML PDF
Abstract: This document specifies procedure updates for broadcast, unknown unicast, and multicast (BUM) traffic in Ethernet VPNs (EVPN), including selective multicast, and provider tunnel segmentation.
- BFD for Multipoint Networks (draft-ietf-bfd-multipoint)
By Dave Katz, David Ward, Juniper Networks, Gregory Mirsky, 2018-12-13 TXT HTML PDF
Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks.
- The IETF-ISOC Relationship (draft-ietf-iasa2-rfc2031bis)
By Gonzalo Camarillo, Jason Livingood, 2018-12-13 TXT HTML PDF
Abstract: This document summarises the Internet Engineering Task Force (IETF) - Internet Society (ISOC) relationship, following a major revision to the structure of the IETF Administrative Support Activity (IASA) in 2018. The IASA was revised under a new "IASA 2.0" structure by the IASA2 Working Group, which changed the IETF's administrative, legal, and financial structure. As a result, it also changed the relationship between the IETF and ISOC, which made it necessary to revise RFC 2031.
- Signalling ERLD using BGP-LS (draft-ietf-idr-bgp-ls-segment-routing-rld)
By Gunter Van de Velde, Wim Henderickx, Matthew Bocci, Keyur Patel, 2018-12-13 TXT HTML PDF
Abstract: This document defines the attribute encoding to use for BGP-LS to expose ERLD "Entropy capable Readable Label Depth" from a node to a centralised controller (PCE/SDN).
- BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions (draft-ietf-idr-te-pm-bgp)
By Les Ginsberg, Stefano Previdi, Qin Wu, Jeff Tantsura, Clarence Filsfils, 2018-12-13 TXT HTML PDF
Abstract: This document defines new BGP-LS TLVs in order to carry the IGP Traffic Engineering Extensions defined in the IS-IS and OSPF protocols.
- IS-IS Extensions for Segment Routing (draft-ietf-isis-segment-routing-extensions)
By Stefano Previdi, Les Ginsberg, Clarence Filsfils, Ahmed Bashandy, Hannes Gredler, Bruno Decraene, 2018-12-13 TXT HTML PDF
Abstract: 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).
- Restart Signaling for IS-IS (draft-ietf-lsr-isis-rfc5306bis)
By Les Ginsberg, Paul Wells, 2018-12-13 TXT HTML PDF
Abstract: This document describes a mechanism for a restarting router to signal to its neighbors that it is restarting, allowing them to reestablish their adjacencies without cycling through the down state, while still correctly initiating database synchronization.
- WebRTC MediaStream Identification in the Session Description Protocol (draft-ietf-mmusic-msid)
By Harald Alvestrand, 2018-12-13 TXT HTML PDF
Abstract: This document specifies a Session Description Protocol (SDP) Grouping mechanism for RTP media streams that can be used to specify relations between media streams.
- Dynamic subscription to YANG Events and Datastores over RESTCONF (draft-ietf-netconf-restconf-notif)
By Eric Voit, Reshad Rahman, Einar Nilsen-Nygaard, Alexander Clemm, Andy Bierman, 2018-11-05 TXT HTML PDF
Abstract: This document provides a RESTCONF binding to the dynamic subscription capability of both subscribed notifications and YANG-Push.
- Network Time Protocol Best Current Practices (draft-ietf-ntp-bcp)
By Denis Reilly, Harlan Stenn, Dieter Sibold, 2018-12-13 TXT HTML PDF
Abstract: The Network Time Protocol (NTP) is one of the oldest protocols on the Internet and has been widely used since its initial publication. This document is a collection of Best Practices for general operation of NTP servers and clients on the Internet. It includes recommendations for stable, accurate and secure operation of NTP infrastructure. This document is targeted at NTP version 4 as described in RFC 5905.
- PCEP Extension for WSON Routing and Wavelength Assignment (draft-ietf-pce-wson-rwa-ext)
By Young Lee, Ramon Casellas, 2018-12-13 TXT HTML PDF
Abstract: 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). Path 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 path computation.
- State-of-the-Art and Challenges for the Internet of Things Security (draft-irtf-t2trg-iot-seccons)
By Oscar Garcia-Morchon, Sandeep Kumar, Mohit Sethi, 2018-12-13 TXT HTML PDF
Abstract: The Internet of Things (IoT) concept refers to the usage of standard Internet protocols to allow for human-to-thing and thing-to-thing communication. The security needs for IoT systems are well- recognized and many standardization steps to provide security have been taken, for example, the specification of Constrained Application Protocol (CoAP) secured with Datagram Transport Layer Security (DTLS). However, security challenges still exist, not only because there are some use cases that lack a suitable solution, but also because many IoT devices and systems have been designed and deployed with very limited security capabilities. In this document, we first discuss the various stages in the lifecycle of a thing. Next, we document the security threats to a thing and the challenges that one might face to protect against these threats. Lastly, we discuss the next steps needed to facilitate the deployment of secure IoT systems. This document can be used by implementors and authors of IoT specifications as a reference for details about security considerations while documenting their specific security challenges, threat models, and mitigations.
Expired Drafts
- Diameter Group Signaling (draft-ietf-dime-group-signaling)
By Mark Jones, Marco Liebsch, Lionel Morand, 2018-06-11 TXT HTML PDF
Abstract: 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.
|
Drafts Sent to IESG
IESG Progress
- BFD for Multipoint Networks (draft-ietf-bfd-multipoint): IESG Evaluation::Revised I-D Needed » ::AD Followup
By Dave Katz, David Ward, Juniper Networks, Gregory Mirsky, 2018-12-13 TXT HTML PDF
Abstract: This document describes extensions to the Bidirectional Forwarding Detection (BFD) protocol for its use in multipoint and multicast networks.
- BGP-LS Advertisement of IGP Traffic Engineering Performance Metric Extensions (draft-ietf-idr-te-pm-bgp): Waiting for Writeup » IESG Evaluation
By Les Ginsberg, Stefano Previdi, Qin Wu, Jeff Tantsura, Clarence Filsfils, 2018-12-13 TXT HTML PDF
Abstract: This document defines new BGP-LS TLVs in order to carry the IGP Traffic Engineering Extensions defined in the IS-IS and OSPF protocols.
- Locator/ID Separation Protocol (LISP): Shared Extension Message & IANA Registry for Packet Type Allocations (draft-ietf-lisp-rfc8113bis): Publication Requested » In Last Call
By Mohamed Boucadair, Christian Jacquenet, 2018-11-04 TXT HTML PDF
Abstract: This document specifies a Locator/ID Separation Protocol (LISP) shared message type for defining future extensions and conducting experiments without consuming a LISP packet type codepoint for each extension.
- IS-IS Traffic Engineering (TE) Metric Extensions (draft-ietf-lsr-isis-rfc7810bis): Waiting for Writeup » IESG Evaluation
By Les Ginsberg, Stefano Previdi, Spencer Giacalone, David Ward, John Drake, Qin Wu, 2018-11-29 TXT HTML PDF
Abstract: 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.
- Label Switched Path (LSP) Ping/Trace Multipath Support for Link Aggregation Group (LAG) Interfaces (draft-ietf-mpls-lsp-ping-lag-multipath): Waiting for Writeup » Expert Review
By Nobo Akiya, George Swallow, Stephane Litkowski, Bruno Decraene, John Drake, Mach Chen, 2018-10-23 TXT HTML PDF
Abstract: This document defines extensions to the MPLS Label Switched Path (LSP) Ping and Traceroute mechanisms as specified in RFC 8029. The extensions allow the MPLS LSP Ping and Traceroute mechanisms to discover and exercise specific paths of Layer 2 (L2) Equal-Cost Multipath (ECMP) over Link Aggregation Group (LAG) interfaces. Additionally, a mechanism is defined to enable determination of the capabilities of an LSR supported.
- Signaling RSVP-TE tunnels on a shared MPLS forwarding plane (draft-ietf-mpls-rsvp-shared-labels): Waiting for Writeup » IESG Evaluation
By Harish Sitaraman, Vishnu Beeram, Tejal Parikh, Tarek Saad, 2018-12-09 TXT HTML PDF
Abstract: As the scale of MPLS RSVP-TE networks has grown, so the number of Label Switched Paths (LSPs) supported by individual network elements has increased. Various implementation recommendations have been proposed to manage the resulting increase in control plane state.
- An MPLS-Based Forwarding Plane for Service Function Chaining (draft-ietf-mpls-sfc): Publication Requested » Expert Review
By Adrian Farrel, Stewart Bryant, John Drake, 2018-11-20 TXT HTML PDF
Abstract: Service Function Chaining (SFC) is the process of directing packets through a network so that they can be acted on by an ordered set of abstract service functions before being delivered to the intended destination. An architecture for SFC is defined in RFC7665.
- PCEP Extension for WSON Routing and Wavelength Assignment (draft-ietf-pce-wson-rwa-ext): Publication Requested » In Last Call
By Young Lee, Ramon Casellas, 2018-12-13 TXT HTML PDF
Abstract: 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). Path 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 path computation.
Drafts Sent to RFC Editor
Other Status Changes
- ALTO Cost Calendar (draft-ietf-alto-cost-calendar): IESG Evaluation::Revised I-D Needed » Active
By Sabine Randriamasy, Yang Yang, Qin Wu, Deng Lingli, Nico Schwan, 2018-11-13 TXT HTML PDF
Abstract: This document is an extension to the base ALTO protocol [RFC7285]. It extends the ALTO cost information service such that applications decide not only 'where' to connect, but also 'when'. This is useful for applications that need to perform bulk data transfer and would like to schedule these transfers during an off-peak hour, for example. This extension introduces ALTO Cost Calendars, with which an ALTO Server exposes ALTO cost values in JSON arrays where each value corresponds to a given time interval. The time intervals as well as other Calendar attributes are specified in the Information Resources Directory and ALTO Server responses.
- An ACME Profile for Generating Delegated STAR Certificates (draft-sheffer-acme-star-delegation): Active » Replaced by draft-ietf-acme-star-delegation
By Yaron Sheffer, Diego Lopez, Antonio Pastor, Thomas Fossati, 2018-11-13 TXT HTML PDF
Abstract: This memo proposes a profile of the ACME protocol that allows the owner of an identifier (e.g., a domain name) to delegate to a third party access to a certificate associated with said identifier. A primary use case is that of a CDN (the third party) terminating TLS sessions on behalf of a content provider (the owner of a domain name). The presented mechanism allows the owner of the identifier to retain control over the delegation and revoke it at any time by cancelling the associated STAR certificate renewal with the ACME CA. Another key property of this mechanism is it does not require any modification to the deployed TLS ecosystem.
RFC Editor Status Changes
- A Root Key Trust Anchor Sentinel for DNSSEC (draft-ietf-dnsop-kskroll-sentinel): » AUTH48
By Geoff Huston, Joao Damas, Warren Kumari, 2018-10-21 TXT HTML PDF
Abstract: 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 mechanism that will allow an end user and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determining which keys are in the trust store for the root key.
IPR Disclosures
IESG/IAB/IAOC/Trust Minutes
Liaison Statements
Classified Ads
|
WGs marked with an 
