IETF

The Dynamic Host Configuration Working Group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses, IPv6 prefixes, IP protocol stack and other parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132.
DHCPv6 is currently a Proposed Standard and is being updated. The WG plans to advance the DHCPv6 protocol to Internet standard. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are generally outside of scope for the DHC WG.

The Real-time Transport Protocol (RTP) is an Internet Standard. RTP and its associated profiles and payload formats provides for real-time transmission of audio and video over unicast and multicast transports.

The Audio/Video Transport Core Maintenance (avtcore) Working Group in IETF is chartered to:

• Maintain the core RTP/RTCP specifications and the AVP, SAVP, AVPF, and SAVPF profiles.
• Develop application-specific guidelines for the use of RTP/RTCP protocols with the AVP, SAVP, AVPF, and SAVPF profiles, and extensions to those protocols that are driven by application-specific needs.
• Specify and maintain payload formats for use with RTP, developing RTP payload formats for new media codecs, review and revise existing payload formats to advance those that are especially
  useful to Internet Standard, and declare others Historic.
• Evaluate and process proposals for RTP eXtended Report Block (XRBLOCK) definitions containing new metrics.

The WG's milestones span early 2019 to Mar 2020.

The Dynamic Host Configuration Working Group (DHC WG) has developed DHCP for automated allocation, configuration and management of IP addresses, IPv6 prefixes, IP protocol stack and other parameters. DHCPv4 is currently a Draft Standard and is documented in RFC 2131 and RFC 2132.
DHCPv6 is currently a Proposed Standard and is being updated. The WG plans to advance the DHCPv6 protocol to Internet standard. The DHC WG is responsible for defining DHCP protocol extensions. Definitions of new DHCP options that are delivered using standard mechanisms with documented semantics are not considered a protocol extension and thus are generally outside of scope for the DHC WG.

The IETF Binary Floor Control Protocol Bis (BFCPBIS) working group is chartered to specify a revision of BFCP (RFC 4582) to support both TCP and UDP as transports.

• The revision adds optional support for UDP to BFCP. The security when using UDP will be based on DTLS. The updated protocol will use an existing approach (e.g., stop and wait with a single outstanding transaction) to provide a reliable, congestion safe, and TCP friendly transport.
• The updated protocol will also be able to deliver server-initiated transactions reliably when needed. The WG will research the size of messages used and decide if fragmenting a request or response over multiple UDP packets is required. The new protocol will be backwards compatible with RFC 4582 when used in TCP mode.
• The BFCPBIS WG coordinates closely with the MMUSIC WG to create a revision of RFC 4583 specifying how BFCP is signaled in SDP so that it supports UDP as well as TCP transports.

Most of the WG's milestones for applications and real-time area have been achieved.

Concise Binary Object Representation (CBOR, RFC 7049) extends the JavaScript Object Notation (JSON, RFC 8259) data interchange format to include binary data and an extensibility model, using a binary representation format that is easy to parse correctly. It has been picked up by a number of IETF efforts (e.g., CORE, ANIMA GRASP) as a message format.

• The IETF CBOR working group will update RFC 7049 to deal with existing errata. Security issues and clarifications may be addressed, but changes to the document will ensure backward compatibility for widespread deployed codebases. The resulting document will be targeted at becoming an Internet Standard.
• This WG falls under the IETF applications and real-time area.

The significant growth in content delivered over IP networks, existing CDN providers are scaling up their infrastructure and many Network Service Providers and Enterprise Service Providers are deploying their own CDNs. Work in IETF focuses on meeting the need to interconnect (previously) standalone CDNs to that can interoperate and collectively behave as a single delivery infrastructure.

The goal of the Content Delivery Networks Interconnection (CDNI) WG is to allow the interconnection of separately administered CDNs in support of the end-to-end delivery of content from CSPs through multiple CDNs and ultimately to end users (via their respective User Agents). The CDNI WG aims at delivering a  targeted, deployable solution in a short timeframe as needed by the industry. It is expected that the CDNI interfaces will be realised using existing IETF protocols for transport and message exchange, and using existing object notation grammars/languages for the definition of CDNI objects and semantics.

In the event that protocol extensions or new protocols are deemed necessary by the WG, the WG will recharter in mid-June 2020.
 

Using existing work done by the development communities of Matroska, FFV1, and FLAC, the IETF Working Group on Codec for LossLess Archiving and Realtime Transmission (CELLAR) will formalise specifications for these open and lossless formats. In order to provide authoritative, standardised specifications for users and developers, the Working Group will seek consensus throughout the process of refining and formalising these standards.

This WG fills gaps in terms of standardising open, transparent, self-descriptive, lossless formats as an important mission to be undertaken by the open source community. Work addresses concerns about the sustainability and credibility of existing specifications for the long-term use of these formats through a broader review and formalisation encourage widespread adoption.

The Working Group will seek consensus and refinements for specifications for both FFV1 and Matroska in order to provide authoritative, standardized specifications for users and developers. Backward compatibility with existing versions 0-3 of the FFV1 and Matroska specifications will be an important goal, while also reviewing and refining the current version 4 under active development.

A major factor limiting the interoperability of telepresence systems is the lack of a standardised way to describe and negotiate the use of the multiple streams of audio and video comprising the media flows.

The CLUE WG will create specifications for SIP-based conferencing systems to enable communication of information about media streams so that a sending system, receiving system, or intermediate system can make
reasonable decisions about transmitting, selecting, and rendering media streams. This enables systems to make choices that optimise user experience.

In the context of this WG, telepresence is used in a general manner to describe systems that provide high definition, high quality audio/video enabling a "being-there" experience.

IETF develops standards for automated network management which, as the name implies, aims to improve and make more efficient management of networks as they continue to increase in size and complexity.

IETF Autonomic Networking Integrated Model and Approach (ANIMA) working group develops and maintains specifications and documentation for interoperable protocols and procedures for automated network management and control of professionally-managed networks.

• ANIMA work will rely on the framework described in draft-ietf-anima-reference-model already approved for publication. Work not related to this framework is welcome for review, but WG adoption of such work requires explicit rechartering. The two concrete areas of the reference model are (1) the Autonomic Networking Infrastructure (ANI), and (2) Autonomic Functions (AF) built from software modules called Autonomic Service Agents (ASA).
• ANIMA will start to define Autonomic Functions (AF) to enable service automation in networks; it will also work on generic aspects of ASA including design guidelines and lifecycle management, coordination and dependency management.
• The life span of this WG is from 2019 with Information distribution over GRASP to the IESG submission in November to Jul 2020, when the WG will recharter or close.

The initial focus of this Working Group was the development of mechanisms that provide confidentiality and authentication between DNS Clients and Iterative Resolvers (published as RFCs 7858 and 8094). With proposed standard solutions for the client-to-iterative resolvers published, the working group turns its attention to the development of documents focused on: 1) providing confidentiality to DNS transactions between Iterative Resolvers and Authoritative Servers, 2) measuring the efficacy in preserving privacy in the face pervasive monitoring attacks, and 3) defining operational, policy, and security considerations for DNS operators offering DNS privacy services. Some of the results of this working group may be experimental.There are numerous aspects that differ between DNS exchanges with an iterative resolver and exchanges involving DNS root/authoritative servers. The working group will work with
DNS operators and developers (via the DNSOP WG) to ensure that proposed solutions address key requirements.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.