Document Action: 'CLUE Protocol data channel' to Experimental RFC (draft-ietf-clue-datachannel-17.txt)

The IESG <iesg-secretary@ietf.org> Wed, 17 April 2019 19:13 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: ietf-announce@ietf.org
Delivered-To: ietf-announce@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 94795120363; Wed, 17 Apr 2019 12:13:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Subject: Document Action: 'CLUE Protocol data channel' to Experimental RFC (draft-ietf-clue-datachannel-17.txt)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.95.0
Auto-Submitted: auto-generated
Precedence: bulk
Cc: The IESG <iesg@ietf.org>, adam@nostrum.com, draft-ietf-clue-datachannel@ietf.org, clue@ietf.org, pkyzivat@alum.mit.edu, clue-chairs@ietf.org, Paul Kyzivat <pkyzivat@alum.mit.edu>, rfc-editor@rfc-editor.org
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Message-ID: <155552839254.21192.10686144667011745150.idtracker@ietfa.amsl.com>
Date: Wed, 17 Apr 2019 12:13:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-announce/Hu2JTKfTElMy3t3ktXfHf9Uu43U>
X-BeenThere: ietf-announce@ietf.org
X-Mailman-Version: 2.1.29
List-Id: "IETF announcement list. No discussions." <ietf-announce.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-announce/>
List-Post: <mailto:ietf-announce@ietf.org>
List-Help: <mailto:ietf-announce-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:ietf-announce-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 17 Apr 2019 19:13:13 -0000

The IESG has approved the following document:
- 'CLUE Protocol data channel'
  (draft-ietf-clue-datachannel-17.txt) as Experimental RFC

This document is the product of the ControLling mUltiple streams for
tElepresence Working Group.

The IESG contact persons are Adam Roach, Alexey Melnikov and Barry Leiba.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-clue-datachannel/





Technical Summary

  This document defines how to use the WebRTC data channel mechanism in
  order to realize a data channel, referred to as a CLUE data channel,
  for transporting CLUE protocol messages between two CLUE entities.

  The document defines how to describe the SCTP over DTLS association used
  to realize the CLUE data channel using the Session Description
  Protocol (SDP), and defines usage of the SDP-based "SCTP over DTLS" data
  channel negotiation mechanism for establishing a CLUE data channel.

  Details and procedures associated with the CLUE protocol, and the SDP
  Offer/Answer procedures for negotiating usage of a CLUE data channel,
  are outside the scope of this document.

Working Group Summary

  There was some difficulty in deciding what mechanism to use to establish 
  the CLUE data channel: whether to the in-band mechanism of 
  draft-ietf-rtcweb-data-protocol, or the SDP offer/answer mechanism of 
  draft-ietf-mmusic-data-channel-sdpneg. Since offer/answer is heavily used 
  in CLUE, the O/A mechanism was preferred, but the work on defining it 
  lagged, and it isn't overtly supported in RTCWEB. But the work on that 
  draft has advanced well so that the group is now willing to accept that 
  dependency. 

Document Quality

  Are there existing implementations of the protocol? 

    One vendor has prototyped and demonstrated CLUE support in
    their product.

  Have a significant number of vendors indicated their plan to 
  implement the specification? 

    Beyond the prototype, no specific plans have yet been announced.

  Are there any reviewers that 
  merit special mention as having done a thorough review, 
  e.g., one that resulted in important changes or a 
  conclusion that the document had no substantive issues? 

    None that stand out.

  If there was a MIB Doctor, Media Type or other expert review, 
  what was its course (briefly)? In the case of a Media Type 
  review, on what date was the request posted?

    None apply to this document

Personnel

  Who is the Document Shepherd? 

    Paul Kyzivat

  Who is the Responsible Area Director?

    Adam Roach