Re: [MMUSIC] Tsvart last call review of draft-ietf-mmusic-data-channel-sdpneg-24

"Roni Even (A)" <roni.even@huawei.com> Tue, 19 March 2019 08:42 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 A7DDE1311FA; Tue, 19 Mar 2019 01:42:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=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 RiXStl_37jeq; Tue, 19 Mar 2019 01:42:24 -0700 (PDT)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (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 DE06B1311F7; Tue, 19 Mar 2019 01:42:23 -0700 (PDT)
Received: from LHREML711-CAH.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id 20689998E132ECA67561; Tue, 19 Mar 2019 08:42:22 +0000 (GMT)
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by LHREML711-CAH.china.huawei.com (10.201.108.34) with Microsoft SMTP Server (TLS) id 14.3.408.0; Tue, 19 Mar 2019 08:42:21 +0000
Received: from DGGEMM526-MBX.china.huawei.com ([169.254.8.251]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Tue, 19 Mar 2019 16:42:17 +0800
From: "Roni Even (A)" <roni.even@huawei.com>
To: =?utf-8?B?TWljaGFlbCBUw7x4ZW4=?= <tuexen@fh-muenster.de>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org" <draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "mmusic@ietf.org" <mmusic@ietf.org>
Thread-Topic: Tsvart last call review of draft-ietf-mmusic-data-channel-sdpneg-24
Thread-Index: AQHU3i5nBnuyOfWx5kSKF4bTaGULyqYSosCw
Date: Tue, 19 Mar 2019 08:42:17 +0000
Message-ID: <6E58094ECC8D8344914996DAD28F1CCD18CC98C2@dggemm526-mbx.china.huawei.com>
References: <155298438841.18151.544289728579176822@ietfa.amsl.com>
In-Reply-To: <155298438841.18151.544289728579176822@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.200.202.69]
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/UJYv2VMQIradg3wsOknxnMCcvTs>
Subject: Re: [MMUSIC] Tsvart last call review of draft-ietf-mmusic-data-channel-sdpneg-24
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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: Tue, 19 Mar 2019 08:42:26 -0000

Michael,
Thanks, I will update the document accordingly
Roni

-----Original Message-----
From: Michael Tüxen via Datatracker [mailto:noreply@ietf.org] 
Sent: Tuesday, March 19, 2019 10:33 AM
To: tsv-art@ietf.org
Cc: draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org; ietf@ietf.org; mmusic@ietf.org
Subject: Tsvart last call review of draft-ietf-mmusic-data-channel-sdpneg-24

Reviewer: Michael Tüxen
Review result: Ready with Nits

This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information.

When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review.

This document describes the usage of SDP for out-of-band data channel negotiation.

Abstract
in- band -> in-band
our-of- band -> out-of-band

1. Introduction
prtocols -> protocols

5.1.1 DCMAP Attribute Syntax
... 'maxtime-opt' parameter may be present -> ... 'maxtime-opt' parameter MAY be present

5.1.5 Max-retr Parameter

If the max-retr parameter is not present, then the maximal number of retransmissions is determined as per the generic SCTP retransmission rules as specified in [RFC4960].

The is no maximum number of retransmissions of a user message or chunk.
I would suggest to use something like

If the max-retr parameter and the max-time parameter are not present, then reliable transmission is performed as specified in [RFC4960].

5.1.6 Max-time Parameter

If the max-time parameter is not present, then the generic SCTP retransmission timing rules apply as specified in [RFC4960].

This also doesn't really fit, since the retransmission timing rules specify when the next retransmission is performed. There is no 'deadline'. So I would suggest to use something like:

If the max-retr parameter and the max-time parameter are not present, then reliable transmission is performed as specified in [RFC4960].

6.6.1 Offerer Processing of the SDP Answer immediately re-uses the SCTP stream:
 Don't you need to wait until the stream reset procedure is finished?

6.2.  Negotiating Data Channel Parameters so Both MUST NOT be present -> so both MUST NOT be present

General
'a SDP' versus 'an SDP'