Re: [MMUSIC] New draft version draft-ietf-mmusic-data-channel-sdpneg-03

Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com> Wed, 22 July 2015 12:08 UTC

Return-Path: <juergen.stoetzer-bradler@alcatel-lucent.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B0C51A0161 for <mmusic@ietfa.amsl.com>; Wed, 22 Jul 2015 05:08:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] 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 szUunYLNxtP9 for <mmusic@ietfa.amsl.com>; Wed, 22 Jul 2015 05:08:27 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpgre-esg-01.alcatel-lucent.com [135.245.210.22]) (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 D94661A00DD for <mmusic@ietf.org>; Wed, 22 Jul 2015 05:08:26 -0700 (PDT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (unknown [135.239.2.122]) by Websense Email Security Gateway with ESMTPS id A4D724D786E99 for <mmusic@ietf.org>; Wed, 22 Jul 2015 12:08:22 +0000 (GMT)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id t6MC8IvV019634 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Wed, 22 Jul 2015 14:08:24 +0200
Received: from [149.204.68.198] (135.239.27.39) by FR711WXCHHUB02.zeu.alcatel-lucent.com (135.239.2.112) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 22 Jul 2015 14:08:09 +0200
To: mmusic@ietf.org
References: <55AE4587.6020303@alcatel-lucent.com> <55AE9793.5000300@alum.mit.edu>
From: Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com>
Message-ID: <55AF87A8.3000704@alcatel-lucent.com>
Date: Wed, 22 Jul 2015 14:08:08 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <55AE9793.5000300@alum.mit.edu>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [135.239.27.39]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/GR7FvSdKH7eWaXFU68lU-YWfDv4>
Subject: Re: [MMUSIC] New draft version draft-ietf-mmusic-data-channel-sdpneg-03
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 22 Jul 2015 12:08:29 -0000

Hi Paul,

Thanks much for your comments.
Please see my replies inserted below.

Thank you,
Juergen

On 21.07.2015 21:03, Paul Kyzivat wrote:
> Thanks for doing this work. The draft is shaping up. Comments below.
>
> On 7/21/15 9:13 AM, Juergen Stoetzer-Bradler wrote:
>> Have submitted version 03 of draft-ietf-mmusic-data-channel-sdpneg.
>> This version solves Roni's comments 1 and 2 and 5 to 9
>> (http://www.ietf.org/mail-archive/web/mmusic/current/msg14790.html,
>> http://www.ietf.org/mail-archive/web/mmusic/current/msg14811.html).
>>
>> Roni's 10th comment was about the still missing IANA registration text
>> for the new SDP attributes dcmap and dcsa. Have added related
>> section headers, but the actual text still needs to be added.
>>
>> Roni's comments 3 and 4 were related to the (JaveScript) API related
>> text parts.
>> Have removed most of these text parts.
>> However, section 5.2.2 still contains some API related text.
>> Before also removing this I'd like to raise a slightly broader question.
>>
>> Sections 5.1 and 5.2 contain informative generic non-DCEP negotiation
>> related text,
>> which could mostly be removed from the document, as this draft now
>> exclusively
>> focuses on SDP offer/answer extensions.
>> Some parts might be moved to the related SDP offer/answer specific text
>> in section 6.
>> Have added a couple of related editor note's to sections 5.1 and 5.2
>> indicating
>> which text parts I think could be completely removed and which could be
>> moved to
>> section 6.
>>
>> Would that be agreeable?
>
> I think the concept makes sense. Right now it is extremely hard to read the draft with all the 
> editors notes and figure out how it might flow with those changes. IMO it would be better for you 
> to go ahead and make the changes, so that the result can be reviewed to see how it works.

[Juergen] Ok. Will do that.

>
> I find all the discussion of "non-DCEP negotiation" awkward. I do think it is better to simply 
> discuss "SDP negotiation". I don't think we need treatise on how other negotiations, other than 
> DCEP or SDP, work.

[Juergen] Ok. Had a look again at the text parts, where "non-DCEP negotiation" is mentioned. I think 
most of the related sentences could anyhow be deleted as discussed above.

>
> Other misc comments:
>
> Section 6 says:
>
>    This SDP extension can only be used with the SDP offer/answer model.
>
> I'm not sure if that is true or not. I think it would be better to say:
>
>    This SDP extension only defines usage in the context of SDP
>    offer/answer.

[Juergen] Agree. This is the intended meaning. Will change the sentence as you propose.

>
> Section 6.1.1 says:
>
>    The intention of exchanging these attributes is to create data
>    channels on both the peers with the same set of attributes without
>    actually using the DCEP [I-D.ietf-rtcweb-data-protocol].
>
> I think there is a bit more to say about this. I suggest:
>
>    The intention in exchanging these attributes is to create, on two
>    peers, without use of DCEP [I-D.ietf-rtcweb-data-protocol], matched
>    pairs of oppositely directed data channels having the same set of
>    attributes.

[Juergen] Agree. Will changes this.

>
> Section 6.1.1.5 says:
>
>    The 'max-retr' parameter indicates the maximal number a user message
>    will be retransmitted.
>
> In the edit a bit was lost. This should say:
>
>    The 'max-retr' parameter indicates the maximal number of times a
>    user message will be retransmitted.

[Juergen] Indeed. Thanks.

>
> Section 6.2.1 says:
>
>    However, an SDP offer/answer exchange MUST NOT be
>    initiated if the associated SCTP stream is already negotiated via
>    DCEP.
>
> This phrasing is awkward and confusing. I suggest:
>
>    However, an SCTP stream MUST NOT be referenced in a dcmap or
>    dcsa attribute of an SDP offer/answer exchange if the associated
>    SCTP stream has already been negotiated via DCEP.

[Juergen] That's more precise. Thanks much. Will change the sentence as you suggest.

>
> Note: above comments based only on reviewing the diffs. I didn't do another full review of the 
> document.
>
>     Thanks,
>     Paul
>
>