IETF-Announce List
![[Feed]](feedicon16.png) New RFCs
New and Revived Drafts
- An update to RFC6302 on Logging Recommendations for Internet-Facing Servers (draft-andersdotter-intarea-update-to-rfc6302)
By Amelia Andersdotter, 2018-04-22 TXT HTML PDF
Abstract: This draft seeks to update RFC6302 on Logging Recommendations for Internet-Facing Servers. The new recommendations aim to be a best practice for service providers and server maintainers, by following recommendations outlined in RFC6973 and taking into account new regulatory requirements in the privacy area.
- FFV1 Video Coding Format Version 4 (draft-ietf-cellar-ffv1-v4)
By Michael Niedermayer, Dave Rice, Jerome Martinez, 2018-04-22 TXT HTML PDF
Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format.
- RTP Payload Format for the TETRA Audio Codec (draft-ietf-payload-tetra)
By Andreas Reisenbauer, Udo Brandhuber, Joachim Hagedorn, Klaus-Peter Hohnsch, Stefan Wenk, 2018-04-23 TXT HTML PDF
Abstract: This document specifies a Real-time Transport Protocol (RTP) payload format for TETRA encoded speech signals. The payload format is designed to be able to interoperate with existing TETRA transport formats on non-IP networks. A media type registration is included, specifying the use of the RTP payload format and the storage format.
- SM3 and SM4 Cipher Suites for TLS (draft-sca-curdle-tls-sm34)
By Paul Yang, Ronald Tse, Markku-Juhani Saarinen, Wai Wong, 2018-04-23 TXT HTML PDF
Abstract: This document describes TLS cipher suites that utilize the SM3 cryptographic hash algorithm (GB/T 32905-2016) and SM4 symmetric blockcipher algorithm (GB/T 32907-2016), both published by the State Cryptography Administration of China (SCA).
Updated Drafts
- Registration Extensions for 6LoWPAN Neighbor Discovery (draft-ietf-6lo-rfc6775-update)
By Pascal Thubert, Erik Nordmark, Samita Chakrabarti, Charles Perkins, 2018-04-23 TXT HTML PDF
Abstract: This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, as well as to provide enhancements to the registration capabilities and mobility detection for different network topologies including the backbone routers performing proxy Neighbor Discovery in a low power network.
- FFV1 Video Coding Format Version 0, 1, and 3 (draft-ietf-cellar-ffv1)
By Michael Niedermayer, Dave Rice, Jerome Martinez, 2018-04-22 TXT HTML PDF
Abstract: This document defines FFV1, a lossless intra-frame video encoding format. FFV1 is designed to efficiently compress video data in a variety of pixel formats. Compared to uncompressed video, FFV1 offers storage compression, frame fixity, and self-description, which makes FFV1 useful as a preservation or intermediate video format.
- Deterministic Networking (DetNet) Security Considerations (draft-ietf-detnet-security)
By Tal Mizrahi, Ethan Grossman, Andrew Hacker, Subir Das, John Dowdell, Henrik Austad, Kevin Stanton, Norman Finn, 2018-04-23 TXT HTML PDF
Abstract: A deterministic network is one that can carry data flows for real- time applications with extremely low data loss rates and bounded latency. Deterministic networks have been successfully deployed in real-time operational technology (OT) applications for some years (for example [ARINC664P7]). However, such networks are typically isolated from external access, and thus the security threat from external attackers is low. IETF Deterministic Networking (DetNet) specifies a set of technologies that enable creation of deterministic networks on IP-based networks of potentially wide area (on the scale of a corporate network) potentially bringing the OT network into contact with Information Technology (IT) traffic and security threats that lie outside of a tightly controlled and bounded area (such as the internals of an aircraft). These DetNet technologies have not previously been deployed together on a wide area IP-based network, and thus can present security considerations that may be new to IP- based wide area network designers. This draft, intended for use by DetNet network designers, provides insight into these security considerations. In addition, this draft collects all security- related statements from the various DetNet drafts (Architecture, Use Cases, etc) into a single location Section 7.
- Authenticated Received Chain (ARC) Protocol (draft-ietf-dmarc-arc-protocol)
By Kurt Andersen, Brandon Long, Steven Jones, Seth Blank, Murray Kucherawy, 2018-04-23 TXT HTML PDF
Abstract: The Authenticated Received Chain (ARC) protocol creates a mechanism whereby a series of handlers of an email message can conduct authentication of the email message as it passes among them on the way to its destination, and create an attached, authenticated record of the status at each step along the handling path, for use by the final recipient in making choices about the disposition of the message. Changes in the message that might break existing authentication mechanisms can be identified through the ARC Set of header fields.
- Recommended Usage of the Authenticated Received Chain (ARC) (draft-ietf-dmarc-arc-usage)
By Steven Jones, Kurt Andersen, John Rae-Grant, J. Adams, 2018-04-23 TXT HTML PDF
Abstract: 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.
- Data-Only Emergency Calls (draft-ietf-ecrit-data-only-ea)
By Brian Rosen, Henning Schulzrinne, Hannes Tschofenig, Randall Gellens, 2018-04-23 TXT HTML PDF
Abstract: 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 Session Initiation Protocol (SIP) session establishment starting with a SIP INVITE that negotiates various parameters for that session.
- IMAP Extension for object identifiers (draft-ietf-extra-imap-objectid)
By Bron Gondwana, 2018-04-23 TXT HTML PDF
Abstract: This document adds new properties to IMAP mailboxes and messages to allow clients to more efficiently re-use cached data for resources which have changed location on the server.
- Dissemination of Flow Specification Rules (draft-ietf-idr-rfc5575bis)
By Susan Hares, Christoph Loibl, Robert Raszuk, Danny McPherson, Martin Bacher, 2018-04-21 TXT HTML PDF
Abstract: This document updates [RFC5575] which defines a Border Gateway Protocol Network Layer Reachability Information (BGP NLRI) encoding format that can be used to distribute traffic Flow Specifications. This allows the routing system to propagate information regarding more specific components of the traffic aggregate defined by an IP destination prefix.
- Route Target Constrained Distribution of Routes with no Route Targets (draft-ietf-idr-rtc-no-rt)
By Eric Rosen, Keyur Patel, Jeffrey Haas, Robert Raszuk, 2018-04-23 TXT HTML PDF
Abstract: 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.
- Two-Way Active Measurement Protocol (TWAMP) Data Model (draft-ietf-ippm-twamp-yang)
By Ruth Civil, Al Morton, Reshad Rahman, Mahesh Jethanandani, Kostas Pentikousis, 2018-04-23 TXT HTML PDF
Abstract: This document specifies a data model for client and server implementations of the Two-Way Active Measurement Protocol (TWAMP). The document defines the TWAMP data model through Unified Modeling Language (UML) class diagrams and formally specifies it using YANG.
- LISP EID Anonymity (draft-ietf-lisp-eid-anonymity)
By Dino Farinacci, Padma Pillay-Esnault, Wassim Haddad, 2018-04-23 TXT HTML PDF
Abstract: 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 Mobile Node (draft-ietf-lisp-mn)
By Dino Farinacci, Darrel Lewis, David Meyer, Chris White, 2018-04-23 TXT HTML PDF
Abstract: 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.
- LISP Traffic Engineering Use-Cases (draft-ietf-lisp-te)
By Dino Farinacci, Michael Kowal, Parantap Lahiri, 2018-04-23 TXT HTML PDF
Abstract: 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.
- OAuth 2.0 Token Exchange (draft-ietf-oauth-token-exchange)
By Michael Jones, Anthony Nadalin, Brian Campbell, John Bradley, Chuck Mortimore, 2018-04-23 TXT HTML PDF
Abstract: This specification defines a protocol for an 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.
- Router Keying for BGPsec (draft-ietf-sidr-rtr-keying)
By Randy Bush, Sean Turner, Keyur Patel, 2018-04-23 TXT HTML PDF
Abstract: BGPsec-speaking routers are provisioned with private keys in order to sign BGPsec announcements. The corresponding public keys are published in the global Resource Public Key Infrastructure, enabling verification of BGPsec messages. This document describes two methods of generating the public-private key-pairs: router-driven and operator-driven.
- Transport Layer Security (TLS) Certificate Compression (draft-ietf-tls-certificate-compression)
By Alessandro Ghedini, Victor Vasiliev, 2018-04-23 TXT HTML PDF
Abstract: In Transport Layer Security (TLS) handshakes, certificate chains often take up the majority of the bytes transmitted.
- Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN) (draft-ietf-tram-turnbis)
By Tirumaleswar Reddy, Alan Johnston, Philip Matthews, Jonathan Rosenberg, 2018-04-23 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.
- RPL Observations (draft-rahul-roll-rpl-observations)
By Rahul Jadhav, Rabi Sahoo, Yuefeng Wu, 2018-04-22 TXT HTML PDF
Abstract: This document describes RPL protocol design issues, various observations and possible consequences of the design and implementation choices.
- The SM4 Blockcipher Algorithm And Its Modes Of Operations (draft-ribose-cfrg-sm4)
By Ronald Tse, Wai Wong, Markku-Juhani Saarinen, 2018-04-22 TXT HTML PDF
Abstract: This document describes the SM4 symmetric blockcipher algorithm published as GB/T 32907-2016 by the State Cryptography Administration of China (SCA).
- Finding HTTP Alternative Services via the Domain Name Service (draft-schwartz-httpbis-dns-alt-svc)
By Benjamin Schwartz, Mike Bishop, 2018-04-23 TXT HTML PDF
Abstract: The HTTP Alternative Services (Alt-Svc) mechanism allows an HTTP origin to be served from multiple network endpoints, and over multiple protocols. However, the client must first contact the origin server, in order to learn of the alternative services. This draft proposes a straightforward mapping of Alt-Svc into DNS, allowing clients to learn of these services before their first contact with the origin. This arrangement offers potential benefits to both performance and privacy.
- BGP Neighbor Autodiscovery (draft-xu-idr-neighbor-autodiscovery)
By Xiaohu Xu, Kunyang Bi, Jeff Tantsura, Nikos Triantafillis, Ketan Talaulikar, 2018-04-23 TXT HTML PDF
Abstract: BGP has been used as the underlay routing protocol in many hyper- scale data centers. This document proposes a BGP neighbor autodiscovery mechanism that greatly simplifies BGP deployments. This mechanism is very useful for those hyper-scale data centers where BGP is used as the underlay routing protocol.
Expired Drafts
- draft-agrewal-idr-accept-own-nexthop
No title available; expired document? TXT HTML PDF
- BGP Link-State Extensions for IPv6 Segment Routing (draft-chen-idr-bgp-ls-srv6)
By Mach Chen, Shunwan Zhuang, 2017-10-20 TXT HTML PDF
Abstract: This document defines extensions to BGP link-state (BGP-LS) to carry the information of IPv6 Segment Routing (SRv6).
- draft-chen-pce-association-ecmp
No title available; expired document? TXT HTML PDF
- RADIUS Extended Identifier Attribute (draft-chen-radext-identifier-attr)
By Enke Chen, Naiming Shen, 2017-10-20 TXT HTML PDF
Abstract: The limitation with the one-octet "Identifier" field in the RADIUS packet is well known. In this document we propose extensions to the RADIUS protocol to address this fundamental limitation, and thus allowing for more efficient and more scalable implementations.
- DHCPv6 options for MQTT client configuration (draft-nalluri-dhc-dhcpv6-mqtt-config-options)
By Srinivasa Nalluri, 2017-10-20 TXT HTML PDF
Abstract: This document defines Dynamic Host Configuration Protocol and Dynamic Host Configuration Protocol version 6 (DHCPv6) Options for MQTT client configuration information, which are used to carry Uniform Resource Locater of MQTT broker and MQTT topic prefix that should be used as prefix for any topic published by MQTT client.
- VXLAN Group Policy Option (draft-smith-vxlan-group-policy)
By Michael Smith, Larry Kreeger, 2017-10-20 TXT HTML PDF
Abstract: 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.
|
Drafts Sent to IESG
- Using National Bibliography Numbers as Uniform Resource Names (draft-hakala-urn-nbn-rfc3188bis): Active » In Last Call
By Juna Hakala, 2018-04-15 TXT HTML PDF
Abstract: National Bibliography Numbers, NBNs, are used by the national libraries and other organizations in order to identify resources in their collections. Generally, NBNs are applied to resources that are not catered for by established (standard) identifier systems such as ISBN.
- P-Charge-Info - A Private Header Field (P-Header) Extension to the Session Initiation Protocol (SIP) (draft-york-p-charge-info): Active » Publication Requested
By Dan York, Tolga Asveren, 2018-04-19 TXT HTML PDF
Abstract: This text documents the current usage of P-Charge-Info, an existing private Session Initiation Protocol (SIP) header field (P-Header) used to convey billing information about the party to be charged. This P-Header is currently used in production by several equipment vendors and carriers and has been in usage since at least 2007. This document is submitted to request the registration of this header field with the Internet Assigned Numbers Authority (IANA).
IESG Progress
- Representing DNS Messages in JSON (draft-hoffman-dns-in-json): Waiting for Writeup » IESG Evaluation
By Paul Hoffman, 2018-04-18 TXT HTML PDF
Abstract: 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 general format for DNS message data in JSON. Specific profiles of this document can be described in other documents for specific applications and usage scenarios.
- Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR (draft-ietf-core-links-json): IESG Evaluation::AD Followup » Waiting for AD Go-Ahead::Revised I-D Needed
By Kepeng Li, Akbar Rahman, Carsten Bormann, 2018-02-26 TXT HTML PDF
Abstract: JavaScript Object Notation, JSON (RFC 8259) 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.
- Using Early Data in HTTP (draft-ietf-httpbis-replay): In Last Call » Waiting for Writeup
By Martin Thomson, Mark Nottingham, Willy Tarreau, 2017-11-23 TXT HTML PDF
Abstract: This document explains the risks of using early data for HTTP and describes techniques for reducing them. In particular, it defines a mechanism that enables clients to communicate with servers about early data, to assure correct operation.
- SMTP MTA Strict Transport Security (MTA-STS) (draft-ietf-uta-mta-sts): In Last Call » Waiting for AD Go-Ahead::Revised I-D Needed
By Daniel Margolis, Mark Risher, Binu Ramakrishnan, Alexander Brotman, Janet Jones, 2018-04-04 TXT HTML PDF
Abstract: SMTP Mail Transfer Agent Strict Transport Security (MTA-STS) is a mechanism enabling mail service providers to declare their ability to receive Transport Layer Security (TLS) secure SMTP connections, and to specify whether sending SMTP servers should refuse to deliver to MX hosts that do not offer TLS with a trusted server certificate.
- Zstandard Compression and The application/zstd Media Type (draft-kucherawy-dispatch-zstd): In Last Call » Waiting for Writeup
By Yann Collet, Murray Kucherawy, 2017-11-12 TXT HTML PDF
Abstract: Zstandard, or "zstd" (pronounced "zee standard"), is a data compression mechanism. This document describes the mechanism, and registers a media type to be used when transporting zstd-compressed via Multipurpose Internet Mail Extensions (MIME).
Drafts Sent to RFC Editor
Other Status Changes
- RTP Payload Format for the TETRA Audio Codec (draft-df-stecker-expertenforum-payload-tetra): Active » Replaced by draft-ietf-payload-tetra
By Andreas Reisenbauer, Udo Brandhuber, Joachim Hagedorn, Klaus-Peter Hohnsch, Stefan Wenk, 2018-01-09 TXT HTML PDF
Abstract: This document specifies a Real-time Transport Protocol (RTP) payload format to be used for TETRA encoded speech signals. The payload format is designed to be able to interoperate with existing TETRA transport formats on non-IP networks. This version of the document does not specify a file format for transport of TETRA speech data in storage mode applications such as email as would be required by the IETF. A media type registration is included, specifying the use of the RTP payload format and the storage format.
- draft-ietf-urnbis-rfc3188bis-nbn-urn: Expired » Replaced by draft-hakala-urn-nbn-rfc3188bis
No title available; expired document? TXT HTML PDF
RFC Editor Status Changes
- Signal-Free LISP Multicast (draft-ietf-lisp-signal-free-multicast): » AUTH48
By Victor Moreno, Dino Farinacci, 2018-03-09 TXT HTML PDF
Abstract: 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 decapsulators at the receiver LISP multicast sites.
- LPWAN Overview (draft-ietf-lpwan-overview): » AUTH48
By Stephen Farrell, 2018-02-07 TXT HTML PDF
Abstract: Low Power Wide Area Networks (LPWAN) are wireless technologies with characteristics such as large coverage areas, low bandwidth, possibly very small packet and application layer data sizes and long battery life operation. This memo is an informational overview of the set of LPWAN technologies being considered in the IETF and of the gaps that exist between the needs of those technologies and the goal of running IP in LPWANs.
- OSPF Graceful Link shutdown (draft-ietf-ospf-link-overload): » AUTH48
By Shraddha Hegde, Pushpasis Sarkar, Hannes Gredler, Mohan Nanduri, Luay Jalil, 2018-02-04 TXT HTML PDF
Abstract: 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 value on one side of the link is not sufficient to divert the traffic flowing in the other direction.
IPR Disclosures
IESG/IAB/IAOC/Trust Minutes
Liaison Statements
Classified Ads
|
WGs marked with an 
