[MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20

Alissa Cooper <alissa@cooperw.in> Thu, 22 May 2014 19:42 UTC

Return-Path: <alissa@cooperw.in>
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 3143B1A0357 for <mmusic@ietfa.amsl.com>; Thu, 22 May 2014 12:42:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, T_FILL_THIS_FORM_SHORT=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 4QYpbEhuq1pO for <mmusic@ietfa.amsl.com>; Thu, 22 May 2014 12:42:43 -0700 (PDT)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEF801A035C for <mmusic@ietf.org>; Thu, 22 May 2014 12:42:36 -0700 (PDT)
Received: from compute1.internal (compute1.nyi.mail.srv.osa [10.202.2.41]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id B168820AC9 for <mmusic@ietf.org>; Thu, 22 May 2014 15:42:34 -0400 (EDT)
Received: from frontend2 ([10.202.2.161]) by compute1.internal (MEProxy); Thu, 22 May 2014 15:42:34 -0400
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h=date :subject:from:to:message-id:mime-version:content-type :content-transfer-encoding; s=mesmtp; bh=AFCGpweaJBSEFwfOKvWAPJB zGkw=; b=vrk+ImD6EsS6eRZVO0Ru7ffDLmaSf4/m/9rl/6pn35EpFJIeY+GfPJE BSX5H9QMlsGKLJmmIt7yqfwrws8CGayo55+Qascq1TPUcksYmGHVPgoFYJ6Y4ghX gnTkcP7BslV7IJpccDcPNjvfsXJf/BgIBpZblb7JBWFkapCbSvDE=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:subject:from:to:message-id :mime-version:content-type:content-transfer-encoding; s=smtpout; bh=AFCGpweaJBSEFwfOKvWAPJBzGkw=; b=gTcDQolNERguX1j91WlIEyyZmThd eRIQUNqhwmGoK899RNx4e/1sYdN2XPU14U4t1uZOEOkR/BA0JCrEajlm+inaMoTE pV3rF8YIAMwvw2kI59RAkdpV+qSjVA1y8kZ9lG99JaMX4omoHlXHiMMCGNt4xQXD JFR6yi+ipryN44o=
X-Sasl-enc: exzw5xopnW78qnLTG/+FlXK/U1iBIuYw/ieP4x5izEfu 1400787749
Received: from [10.150.9.165] (unknown [64.102.254.33]) by mail.messagingengine.com (Postfix) with ESMTPA id 84F2068013A for <mmusic@ietf.org>; Thu, 22 May 2014 15:42:27 -0400 (EDT)
User-Agent: Microsoft-MacOutlook/14.3.9.131030
Date: Thu, 22 May 2014 15:42:23 -0400
From: Alissa Cooper <alissa@cooperw.in>
To: mmusic@ietf.org
Message-ID: <CFA3CB5F.3BF69%alissa@cooperw.in>
Thread-Topic: AD evaluation: draft-ietf-mmusic-rtsp-nat-20
Mime-version: 1.0
Content-type: text/plain; charset="UTF-8"
Content-transfer-encoding: quoted-printable
Archived-At: http://mailarchive.ietf.org/arch/msg/mmusic/1aI6PvIobrhBT81cYTrPH8lpJJk
Subject: [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-nat-20
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: Thu, 22 May 2014 19:42:46 -0000

I have reviewed draft-ietf-mmusic-rtsp-nat-20 in preparation for IETF LC.
The document is in good shape. I have a few questions and comments below
that need to be resolved before issuing the last call. I’ve also included
a list of nits that should be resolved in the next rev.

Comments and questions:

Sec 4.2:
"The connection address SHOULD use the same format
      (explicit IP or FQDN) as in the dest_addr parameter used to
      express fallbacks.”

Per 4.1, I thought the dest_addr MUST NOT be included, so this requirement
seems contradictory.

"<tcp-type-ext>:  conveys the candidates connection type (active,
      passive, or S-O) for TCP based candidates.  This MUST be included
      for candidates that have <transport> set to TCP and MUST NOT be
      included for other transport types, including UDP, unless
      explicitly specified for that transport protocol."

I’m assuming the last phrase means “unless <something> gets specified in
the future for that transport protocol.” But I’m not clear on what the
<something> is.

Sec 4.4:
"The RTSP client SHOULD send the feature tag "setup.ice-d-m" in the
   "Supported" header in all SETUP requests that contain the "D-ICE"
   lower layer transport.”

What are the situations where the SETUP request contains “D-ICE” but where
the feature tag should not be included? Is it for SETUP requests issued
after media is already playing (as described in Sec 6.13)?

Sec 6.5:
"The server determines if the SETUP request is successful from the
   other perspectives”

It’s not clear what is meant by “from the other perspectives.”

Sec 6.10:
"If the 480 response is received or sent in response to a PLAY
   request, the server MUST NOT free its gathered candidates."

The “received or sent” part doesn’t quite make sense, since we’re talking
about the server, right? Shouldn’t this just say “sent”?

Sec 6.13:
See comments on Sec 4.4 above — why is the Supported header not included
in the SETUP requests in this example?

Sec 7.1 and 7.2:
Again with reference to Sec 4.4 — why is the "setup.ice-d-m” feature tag
mandatory for media proxies but recommended for clients and signaling
proxies?

Sec 7.3:
"Unfortunately, the usage of the "setup.ice-d-m" feature tag in the
   Proxy-Require will have contradicting results.”

This sentence and the paragraph that follows are confusing because there
is no prior mention of putting the feature tag in the Proxy-Require header
(although I guess it was implicitly assumed). I think what you meant is
this:

"The usage of the “setup.ice-d-m” feature tag in the Proxy-Require header
is NOT RECOMMENDED because it can have contradictory results.”

Sec 8:
"This multiplexing SHALL be combined with ICE”

I think s/ICE/ICE-RTSP/ makes sense here.

"Due to the above mentioned benefits, RTSP servers and clients that
   support "D-ICE" lower layer transport in combination with RTP SHALL
   also implement RTP and RTCP multiplexing as specified in this section
   and [RFC5761].”

Multiplexing is not specified in this section. Did you mean as specified
in Appendix C of draft-ietf-mmusic-rfc2326bis and RFC5761?



Nits:

There are a couple of idnits that should be fixed.

Sec 1:
s/when PLAY request are/when PLAY requests are/

Sec 4.2:
OLD:
<foundation>:   is an identifier that is equivalent for two
      candidates that are of the same type, share the same base, and
      come from the same STUN server, and is composed of one to thirty
      two <ice-char>.


NEW:
<foundation>:   is an identifier that is equivalent for two
      candidates that are of the same type, share the same base IP
address, and
      come from the same STUN server. It is composed of 1 to 32
<ice-char>s.


s/is used when the second component/is used, in which case the second
component/

s/the Allocate Response/the TURN Allocate Response/

s/<tcp-type-ext>:  conveys the candidates connection type/<tcp-type-ext>:
conveys the candidate’s connection type/

Sec 4.4:
s/RTSP agents; clients, servers and proxies./RTSP agents: clients, servers
and proxies./

Sec 6.12:
s/First, if it can attempt/First, it can attempt/

s/or change the transport parameters./or changing the transport
parameters./

s/SHALL use Regular nomination./SHALL use regular nomination./

Sec 6.13:
s/A Server/A server/

s/gather new ICE candidates, and send/gather new ICE candidates and send/

s/If not the client will/If not, the client will/

Sec 7.3:
s/non ICE/non-ICE/

OLD:
A non-media handling proxy is expected to ignore and simply forward
   all unknown transport specifications, however, this can only be
   guaranteed for proxies following the RTSP 2.0 specification
   [I-D.ietf-mmusic-rfc2326bis].


NEW:
A non-media handling proxy is expected to ignore and simply forward
all unknown transport specifications. However, this can only be
guaranteed for proxies following the RTSP 2.0 specification
[I-D.ietf-mmusic-rfc2326bis].


s/if you want to provide other fallbacks/if it is desirable to provide
other fallbacks/

s/For non-supporting non-media handling proxies the result will also
result in aborting the setup, however,/For non-ICE supporting non-media
handling proxies the result will be aborting the setup. However,/

s/the proxy chain support/the proxy chain supports/

s/to try perform an SETUP/to try to perform a SETUP/

Sec 9:
OLD:
However, for RTSP clients lacking a relay server,
   like a TURN server, or where usage of such a server has significant
   cost associated with it the usage of a STUN derived server reflexive
   address

NEW:
However, for RTSP clients lacking a relay server,
such as a TURN server, or where usage of such a server has significant
cost associated with it, the usage of a STUN-derived server reflexive
address

s/the selected protocol, e.g. UDP needs/the selected protocol, e.g. UDP,
needs/

s/Secondly the selected/Secondly, the selected/

Sec 10.1:
s/This document request that/This document requests that/

s/ICE based/ICE-based/

Sec. 10.2:
s/Transport Protocol Specifications/Transport Protocol Identifiers/

Sec 12:
s/Bill Atwood have provided/Bill Atwood has provided/