Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel

Mary Barnes <mary.ietf.barnes@gmail.com> Mon, 27 October 2014 19:06 UTC

Return-Path: <mary.ietf.barnes@gmail.com>
X-Original-To: clue@ietfa.amsl.com
Delivered-To: clue@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 041C61AD013 for <clue@ietfa.amsl.com>; Mon, 27 Oct 2014 12:06:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypU2RMSyXnrJ for <clue@ietfa.amsl.com>; Mon, 27 Oct 2014 12:06:07 -0700 (PDT)
Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2836A1ACFF0 for <clue@ietf.org>; Mon, 27 Oct 2014 12:05:17 -0700 (PDT)
Received: by mail-lb0-f175.google.com with SMTP id u10so6205913lbd.20 for <clue@ietf.org>; Mon, 27 Oct 2014 12:05:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=eMiRk2QNf/ZtxVAorTrmbDeyWY9aYgTgWXQvoapq7uU=; b=DaY1OugPbu6AzxqLwRjRpE+WXx5FZSoKBhEMtxqyu97XMsGzL5VHLcVSudhxmnQlQ4 V0BoABJtfVIJ23s6kbIrs53veyK8HYDYrK4uYgAfsPZBAa8O9VJ4pFKh4Ap3JHhCQqrJ URRGX/uFsf+Z2vf38DKty/ZKv6PtaTxPAAhD2KJFqf+rp0Eg8ptjyNsBUE2Or6YZAry1 deKHrHZ14HcqnDDKkblaLoNpq8ohJa7lcfQqtJNNyi0iLNG6alrqdvKo4SSc7jhg4Mxd bbAv4LMC1GEjPJaxQTqBrfXVLAcyBVkxJ18REuuIT3Slk9mRP35b8lJmCsPqDEfQ6cWX HiwQ==
MIME-Version: 1.0
X-Received: by 10.152.1.42 with SMTP id 10mr26365430laj.4.1414436716296; Mon, 27 Oct 2014 12:05:16 -0700 (PDT)
Received: by 10.25.42.134 with HTTP; Mon, 27 Oct 2014 12:05:16 -0700 (PDT)
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D4CE942@ESESSMB209.ericsson.se>
References: <949EF20990823C4C85C18D59AA11AD8B26950D@FR712WXCHMBA11.zeu.alcatel-lucent.com> <7594FB04B1934943A5C02806D1A2204B1D4CE942@ESESSMB209.ericsson.se>
Date: Mon, 27 Oct 2014 14:05:16 -0500
Message-ID: <CAHBDyN60XCOhCoikzX0m4ku0q50KKO3sWANAJVGL+-rt558rmw@mail.gmail.com>
From: Mary Barnes <mary.ietf.barnes@gmail.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>
Content-Type: multipart/alternative; boundary="089e013c65bc083f9305066c3658"
Archived-At: http://mailarchive.ietf.org/arch/msg/clue/ZD9T3yMUPFGvqAVskvro8TxQwVs
Cc: "clue@ietf.org" <clue@ietf.org>
Subject: Re: [clue] FW: draft-ejzak-mmusic-data-channel-sdpneg and draft-ejzak-mmusic-msrp-usage-data-channel
X-BeenThere: clue@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: CLUE - ControLling mUltiple streams for TElepresence <clue.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/clue>, <mailto:clue-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/clue/>
List-Post: <mailto:clue@ietf.org>
List-Help: <mailto:clue-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/clue>, <mailto:clue-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Oct 2014 19:06:11 -0000

When we discussed this at IETF-90, we said that we would consider it if the
updated document was submitted no later than September 1st (per the
minutes).  Of course, that date wasn't met.  My suggestion is that if there
is consensus to adopt this as an MMUSIC WG deliverable, we could add a
reference. BUT, I would still be concerned about delays in that work that
would result in CLUE documents sitting in the RFC editor's queue waiting
for that document.

As an individual, considering the overall pace of the work on that document
thus far, I would be quite worried about adding that as a dependency.

Regards,
Mary.

On Mon, Oct 27, 2014 at 1:26 PM, Christer Holmberg <
christer.holmberg@ericsson.com> wrote:

> FYI,
>
> Keith has submitted a new version of the SDP-data-channel-neg draft.
>
> Personally I think the mechanism would be useful, but I think it would be
> good to have a "CLUE opinion" also. Currently we only have an editor's note
> saying that we may consider the mechanism depending on how it progresses.
> But, as we know, nothing progresses by itself in IETF, so the question is
> whether we shall say "CLUE has an interest in this mechanism, and would
> like it to move forward".
>
> Regards,
>
> Christer
>
>
> -----Original Message-----
> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of DRAGE, Keith
> (Keith)
> Sent: 27 October 2014 16:39
> To: mmusic@ietf.org
> Subject: [MMUSIC] draft-ejzak-mmusic-data-channel-sdpneg and
> draft-ejzak-mmusic-msrp-usage-data-channel
>
> Based on the discussion on list over the last few days, I have submitted
> revised versions of the two SDP negotiation over data channel drafts as
> follows:
>
> A new version of I-D, draft-ejzak-mmusic-data-channel-sdpneg-02.txt
> has been successfully submitted by Keith Drage and posted to the IETF
> repository.
>
> Name:           draft-ejzak-mmusic-data-channel-sdpneg
> Revision:       02
> Title:          SDP-based "SCTP over DTLS" data channel negotiation
> Document date:  2014-10-27
> Group:          Individual Submission
> Pages:          22
> URL:
> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-data-channel-sdpneg-02.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-data-channel-sdpneg/
> Htmlized:
> http://tools.ietf.org/html/draft-ejzak-mmusic-data-channel-sdpneg-02
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-data-channel-sdpneg-02
>
> Abstract:
>    The Real-Time Communication in WEB-browsers (RTCWeb) working group is
>    charged to provide protocols to support direct interactive rich
>    communications using audio, video, and data between two peers' web-
>    browsers.  For the support of data communication, the RTCWeb working
>    group has in particular defined the concept of bi-directional data
>    channels over SCTP, where each data channel might be used to
>    transport other protocols, called sub-protocols.  Data channel setup
>    can be done using either the internal in-band band (also referred to
>    as 'internal' for the rest of the document) WebRTC Data Channel
>    Establishment Protocol or some external out-of-band simply referred
>    to as 'external negotiation' in the rest of the document . This
>    document specifies how the SDP offer/answer exchange can be used to
>    achieve such an external negotiation.  Even though data channels are
>    designed for RTCWeb use initially they may be used by other protocols
>    like, but not limited to, the CLUE protocol.  This document is
>    intended to be used wherever data channels are used.
>
>
> A new version of I-D, draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
> has been successfully submitted by Keith Drage and posted to the IETF
> repository.
>
> Name:           draft-ejzak-mmusic-msrp-usage-data-channel
> Revision:       01
> Title:          MSRP over SCTP/DTLS data channels
> Document date:  2014-10-27
> Group:          Individual Submission
> Pages:          11
> URL:
> http://www.ietf.org/internet-drafts/draft-ejzak-mmusic-msrp-usage-data-channel-01.txt
> Status:
> https://datatracker.ietf.org/doc/draft-ejzak-mmusic-msrp-usage-data-channel/
> Htmlized:
> http://tools.ietf.org/html/draft-ejzak-mmusic-msrp-usage-data-channel-01
> Diff:
> http://www.ietf.org/rfcdiff?url2=draft-ejzak-mmusic-msrp-usage-data-channel-01
>
> Abstract:
>    This document specifies how the Message Session Relay Protocol (MSRP)
>    can be instantiated as a data channel sub-protocol, using the the SDP
>    offer/answer exchange-based external negotiation defined in
>    [I-D.ejzak-mmusic-data-channel-sdpneg].  Two network configurations
>    are documented: a WebRTC end-to-end configuration (connecting two
>    MSRP over data channel endpoints), and a gateway configuration
>    (connecting an MSRP over data channel endpoint with an MSRP over TCP
>    endpoint).
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> clue mailing list
> clue@ietf.org
> https://www.ietf.org/mailman/listinfo/clue
>