Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)
draft-ietf-avtcore-6222bis-06

Approval announcement
Draft of message to be sent after approval:

Announcement

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    avtcore mailing list <avt@ietf.org>,
    avtcore chair <avtcore-chairs@tools.ietf.org>
Subject: Protocol Action: 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names (CNAMEs)' to Proposed Standard (draft-ietf-avtcore-6222bis-06.txt)

The IESG has approved the following document:
- 'Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names
   (CNAMEs)'
  (draft-ietf-avtcore-6222bis-06.txt) as Proposed Standard

This document is the product of the Audio/Video Transport Core
Maintenance Working Group.

The IESG contact persons are Richard Barnes and Gonzalo Camarillo.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/

Ballot Text

Technical Summary

   The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a
   persistent transport-level identifier for an RTP endpoint.  While the
   Synchronization Source (SSRC) identifier of an RTP endpoint may
   change if a collision is detected or when the RTP application is
   restarted, its RTCP CNAME is meant to stay unchanged, so that RTP
   endpoints can be uniquely identified and associated with their RTP
   media streams.

   For proper functionality, RTCP CNAMEs should be unique within the
   participants of an RTP session.  However, the existing guidelines for
   choosing the RTCP CNAME provided in the RTP standard are insufficient
   to achieve this uniqueness.  RFC 6222 was published to update those
   guidelines to allow endpoints to choose unique RTCP CNAMEs.
   Unfortunately, later investigations showed that some parts of the new
   algorithms were unnecessarily complicated and/or ineffective.  This
   document addresses these concerns and replaces RFC 6222.
   
Working Group Summary

The requirements for this replacement of RFC 6222 came from RTCWEB WG, which identified the linkability and privacy issue of the previous random method. There was strong WG consensus to address this issue. The method of addressing it, using a cryptographic random number generator, was obvious. The main concern in WG last call has been around the clarity of the motivation for the update. 


Document Quality

The Shepherd assumes that this will see significant implementation, especially initially in any WebRTC implementations. The document has gotten a fair amount of reviews in the WG last call. 

Personnel

  Magnus Westerlund is the Document Shepherd. 
  Richard Barnes is the Responsible Area Director.

RFC Editor Note