IETF-Announce List
![[Feed]](feedicon16.png) New RFCs
New and Revived Drafts
- RIB YANG Data Model (draft-acee-rtgwg-yang-rib-extend)
By Acee Lindem, Yingzhen Qu, 2019-02-18 TXT HTML PDF
Abstract: The Routing Information Base (RIB) is a list of routes and their corresponding administrative data and operational state.
- Extensible Provisioning Protocol (EPP) Contact Mapping for Registration Data Access Protocol (RDAP) JSON Responses (draft-brown-epp-contacts-in-rdap)
By Gavin Brown, 2019-02-18 TXT HTML PDF
Abstract: This document describes how EPP contact objects can be represented in RDAP entities.
- draft-ietf-teas-yang-rsvp
No title available; expired document? TXT HTML PDF
- IKEv2 Optional SA&TS Payloads in Child Exchange (draft-kampati-ipsecme-ikev2-sa-ts-payloads-opt)
By Sandeep Kampati, 2019-02-18 TXT HTML PDF
Abstract: This document describes a method for reduce the size of the Internet Key Exchange version 2 (IKEv2) exchanges at time of IKE rekey and Child SA Rekey by removing or making optional of SA & TS payloads. Reducing size of IKEv2 exchange is desirable for low power consumption battery powered devices. It also helps to avoid IP fragmentation of IKEv2 messages.
- Responsibility for Authoritative DNS and DNSSEC Mistakes (draft-livingood-dnsop-auth-dnssec-mistakes)
By Jason Livingood, 2019-02-18 TXT HTML PDF
Abstract: DNS Security Extensions (DNSSEC) validation by recursive DNS resolvers has been deployed at scale. However, domain signing tools and processes are not yet as mature and reliable as is the case for non-DNSSEC-related domain administration tools and processes. This sometimes results in DNSSEC-validation failures, for which operators of validating resolvers are often blamed. This is similar to other, non-DNSSEC-related authoritative DNS errors, for which individual recursive DNS operators are sometimes incorrectly blamed. This document makes clear that responsibility for any and all authoritative DNS failures rests squarely with authoritative domain name operators, who are the only party that can properly maintain their domain names and rectify associated authoritative DNS errors.
- In Case of DNSSEC Validation Failures, Do Not Change Resolvers (draft-livingood-dnsop-dont-switch-resolvers)
By Jason Livingood, 2019-02-18 TXT HTML PDF
Abstract: DNS Security Extensions (DNSSEC) validation by recursive DNS resolvers has been deployed at scale. However, domain signing tools and processes are not yet as mature and reliable as is the case for non-DNSSEC-related domain administration tools and processes. This sometimes results in DNSSEC validation failures, for which operators of validating resolvers are often blamed. When these failures do occur, end users should not change to a non-validating DNS resolver, as that would downgrade their security. They should instead wait until the authoritative domain operator updates their DNS records to resolve the error and that change propagates across the Internet's DNS resolvers, the timing of which may be dependent upon the Time To Live (TTL) settings in the old and/or erroneous DNS resource records.
Updated Drafts
- PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for P2MP LSPs (draft-dhody-pce-pcep-extension-pce-controller-p2mp)
By Mahendra Negi, Zhenbin Li, Xuesong Geng, 2019-02-18 TXT HTML PDF
Abstract: The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.
- PCEP Procedures and Protocol Extensions for Using PCE as a Central Controller (PCECC) for SRv6 (draft-dhody-pce-pcep-extension-pce-controller-srv6)
By Mahendra Negi, Zhenbin Li, Xuesong Geng, 2019-02-18 TXT HTML PDF
Abstract: The Path Computation Element (PCE) is a core component of Software- Defined Networking (SDN) systems. It can compute optimal paths for traffic across a network and can also update the paths to reflect changes in the network or traffic demands.
- Reaction of Stateless Address Autoconfiguration (SLAAC) to Renumbering Events (draft-gont-6man-slaac-renum)
By Fernando Gont, Jan Zorz, 2019-02-18 TXT HTML PDF
Abstract: In scenarios where network configuration information related to IPv6 prefixes becomes invalid without any explicit signaling of that condition (such as when a CPE crashes and reboots without knowledge of the previously-employed prefixes), nodes on the local network will continue using stale prefixes for an unacceptably long period of time, thus resulting in connectivity problems. This document analyzes these problem scenarios, and proposes workarounds to improve network robustness. This document updates RFC4861 and RFC4862 to allow for a more robust reaction to network configuration changes.
- FETCH & PATCH with Sensor Measurement Lists (SenML) (draft-ietf-core-senml-etch)
By Ari Keranen, Mojan Mohajer, 2019-02-18 TXT HTML PDF
Abstract: The Sensor Measurement Lists (SenML) media type and data model can be used to send collections of resources, such as batches of sensor data or configuration parameters. The CoAP iPATCH, PATCH, and FETCH methods enable accessing and updating parts of a resource or multiple resources with one request. This document defines new media types for the CoAP iPATCH, and FETCH methods for resources represented with the SenML data model.
- Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification (draft-ietf-dots-data-channel)
By Mohamed Boucadair, Reddy K, 2019-02-18 TXT HTML PDF
Abstract: The document specifies a Distributed Denial-of-Service Open Threat Signaling (DOTS) data channel used for bulk exchange of data that cannot easily or appropriately communicated through the DOTS signal channel under attack conditions.
- A YANG Data Model for Traffic Engineering Tunnels and Interfaces (draft-ietf-teas-yang-te)
By Tarek Saad, Rakesh Gandhi, Xufeng Liu, Vishnu Beeram, Igor Bryskin, 2019-02-18 TXT HTML PDF
Abstract: 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.
- Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (draft-ietf-tram-turnbis)
By Reddy K, Alan Johnston, Philip Matthews, Jonathan Rosenberg, 2019-02-17 TXT HTML PDF
Abstract: 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.
- Packetization Layer Path MTU Discovery for Datagram Transports (draft-ietf-tsvwg-datagram-plpmtud)
By Gorry Fairhurst, Tom Jones, Michael Tuexen, Irene Ruengeler, Timo Voelker, 2019-02-18 TXT HTML PDF
Abstract: This document describes a robust method for Path MTU Discovery (PMTUD) for datagram Packetization Layers (PLs). The document describes an extension to RFC 1191 and RFC 8201, which specifies ICMP-based Path MTU Discovery for IPv4 and IPv6. The method allows a PL, or a datagram application that uses a PL, to discover whether a network path can support the current size of datagram. This can be used to detect and reduce the message size when a sender encounters a network black hole (where packets are discarded, and no ICMP message is received). The method can also probe a network path with progressively larger packets to find whether the maximum packet size can be increased. This allows a sender to determine an appropriate packet size, providing functionally for datagram transports that is equivalent to the Packetization Layer PMTUD specification for TCP, specified in RFC 4821.
- The Impact of Transport Header Confidentiality on Network Operation and Evolution of the Internet (draft-ietf-tsvwg-transport-encrypt)
By Gorry Fairhurst, Colin Perkins, 2019-02-18 TXT HTML PDF
Abstract: This document describes implications of applying end-to-end encryption at the transport layer. It identifies in-network uses of transport layer header information. It then reviews the implications of developing end-to-end transport protocols that use authentication to protect the integrity of transport information or encryption to provide confidentiality of the transport protocol header and expected implications of transport protocol design and network operation. Since transport measurement and analysis of the impact of network characteristics have been important to the design of current transport protocols, it also considers the impact on transport and application evolution.
- Compressed BGP Update Message (draft-przygienda-idr-compressed-updates)
By Tony Przygienda, Avinash Lingala, Csaba Mate, Jeff Tantsura, 2019-02-18 TXT HTML PDF
Abstract: This document provides specification of an optional compressed BGP update message format to allow family independent reduction in BGP control traffic volume.
- DNS TIMEOUT Resource Record (draft-pusateri-dnsop-update-timeout)
By Tom Pusateri, Tim Wattenberg, 2019-02-18 TXT HTML PDF
Abstract: This specification defines a new DNS TIMEOUT resource record (RR) that associates a lifetime with one or more zone resource records with the same owner name, type, and class. It is intended to be used to transfer resource record lifetime state between a zone's primary and secondary servers and to store lifetime state during server software restarts.
Expired Drafts
- Launch Phase Policy Extensions Mapping for the Extensible Provisioning Protocol (EPP) (draft-gould-regext-launch-policy)
By James Gould, 2018-08-17 TXT HTML PDF
Abstract: This document describes an Extensible Provisioning Protocol (EPP) extension of the Registry Mapping to define the server policy of the Launch Phase EPP extension. The server policy of the Launch Phase EPP extension includes the MAYs, SHOULDs, and options implemented by the server.
- Delegated Credentials for TLS (draft-ietf-tls-subcerts)
By Richard Barnes, Subodh Iyengar, Nick Sullivan, Eric Rescorla, 2018-08-17 TXT HTML PDF
Abstract: The organizational separation between the operator of a TLS server and the certification authority can create limitations. For example, the lifetime of certificates, how they may be used, and the algorithms they support are ultimately determined by the certification authority. This document describes a mechanism by which operators may delegate their own credentials for use in TLS, without breaking compatibility with clients that do not support this specification.
|
Drafts Sent to IESG
IESG Progress
- Diameter Group Signaling (draft-ietf-dime-group-signaling): Publication Requested » AD Evaluation
By Mark Jones, Marco Liebsch, Lionel Morand, 2018-12-28 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 RFC Editor
Other Status Changes
RFC Editor Status Changes
- Extensible Provisioning Protocol (EPP) Organization Mapping (draft-ietf-regext-org): » AUTH48
By Linlin Zhou, Ning Kong, Guiqing Zhou, Jiankang Yao, James Gould, 2018-11-29 TXT HTML PDF
Abstract: This document describes an Extensible Provisioning Protocol (EPP) mapping for provisioning and management of organization objects 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 organizations.
- Organization Extension for the Extensible Provisioning Protocol (EPP) (draft-ietf-regext-org-ext): » AUTH48
By Linlin Zhou, Ning Kong, Junkai Wei, Jiankang Yao, James Gould, 2018-12-04 TXT HTML PDF
Abstract: This document describes an extension to Extensible Provisioning Protocol (EPP) object mappings, which is designed to support assigning an organization to any existing object (domain, host, contact) as well as any future objects.
IPR Disclosures
IESG/IAB/IAOC/Trust Minutes
Liaison Statements
Classified Ads
|
WGs marked with an 
