Re: [MMUSIC] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 23 August 2013 08:51 UTC
Return-Path: <magnus.westerlund@ericsson.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 6BF7E11E82E5; Fri, 23 Aug 2013 01:51:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.351
X-Spam-Level:
X-Spam-Status: No, score=-105.351 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TalCClRElYpF; Fri, 23 Aug 2013 01:51:29 -0700 (PDT)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id F099711E82D2; Fri, 23 Aug 2013 01:51:25 -0700 (PDT)
X-AuditID: c1b4fb2d-b7f738e000003ee3-e8-5217228cc16d
Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 4A.0D.16099.C8227125; Fri, 23 Aug 2013 10:51:24 +0200 (CEST)
Received: from [127.0.0.1] (153.88.183.148) by smtp.internal.ericsson.com (153.88.183.38) with Microsoft SMTP Server id 14.2.328.9; Fri, 23 Aug 2013 10:51:22 +0200
Message-ID: <521722BF.8010207@ericsson.com>
Date: Fri, 23 Aug 2013 10:52:15 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Elwyn Davies <elwynd@folly.org.uk>
References: <1370477514.4596.9052.camel@mightyatom>
In-Reply-To: <1370477514.4596.9052.camel@mightyatom>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprPLMWRmVeSWpSXmKPExsUyM+JvjW6PkniQwY9ZlhYXvxxhtzh+YAe7 xdVXn1kspi5/zOLA4vH1ZDuLx5IlP5k8vlz+zBbAHMVlk5Kak1mWWqRvl8CVsftJRcH7woqz u18yNjA+jOpi5OCQEDCROLkltIuRE8gUk7hwbz1bFyMXh5DAYUaJz/OnsUA4yxklrr3sYAap 4hXQluiYMYMJxGYRUJU4P7WfEcRmE7CQuPmjkQ3EFhUIlmjf/pUNol5Q4uTMJywgtoiAmsTm rw8YQYYyC3QzSsx+dgFskLCAj8SWCavBioQEjCUef33PCmJzAl13t7WLFeI8SYlti46xg9jM AnoSU662MELY8hLNW2czQ/RqSzQ0dbBOYBSahWT3LCQts5C0LGBkXsXInpuYmZNebriJERjI B7f81t3BeOqcyCFGaQ4WJXHeTXpnAoUE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwGgpGdNe/ /furfYvdjhuOUWJTU41vam0yVlA2ONNVxCy1goVv0Ue3/tTAD/6f1n6sPLP/lXfHvf2T/zo3 ykZPTK6a+EBAYe1E7tWft/3jmhbInHTFb+1OK5uOT0szFF1+CIrG8s5LFVPc7GWh1irIU/7p RHr0NZaqHs9Cx/6pMTf3lW99ecpCiaU4I9FQi7moOBEAD+ZUZTICAAA=
Cc: General Area Review Team <gen-art@ietf.org>, draft-ietf-mmusic-rfc2326bis.all@tools.ietf.org, "mmusic (E-mail)" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 23 Aug 2013 08:51:35 -0000
Hi, Continuing with the issues after Section 11. Once more a big thanks for the work you have put into this. It is really helpful, both from clarity point of view and finding some actual protocol issues. On 2013-06-06 02:11, Elwyn Davies wrote: > > s13.4.1, para 2: >> Upon receipt of the PLAY request, the server MUST position the normal >> play time to the beginning of the range specified in the received >> Range header > > Should this mention the caveat that (if I understood earlier statements > correctly) the server may not be able to deliver exactly on this MUST > and then sets it the nearest it can manage? This is borne out by the > example later in this section where the server sets the start point back > 10ms (and says so), etc. Seek-Style affects the interpreation of MUST! Yes, I have added that this needs to happen ".. within the limits of the media resource and in accordance with the Seek-Style header (Section X.Y) ..". > > s13.4.4/.5/.7/.8: In these sections the Media-Property random access > property is stated as being required to be Random-Access. Is > Conditional Random Access a possible value for this property? The > confusion in s4.9.1 does not allow me to conclude that this shouldn't be > a value for the property (sorry for the double negative but this looks a > bit confused). These section lists the Media-Properties for the media resource one request delivery for. Thus from a PLAY request perspective using a Seek-Style: CoRAP header is fine for the ones that has Random Access property as Random-Access in these section. > > s13.5.1: Apologies if this question is stupid - I am not a media stream > wxpert. Suppose we have an aggregated stream with (say) a number of > recorded media items making up the aggregate. The client sets it on to > play to the end. What happens if not all the streams end at the same > time? Do we get PLAY_NOTIFY End-of-Stream notifications for each > individual stream as it ends or just one when the complete aggregate > ends? Not at all a stupid question. This should have been clearly specified for all usages of PLAY_NOTIFY in regards to aggregated sessions. Thus I have added both a general requirement on PLAY_NOTIFY level: PLAY_NOTIFY requests MAY use both aggregate control URI and individual media resource URIs depending on scope of the notification. This scope may have important distinctions for aggregated sessions, and each reason for a PLAY_NOTIFY request needs to specify the interpretation and if aggregated control URIs or individual URIs may be used in requests. And specified the following for end-of-stream: For RTSP Session where media resources under aggregated control the media resources will normally end at approximately the same time, although some small differences may exist, on the scale of a few hundred of milliseconds. In those cases a RTSP session under aggregated control SHOULD send only a single PLAY_NOTIFY request. By using the aggregate control URI in the PLAY_NOTIFY request the RTSP server indicates that this applies to all media resources within the session. In cases RTP is used for media delivery corresponding RTP-Info needs to be included for all media resources. In cases where one or more media resource has significantly shorter duration than some other resources in the aggregated session the server MAY send end-of-stream notifications using individual media resource URIs to indicate to agents that there will be no more media for this particular media resource related to the current active PLAY request. In such cases when the remaining media resources comes to end-of-stream they MUST send a PLAY_NOTIFY request using the aggregate control URI to indicate that no more resources remains. And the following for Media-Properties-Update The Media-Properties header has session scope, thus for aggregated sessions the PLAY_NOTIFY request MUST be using the aggregated control URI. And for Scale-Change PLAY_NOTIFY requests for aggregated sessions MUST use the aggregated control URI in the request. The scale change for any aggregated session do apply to all media streams part of the aggregate. > > s13.5.2, para 2: >> that changes the basis for making >> estimates on how the media range progress. > I can't parse the last part of this and I am not sure what it should be. I hope this is better This notification MUST be sent for media that are Time-Progressing every time an event happens that changes the basis for making estimates on how the available for play-back media range will progress with wall clock time. > > s14: What happens if the upper layer PDU is longer than (2^16 - 1)? I have added this note: Note that this mechanism does not support larger PDUs than 65535 bytes, which is the same that regular IPv4 and IPv6 is capable. If the media delivery protocol intended to be used has larger PDUs than that, the definition of such mechanisms usage of this mechanism will require the definition of a PDU fragmentation mechanism. > > s18.10, private para: Is there any way in RTSP for the cache to know > whether this is a private cache for the user that should cache this > content? To my understanding this is something the cache itself knows through its behavior and deployment. > s18.10, last para: I am not absolutely certain, but I think this para > is specific to the max-age cache type rather than being generic as > implied by the indentation. [If so use the <vspace blankLines=1/> trick > to provide a pseudo-paragraph break] Yes, you are correct. I did the equally easy choice for hanging lists to simply make a new paragraph without any paragraph text. > s18.14: Consider adding the 'identity' value explicitly to the ABNF. If I understand you correctly what you are requesting is that "identity" is listed as an construct in the content-coding ABNF construction that are used by Accept-Encoding and Content-Encoding headers. Accept-Encoding = "Accept-Encoding" HCOLON [ encoding *(COMMA encoding) ] encoding = codings [SEMI accept-params] codings = content-coding / "*" content-coding = "identity" / token Content-Encoding = "Content-Encoding" HCOLON content-coding *(COMMA content-coding) > > s18.29, para 2: Are (or should there be) constraints on the ordering of > media ranges for a non-continuous media stream? It would probably make > the client's job easier if they were in incresing order. This is a interesting question. If one simply expresses what pieces of media that are currently available then using a requirement that the first ranges end-time must be prior any of the subsequent ranges start times would work. However, my head gets stuck on considering when desired playback is non linear. But that is probably a higher function question. So a possible addition after this existing sentence: The server MAY include more than one range specification of any given time format to indicate media that has non-continuous range. would be: The range specifications shall be ordered with the range with the lowest value or earliest start time first, followed by ranges with increasingly higher values or later start time. Comments on this? > s18.41: It appears from a literal interpretation (the third sentence is > an unqualified MUST) that the responder has to respond with error code > 551 and an (empty?) list of Unsupported features if it actually does > support all the features. I suspect this is not what is wanted. Correct, reformulated proposal is: In case any of the feature-tags listed by the Require header are not supported by the server or client receiving the request, it MUST respond to the request using the error code 551 (Option Not Supported) and include the Unsupported header listing those feature-tags which are NOT supported. > s18.45, para 4: Harummph! Political Correctness strikes again. Every > protocol should (and probably does) have a CRAP policy. ;-) Yes, the lower case o is silent here ;-). > > s18.52, 'setup' section: There seems to be some inconsistency in the > spcification of the 'active/passive/actpass' values. a) Is there some > reason for specifying them in square brackets? Not, that I can remember. Removing both brackets and quotes. b) should they say > ["active:"] or ["active":] - both formats are used? The ABNF has the > plain words with no brackets or quotes. The later would be correct, but now it will only say active: <description> The ABNF is clear that it will be RTP/SAVPF/TCP;unicast;setup=active;connection=new > > 18.52, 'connection' section, 1st line: > s/Clients use the setup parameter/Clients use the connection parameter/ > (I assume). Had to tweak that sentence a bit more: Clients use the connection parameter in a transport specification part of the Transport header in a SETUP request, to indicate the client's preference for either reusing an existing connection between client and server (in which case the client sets the "connection" parameter to "existing"), or requesting the creation of a new connection between client and server (in which cast the client sets the "connection" parameter to "new"). > > s21.1, transfer of sensitive info: Is there an equivalent of the Referer > header in RTSP? Not sure there is but it would be good to explain one > way or the other (either there isn't one so it's less of a problem or > this is the equivalent...) Yes, the Referer header is retained also in RTSP. > > s21.1, DNS Spoofing: Presumably RTSP will interact significantly with > content delivery networks. Some of these work by DNS 'spoofing' that > was in its infancy when RFC 2616 was published. Are there any other > issues that come out of the greater prevalence of CDNs since 1999? I have no experience with large scale deployment of RTSP. To my knowledge there hasn't been the same development with CDNs for RTSP as HTTP. This I think is dependent on several factors. One has been the issues with deploying RTSP on global scale due to NAT traversal etc, instead progressive download and HTTP adaptive streaming has mostly taken this market. Thus most large scale deployments has been in contexts within single operators providing Video On Demand services etc. Thus, I don't really know of any additional issues around this. > > s21.1, Session Hijacking: The last part of this is written so that it > appears to mandate authentication in all cases. As far as I understand > it is up to the client to decide if it needs authentication etc and some > content will be offered on unsecured URIs. I think this needs to be > clearer that authentication will mitigate the problem but whether it is > done is up to the client if the server doesn't care. Is this better? Another choice for preventing session hijacking is to use client authentication and only allow the authenticated client creating the session to access that session. > > s21.1, Persistently suspicious behaviour: There seems to be a mismatch > between the title (persistently..) and the first sentence (a single > instance). Do we have examples of the sort of security risk which is > supposed to be met with a 403 response the first time? Yes, it is a bit inconsistent. I propose: Suspicious behavior: RTSP servers upon detecting intances of behavior which is deemed a security risk SHOULD return error code 403 (Forbidden). RTSP servers SHOULD also be aware of attempts to probe the server for weaknesses and entry points and MAY arbitrarily disconnect and ignore further requests from clients which are deemed to be in violation of local security policy. > > s21.1, last sentence: >> Some of the above threats are such that >> the implementation of the RTSP functionality itself needs to consider >> which policy and strategy it uses to mitigate them. > It strikes me that this is not very helpful to a prospective > implementer. The point of this section is at least in part to provide > that policy and strategy. I am not quite sure how to rewrite this (or > if indeed other people think it does need rewriting). No, it is not helpful in other ways then, you need to think about this and consider what mitigations you think should be implemented and how that affects your implementation design. For now I am leaving this as it is. > s22.3: The rules about allocating in the sections above x50 should be > explained here (see s8.1.1). The numbers below x50 in each section > should be marked as a special category of reserved so they are only > allocated to HTTP analogues. Is an experimental/private segment in each > category desirable? Yes I think adding something like the below to at least make clear the intention that RTSP specific status codes should first be registered in the x50-x99 range. New RTSP functionality requiring Status Codes should first be registered in the range x50-x99. Only when the range is full should registrations be done in the x00-x49 range, unless it is to adopt an HTTP extension also to RTSP. The reason is to enable any HTTP extension to be adopted to RTSP without needing to renumber any related status codes. Regarding experimental and private I am very torn about such range. Unless someone else in the WG thinks this is worth the work I will leave it out. > > s22.9: Being allowed to register new Range header formats will currently > be restricted to times specified by NPT, SMPTE or UTC because no > registry is defined for Accept-Ranges. Is this what is intended? No, the intention is that Range header format registry is shared between Range and Accept-Ranges. However, I see the description is not clear on this and needs to be amended. I have sent a separate email on this. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- Re: [MMUSIC] Gen-art additional LC review of draf… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Elwyn Davies
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Elwyn Davies
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Magnus Westerlund
- Re: [MMUSIC] Gen-art additional LC review of draf… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Elwyn Davies
- Re: [MMUSIC] Gen-art additional LC review of draf… Magnus Westerlund
- Re: [MMUSIC] [Gen-art] Gen-art additional LC revi… Magnus Westerlund
- [MMUSIC] RTSP 2.0: Body format negotiation Magnus Westerlund