Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - Comment on subprotocol specifications

Roni Even <roni.even@huawei.com> Mon, 04 December 2017 14:03 UTC

Return-Path: <roni.even@huawei.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E115127444 for <mmusic@ietfa.amsl.com>; Mon, 4 Dec 2017 06:03:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level:
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 XIlQVAdGvfDZ for <mmusic@ietfa.amsl.com>; Mon, 4 Dec 2017 06:03:20 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 71177127369 for <mmusic@ietf.org>; Mon, 4 Dec 2017 06:03:20 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 533DDD629E355; Mon, 4 Dec 2017 14:03:17 +0000 (GMT)
Received: from DGGEMM405-HUB.china.huawei.com (10.3.20.213) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Mon, 4 Dec 2017 14:03:18 +0000
Received: from DGGEMM506-MBS.china.huawei.com ([169.254.4.14]) by DGGEMM405-HUB.china.huawei.com ([10.3.20.213]) with mapi id 14.03.0361.001; Mon, 4 Dec 2017 22:02:47 +0800
From: Roni Even <roni.even@huawei.com>
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - Comment on subprotocol specifications
Thread-Index: AQHTbQSColMyBnIAJ0208YZM8KMNHaMzNWUw
Date: Mon, 04 Dec 2017 14:02:46 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD8503FA@DGGEMM506-MBS.china.huawei.com>
References: <D64B1D17.26F90%christer.holmberg@ericsson.com>
In-Reply-To: <D64B1D17.26F90%christer.holmberg@ericsson.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.203.55]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/U8pBCKuAUcdTq_3Uvvo7UgCZlMs>
Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-sdpneg-14.txt - Comment on subprotocol specifications
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Dec 2017 14:03:22 -0000

Hi Christer,
This sentence is partially correct, I will change based on your proposed text but mention that MSRP usage is in https://tools.ietf.org/html/draft-ietf-mmusic-msrp-usage-data-channel-07 with informative reference.
Roni

> -----Original Message-----
> From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]
> Sent: יום ב 04 דצמבר 2017 15:34
> To: Roni Even; mmusic@ietf.org
> Subject: Re: [MMUSIC] FW: I-D Action: draft-ietf-mmusic-data-channel-
> sdpneg-14.txt - Comment on subprotocol specifications
> 
> Hi,
> 
> Section 1 says:
> 
>    "Procedures specific to each subprotocol such as MSRP are documented
> elsewhere."
> 
> 
> I think we should say “would have to be documented elsewhere”, because
> we don’t know whether they will be.
> 
> Regards,
> 
> Christer
> 
> 
> 
> On 04/12/17 08:07, "mmusic on behalf of Roni Even"
> <mmusic-bounces@ietf.org on behalf of roni.even@huawei.com> wrote:
> 
> >Hi,
> >
> >This new revision addresses all nits pointed out by the idnits tool.
> >As a new editor, I looked at the MMUSIC mail archive and as far as I
> >can tell there were no open issues from the list.
> >
> >Thanks
> >Roni Even
> >
> >
> >-----Original Message-----
> >From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of
> >internet-drafts@ietf.org
> >Sent: יום א 03 דצמבר 2017 18:28
> >To: i-d-announce@ietf.org
> >Cc: mmusic@ietf.org
> >Subject: [MMUSIC] I-D Action:
> >draft-ietf-mmusic-data-channel-sdpneg-14.txt
> >
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >This draft is a work item of the Multiparty Multimedia Session Control
> >WG of the IETF.
> >
> >        Title           : SDP-based Data Channel Negotiation
> >        Authors         : Keith Drage
> >                          Maridi R. Makaraju
> >                          Juergen Stoetzer-Bradler
> >                          Richard Ejzak
> >                          Jerome Marcon
> >                          Roni Even
> >	Filename        : draft-ietf-mmusic-data-channel-sdpneg-14.txt
> >	Pages           : 41
> >	Date            : 2017-12-03
> >
> >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 (Stream Control Transmission Protocol), where each
> >   data channel might be used to transport other protocols, called
> >   subprotocols.  Data channel setup can be done using either the in-
> >   band Data Channel Establishment Protocol (DCEP) or using some out-of-
> >   band non-DCEP protocol.  This document specifies how the SDP (Session
> >   Description Protocol) offer/answer exchange can be used to achieve
> >   such an out-of-band non-DCEP 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 (which is
> >   defined by the IETF "ControLling mUltiple streams for tElepresence"
> >   working group).  This document is intended to be used wherever data
> >   channels are used.
> >
> >
> >The IETF datatracker status page for this draft is:
> >https://datatracker.ietf.org/doc/draft-ietf-mmusic-data-channel-sdpneg/
> >
> >There are also htmlized versions available at:
> >https://tools.ietf.org/html/draft-ietf-mmusic-data-channel-sdpneg-14
> >https://datatracker.ietf.org/doc/html/draft-ietf-mmusic-data-channel-sd
> >pne
> >g-14
> >
> >A diff from the previous version is available at:
> >https://www.ietf.org/rfcdiff?url2=draft-ietf-mmusic-data-channel-sdpneg
> >-14
> >
> >
> >Please note that it may take a couple of minutes from the time of
> >submission until the htmlized version and diff are available at
> >tools.ietf.org.
> >
> >Internet-Drafts are also available by anonymous FTP at:
> >ftp://ftp.ietf.org/internet-drafts/
> >
> >_______________________________________________
> >mmusic mailing list
> >mmusic@ietf.org
> >https://www.ietf.org/mailman/listinfo/mmusic
> >
> >_______________________________________________
> >mmusic mailing list
> >mmusic@ietf.org
> >https://www.ietf.org/mailman/listinfo/mmusic