[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/
- [MMUSIC] AD evaluation: draft-ietf-mmusic-rtsp-na… Alissa Cooper
- Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rts… Magnus Westerlund
- Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rts… Alissa Cooper
- Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rts… Magnus Westerlund
- Re: [MMUSIC] AD evaluation: draft-ietf-mmusic-rts… Alissa Cooper