Re: [MMUSIC] New draft version: draft-ietf-mmusic-msrp-usage-data-channel-01

Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com> Wed, 11 March 2015 15:42 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 D052B1A000D for <mmusic@ietfa.amsl.com>; Wed, 11 Mar 2015 08:42:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.71
X-Spam-Level:
X-Spam-Status: No, score=-5.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, 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 pS_soWZoGAb9 for <mmusic@ietfa.amsl.com>; Wed, 11 Mar 2015 08:41:52 -0700 (PDT)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 7111D1A0037 for <mmusic@ietf.org>; Wed, 11 Mar 2015 08:41:52 -0700 (PDT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (unknown [135.239.2.42]) by Websense Email Security Gateway with ESMTPS id A55D5E40A6273 for <mmusic@ietf.org>; Wed, 11 Mar 2015 15:41:47 +0000 (GMT)
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id t2BFfjwY019970 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Wed, 11 Mar 2015 16:41:50 +0100
Received: from [149.204.68.136] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 11 Mar 2015 16:41:48 +0100
Message-ID: <5500623B.9070604@alcatel-lucent.com>
Date: Wed, 11 Mar 2015 16:41:47 +0100
From: Juergen Stoetzer-Bradler <Juergen.Stoetzer-Bradler@alcatel-lucent.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <54FD7E79.8010600@alcatel-lucent.com> <54FE6446.7020007@nteczone.com>
In-Reply-To: <54FE6446.7020007@nteczone.com>
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/DNyv2yiBoOQh0OFTHGwshRIatEU>
Subject: Re: [MMUSIC] New draft version: draft-ietf-mmusic-msrp-usage-data-channel-01
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: <http://www.ietf.org/mail-archive/web/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, 11 Mar 2015 15:42:04 -0000

Hello Christian,

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

Thanks,
Juergen

On 10.03.2015 04:25, Christian Groves wrote:
> Hello Juergen,
>
> Thanks for the update. Some comments:
> 5.1.1.1 - The section indicates that the max-retr, max-time and
>    ordered parameters shall not be used. I take it then that the SCTP Stream used for MSRP must be 
> DATA_CHANNEL_RELIABLE? If so it might be better to say what is used rather than what is not.

[Juergen] Agree. Would propose to replaced current sentence "The max-retr, max-time and ordered 
parameters shall not be used" with
"Ordered and reliable data channels MUST always be used, such that the 'max-retr' and 'max-time' 
parameters SHALL NOT be used.
If the 'ordered' parameter is used, then its value MUST be equal to 'true'."

>
> 5.1.1.1 - The text regarding the SCTP port can be removed because of recent changes to 
> draft-ietf-mmusic-sctp-sdp removing the concept of default port.

[Juergen] Yes, agree. We'll remove the text in parentheses: "(on default SCTP port 5000)".

>
> 5.1.1.2 1st paragraph - I propose to re-order to make it clear there's one dcsa line per MSRP 
> specific attribute:
>
>    The SDP offer shall also include within the media description
>    for the SCTP association a dcsa attribute line (defined in
>    [I-D.ietf-mmusic-data-channel-sdpneg]) for each MSRP-specific SDP attribute to be
>    negotiated for each MSRP data channel being negotiated.

[Juergen] Indeed, that's clearer. We'll change the text as you propose.

>
> 5.1.1.2: MSRP "max-size" would it be worth to note that this must be less than the SCTP SDP 
> max-message-size value?

[Juergen] That's a good point. As far as I understand the a=max-message-size value
is related to the “maximum message size that an SCTP endpoint is willing to receive”
as per draft-ietf-mmusic-sctp-sdp-14, sec 6.1, whereas the MSRP specific a=max-size attribute
refers to the maximum MSRP message size an endpoint is willing to accept (as per 4975, sec 8.6),
thus is not related to the maximum MSRP message chunk size.
Would you be OK if we added a sentence to 5.1.1.2 saying that an MSRP session endpoint
MUST NOT send MSRP message chunks larger than  the peer’s a=max-message-size value?

>
> 5.1.1.2: "Setup" is this relevant for MSRP using data channel? The SCTP-SDP draft etc. give rules 
> as to which endpoint establishes different parts of the transport connection?

[Juergen] Good point, too. The msrp-usage draft requires MSRP UAs using data channel transport
to support the MSRP CEMA extension as described in RFC 6714. This again refers to RFC 6135,
which uses the a=setup attribute value to determine the "active" MSRP UA, which is responsible for 
sending
the initial MSRP SEND message (which might be empty).
Also msrp-usage draft's section 5.1.2 currently requests the "active" MSRP endpoint to send an
MSRP SEND message as as soon as the associated data channel instance is opened.
Per draft-ietf-mmusic-sctp-sdp-14 the "a=setup" attribute contained in the DTLS/SCTP based media 
description
is used to determine the TCP (if used) and DTLS client/server roles. But this usage of the "a=setup" 
attribute
is different than the usage of "a=setup" as described in RFC 6135's section 4.2.
I assume we may have to describe more explicitly in msrp-usage how it is determined if an MSRP endpoint
becomes "active" (and sends the initial MSRP SEND message).

>
> 5.1.1.3: a=sctp-port 5000 should have a colon e.g. a=sctp-port:5000

[Juergen] Thanks. We'll correct this.

>
> 5.1.5: This section indicates that closing is done as per I-D.ietf-mmusic-data-channel-sdpneg. 
> However clause 5.2.4/I-D.ietf-mmusic-data-channel-sdpneg indicates that closure is sub-protocol 
> specific. Its not clear to me whether this the sub-protocol should indicate the use of the SCTP 
> reset or the use of SDP O/A?

[Juergen] The intention in 5.1.5 is to refer to the generic data channel closure procedure based on
the SCTP stream reset mechanism, and that additionally per new SDP offer / answer exchange
the a=dcmap and a=dcsa attribute lines associated with the MSRP session need to be removed
from the DTLS/SCTP based media description.
Would you agree if we explicitly said:
“The closure of an MSRP session MUST be signaled via an SDP offer / answer exchange which
removes the "a=dcmap:" and "a=dcsa:" attribute lines associated with the MSRP session from
the associated DTLS/SCTP based media description.
This results in the associated data channel being closed as well as per 
[I-D.ietf-mmusic-data-channel-sdpneg].”

>
> Regards, Christian
>
>

[snip]