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

Michael Tüxen via Datatracker <noreply@ietf.org> Tue, 19 March 2019 08:33 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mmusic@ietf.org
Delivered-To: mmusic@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E66F1311F9; Tue, 19 Mar 2019 01:33:08 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Michael Tüxen via Datatracker <noreply@ietf.org>
To: tsv-art@ietf.org
Cc: draft-ietf-mmusic-data-channel-sdpneg.all@ietf.org, ietf@ietf.org, mmusic@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.94.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Michael Tüxen <tuexen@fh-muenster.de>
Message-ID: <155298438841.18151.544289728579176822@ietfa.amsl.com>
Date: Tue, 19 Mar 2019 01:33:08 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/xbTFOnZ00yhqWwAQEAyEvWrHIh0>
Subject: [MMUSIC] Tsvart last call review of draft-ietf-mmusic-data-channel-sdpneg-24
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
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:33:09 -0000

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'