[Gen-art] Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

[Elwyn Davies <[e-mail]>]

I am an additional Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at

<http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.

Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-mmusic-rfc2326bis
Reviewer: Elwyn Davies
Review Date: 5 June 2013
IETF LC End Date: 5 JUne 2013
IESG Telechat date: (if known) -

Summary:
Almost ready.  Generally this is an excellent and well written document,
particularly given its size.  There are a few minor issues to sort out
mainly at the nit level and some consistency issues to fix up.  The two
issues that I have brought out below are really at what the IESG would
call 'DISCUSS-DISCUSS' level.  The issue of URI scheme redefinition may
well have already been cleared by the URI expert - the draft does not do
itself any favours here by failing to explain what the syntax changes
are in s4.2; this raises immediate red flags that only start to fade a
couple of hundred pages later. The rudimentary nature of the pipeline
mechanism is carried over from RTSP 1.0.  I'd like to be sure that this
has been properly discussed in the WG as it looks pretty flaky to an
outsider.  There are several inconsistencies between various lists of
headers that need sorting out and there is no definition of
Proxy-Authorization in the ABNF.

There are also a fairly large number of editorial nits but these are all
localized and trivial to fix.  Finally I have't had time to review the
appendices (maybe there will be a follow up).

Robert Sparks is the main gen-art reviewer for the document; he asked
for additional eyes on the document given the size and his RAI
background.  Having (just) seen his review, I think we have both picked
up on the URI scheme and pipeline issues.  I am not sure that I concur
with his view that there is significant normative material in the
appendices - AFAICS the main protocol definition *is* in the main body
of the document and the bits especiially in Appendices B and C are not
the core of the protocol.  However this is based on a very cursory
glance through something like 75 pages of the document.  However, I do
concur with Robert's view that it needs a security expert to check the
security stories.

Major(ish) issues:
s4.2: This section (re-)defines the URI schemes "rtsp" and "rtsps". The 
last sentence of para 1 states that the 'details of the syntax' of the 
URIs 'have been changed'.  Is this a reasonable thing to do? Has this 
been cleared with the URI expert reviewer?  I am not entirely clear what 
the change involves and the draft doesn't explain exactly how the syntax 
has been altered  and its consequences (if any) in s4.2.  Some details
are finally given in s22.14.


Minor issues:
s11, para 3: I guess that the WG decided that sticking with the RTSP 1.0
model of sending requests and worrying about success of prior prior
pipelined requests was the right answer.  I would have thought that it
might have been helpful to provide qualifiers on the Pipelined-Requests
header that allowed subsequent requests to be suppressed unless the
previous command resulted in one of a given set of status codes with a
'reset' option to 'restart' the pipeline.  It strikes me that this would
avoid some irritating need to work out how to recover from arbitrary
failures in a command chain in a client.

Nits/editorial comments:

General: s/i.e./i.e.,/; s/e.g./e.g.,/

General:  Consistent usage of octet vs. byte (octet preferred).

General: Consistent use of '(session) keep alive' vs. '(session) keep-alive'

General: Consistent use of Base64 vs BASE64.

s1, para 2, last sentence: s/delivered as a time-synchronized 
streams/delivered as time-synchronized streams/

s1. last para: s/used terms/terms used/

s1, last para: Need to expand SDP acronym.

s2, para 1: s/considered use cases/use cases considered/

s2.1, para 1: s/completely out of bands/completely out of band/

s2.1, next to last para: It would be useful to  provide a pointer to 
where the  two URI schemes are defined (s4.2?) so it is clear these are 
internally defined and one needn't go looking for another doc.

s2.2, para 5: s/uses client-selected identifier/uses a client-selected 
identifier/

s2.2, para 5: For  consistency there should be a reference for s18.32 
with Pipelined-Requests.

s2.2, last para: For  consistency there should be a reference for s18.29 
with Media-Range.

s2.3, para 1: Expand SMPTE acronym.

s2.3, para 3: Reference s13.5 for PLAY_NOTIFY

s2.3, para 5:
> The server should also regularly send every 5
>     minutes the current media range in a PLAY_NOTIFY request.
Shouldn't this be configurable?

s2.3, last para:
> If the client waits too long
>     before resuming the pause point, the content may no longer be
>     available.  In this case the pause point will be adjusted to the end
>     of the available media.
I know this is a subjective choice, but I would have thought adjusting 
to the beginning of the available media would be what the user expects.
Later: Having read s13.4.1, I think this conflicts with (or is unclear) 
compared with s13.4.1, para 2 which states that the pause point will be
the oldest retained time - that is what I would have expected.

s2.4, para 1: For  consistency there should be a references for 
s22.11/s22.9 with RTP-Info and Range.

s2.4, para 2: s/that can be used/can be used/

s2.5.1, paras 2/3:  Should have references to ss18.48/18.44 for Scale/Speed.

s2.5.1, para 6:
OLD:
These media manipulation and when they are needed are highly media-type 
dependent.
NEW:
The nature of these media manipulations and when they are needed is 
highly media-type dependent.
--or--
The nature of this media manipulation and when it is needed is highly 
media-type dependent.

s2.5.1, para 9: s/and the currently used scale factor
    exist./and the scale factor currently in use, exists./
OLD:
    a mechanism for
    updating the media properties and the currently used scale factor
    exist.
NEW:
    a mechanism exists for
    updating the media properties and the scale factor currently in use.

s2.6, bullet 1: Need to expand RTCP acronym (RTP is 'well-known' but not 
so RTCP apparently).

s2.6, para 5: Reference s13.7 for TEARDOWN.

s2.6, para 7: s/10*times/ten times/

s2.6, last para: Reference s13.10 for REDIRECT

s2.6, last para: Reference s22.10 for Terminate-Reason

s2.7, para 2: Reference s18.41 for Require

s2.7, para 2: The reference for s18.35 for Proxy-Require should be moved 
from bullet 2.

s2.7, para 3: s/in order of the magnitude/in increasing order of the 
magnitude/

s2.7, bullet 3: s/standard/standards/

s3.1, para 3:  Clearly there won't be any smaller type paras in the 
ASCII version.. is there a PDF version that actually has smaller type?  
The one I get from the repository doesn't seem to have any smaller type 
paras.

s4.2, para 2, last sentence:
OLD:
This way RTSP 2.0 URIs for request
    can be produced from an RTSP IRI.
NEW:
This allows a URI that matches the RTSP 2.0 specification, and so is 
suitable for use in a request, to be created from an RTSP IRI.

s4.4: An external reference to the relevant Society of Motion Picture 
and Television Engineers standard (probably SMPTE 12M) ought to be 
included to define things like "SMPTE 30 drop".  [Aside: 29.97 frames 
per second?? Must be something to do with Never Twice the Same Color.  
Oh, well,  a little research job for whan I am really bored.]

s4.5: The NTP reference is interesting but gratuitous.

s4.6:  It would be useful to add the "clock=19961108T143720.25Z-" form for 
consistency with s4.4 and s4.5 as well as the 'free-standing' absolute
time which is used in Media-Properties etc.

s4.8, para 1: A more precise reference for HTTP ETag would be helpful.

s4.9, para 1: s/the below listed media properties/the media properties 
listed below/

s4.9.1: There seems to be some confusion in this section between the
values from the Seek-Style header and the values from the
Media-Properties random access property.  The section says the values
are from Seek-Style but they are actually from the random access
property.  Presumably there was some intention to interelate the media
capabilities and the play event policies?  Further this section has
Random Access, Conditional Random Access, Return to Start and No
Seeking.  This doesn't match exactly with either Seek-Style (RAP, CoRAP,
First-Prior and Next) or Media-Properties (Random-Access, Beginning-Only
and No-Seeking).

s4.9.2, "Time Limited": s/before given wallclock time/before the given 
wallclock time/

s4.9.3, para 1: s/during time/over time/

s4.9.x: It would be desirable to use the parameter names in the same 
form as they appear in s18 (e.g., Random-Access instead of Random 
Access, No-Seeking instead of No seeking) both in the definitions 
(s4.9.1 - s4.9.4) and the mapping (s4.9.5).


ss4.4/4.5/4.6: If I read the ABNF in s20.2.1 correctly, the unqualified 
values "smpte", "npt" and "clock" are valid  in the Range parameter.  
What is the meaning of such an unqualified value?

s5:  It would be sensible to note that the ABNF fragments in s5 and the 
following sections match with the full syntax productions in s20.

Table 3:  Proxy-Authorization (Section 18.34) doesn't appear in any of 
the various header categorization tables [I must have better things to 
do than checking they were all there :-( ].  I think it belongs here.

s5.3: For consistency with s9.2, this section should also say that a 
message with a body MUST contain a Content-Type header also.

s5.3, para 1:
> An example of a message body is the Session Description
>     Protocol (SDP).
Er, perhaps not the *whole* protocol?  Maybe an SDP message??

s7.2, para 1 and Table 3:  Perhaps the headers that can also be in 
Response messages could be marked?  I believe these are Range, Scale, 
Session, Supported and Transport.

s8.1.1: Should clarify that a separate registry is being defined so the
story about importing HTTP codes doesn't have any impact on the HTTP
registry.  I initially read this as if it did.

s8.1.1, para 5:  Is there some deep reason for labelling this 3rr rather 
than 3xx? (and throughout the document).  Sort of understandable but a 
bit odd.

s8.1.1, code 505:  HTTP code 505 is explicitly '*HTTP* version not 
supported' - should there really be a separate code for 'RTSP version 
not supported'?

s8.1.1, code 551: s/Support/Supported/

Table 5: Alphabetic sort on Server and Session is incorrect.

s8.2, last para: s/recognize them to be response-header/recognize them 
to be a response-header/

s9, para 1:  Should the cross-reference be to s5.3 (message body) rather 
than 5.2?

s9: Is it deliberately left vague as to whether other message types 
might have message bodies?

s10.2, para 6 and following note:  I can't see that the note following 
para 6 can be justified: since the restriction on multiple connections 
from a client to a server is only a SHOULD, an interoperable server MUST 
be capable of handling multiple connections from a client unless the 
server can explicitly send back a TOO MANY CONNECTIONS status.

s10.2, para 10: s/due to the response is caught in the queue behind a 
number of request that/due to the response being caught in the queue 
behind a number of requests that/

s10.3, para 4, "on the flip side":  Slang.  Maybe "Contrariwise" or 
something less archaic.

s10.4, para 4: Expand RTT acronym (its apparently not well-known).

s10.5, para 1: s/ To show liveness between RTSP request issued/ To show 
liveness between RTSP requests being issued/

s10.5, RTCP para: s/it MUST also work as keep alive/it will necessarily 
also function as a keep alive/; s/statistical guarantees to reach the 
server/statistical guarantees of reaching the server/

s10.5, RTCP para:
OLD:
         That client has, for a network with 5
         % packet loss, the probability to fail showing liveness sign in
         that session within the timeout interval of 2.4*E-16.  Sessions
         with shorter timeouts, or much higher packet loss, or small
         RTCP bandwidths SHOULD also use any of the mechanisms below.
NEW:
         That client has, for a network with 5% 
         packet loss, a probability of failing to confirm liveness 
         within the timeout interval for that session  of 2.4*E-16.  
         Sessions with shorter timeouts, or much higher packet loss, 
         or small RTCP bandwidths SHOULD also implement one or more 
         of the mechanisms below.

s10.5, RTCP para: expand SSRC acronym.

s10.5, SET PARAMETER para: s/keep-alive/keep alive/

s10.5, last para: Should clarify that the 'timeout parameter' is a 
qualifier on the Session parameter - 'timeout parameter' appeared to 
indicate that it was a separate protocol parameter and sent me searching.

s10.6: RFC 3986 has capability for dealing with IP versions beyond 6... 
should these be carried over into RTSP?  The IANA registry says they are.

s10.7, para 3: s/and in dependency of its current load situation/and 
bearing in mind its current load situation/; s/to  increase the length 
proportional with the load of the server/to increase the timeout period 
in proportion to the current load on the server/

s10.7, para 3: Anti-synchronization measures such as are RECOMMENDED 
here are usually MANDATORY. (Also applies to wait timer in last para of 
this section).

s10.7, para 4: s/Another issue are load balancing RTSP proxies/A more 
complex case may arise when a load balancing RTSP proxy is in use/

s10.7, last para: Should the doubling of the wait timer have an upper limit?

s11, para 4: s/Feature-Tag/Feature-tag/

s11, para 4: According to s22.1.3, play.basic, play.scale and play.speed
are 'defined' in this draft.  The nearest thing to a definition of
play.basic that I can find is the last sentence of para 4 in this
section.  I am not convinced that I could produce an interoperable
implementation of a server with this feature-tag with the one sentence
'definition'.  References to where play.xxx are defined would be useful
(play.scale in s18.44, play.speed in s18.48).

s11, Supported (and Proxy-Supported) bullets: 
OLD:
         This results in the
         receiver is learning the requester's feature support.
NEW:
         This results in the
         receiver learning the requester's feature support 
         relevant to the specified resource.
[Note: I added 'specified resource' here and then thought about whether
this made any sense.  It probably needs to be clearer what set of
features are included in the Supported list for both requester and
responder.  Are they restricted to those relevant to the specified
resource that might of course be the whole server, proxy - or client?? -
in which case there isn't an issue, but it might be a specific
presentation - what happens then?  Affects s13.1, para 3 also.]

s11, Proxy-Supported bullet: To emphasise the 'intersection of features'
mechanism used for Proxy-Supported (s18.36), it might be good to 
s/a view of what functionality the proxy chain/a view of the common
functionality supported by all members of the proxy chain/

s12, para 2: Might be better with:
s/allow all requests to setup and initiate media delivery/allow all
requests involved in setting up and initiating media delivery/

s12, para 2, last sentence: s/with at least one RTT/by at least one RTT/

Table 7: The 'Server req' and 'Client req' columns are not described.

s13.1, para 1: s/a client request it to a server/a client can send the
request to a server/

s13.1, para 1:
OLD:
   The client, server or proxy MAY also
   implement the converse of their required capability, but still retain
   the prior mentioned about what is a "MUST implement".
NEW:
   In addition to this "MUST implement" functionality, clients, servers 
   and proxies MAY provide support both for sending OPTIONS requests and 
   generating responses to the requests. 

s13.1, para 3: s/Regardless of scope of the request/Regardless of the
scope of the request/

s13.1, para 4: s/ID/identity/

s13.1, last para: s/fictional/fictitious/

s13.2, example S->C: Is Mark Handley cool with using his name? Might be
better to use the traditional 'another' (A.N.Other).

s13.3, para 1:  It would be helpful to copy the list of (3) states from
Appendix B somewhere around here and mention that the protocol drives a
state machine.

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!

s13.4.1, page 72:
OLD:
   i.e.
   being handled the same as the request was received in Ready state.
   In the case the range in Range header has an implicit start time
   (-endtime),
NEW:
   i.e.
   being handled in the same way as if as the request was received in Ready state.
   In the case that the range in Range header has an implicit start time
   ("-endtime"),

s13.4.3, para 2: s/will take action/will take effect/

s13.4.3, page 76: s/entering or leaving from fast forward or fast
rewind./entering or leaving fast forward or fast rewind mode./

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).

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?

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.

s13.5.3, first sentence: 'change the rate' of what? media delivery
presumably.

s13.5.3, para 2: s/adjust the used Scale value/adjust the Scale value
used/

s13.5.3, para 2: s/where the change took effect/when the change took
effect/; s/ID/identity/

s13.6, para after 1st example:s/ resume from the pause/resumes from the
pause/

s13.7.1, para 3:
OLD:
   This may result in
   that a session returns to non-aggregated control, due to that it only
   contains a single media after the requests completion.
NEW:
   This may result in
   a session returning to non-aggregated control, because it only
   contains a single media after the request's completion.

s13.8, para after bullets: s/request parameters/requests parameters/; 
s/Due to this reason/For this reason/

s13.9, para 2: s/In the case a parameter/When a parameter/

s13.10, 3rd para after numbered bullets, page 93: s/"time" parameter are
included/"time" parameter is included/

s13.10, page 94, para next but 1 before example:
OLD:
   However, the
   usage of conditional SETUP using MTag identifiers are RECOMMENDED to
   verify the assumption.
NEW:
   However, the
   usage of conditional SETUP using MTag identifiers is RECOMMENDED as
   a means to verify the assumption.

s14, para 2: s/integer/unsigned integer/ (I assume)

s14: What happens if the upper layer PDU is longer than (2^16 - 1)?

s14, figure: Binary header should have a figure number and title.

s14, figure: 'Length number of bytes of binary data' is confusing.
Maybe 'Binary data (length as in Length field)'

s17.3:  Uses 3xx in the title and 3rr in the body. See previous comment
about 3rr.

s17.4.32: s/next hops/next hop's/ (I think).

s17.5.6: See previous comment about overloading the 505 error code.

s18, Table 8 caption: 
OLD:
Note: It is allowed for all error messages 4xx and 5xx to
                                have a body
NEW:
Note: All error messages for statuses 4xx and 5xx are allowed to
                                carry a body.

s18, para after Table 8: s/[HX.Y] to informational refer to Section
X.Y/[HX.Y] to reference Section X.Y/

s18.2, para 2: s/This as/This is because/

s18.2, para 2: Expand DER avronym.

s18.2, para 3: s/replacement algorithm exist./replacement algorithm
exists./

s18.5, para 1: s/formats it support to receive/formats are acceptable
when received/

s18.6 para 1: s/to strictly inform the recipient of valid methods/to
inform the receipient of the complete set of valid methods/

s18.6, para 2: s/Allow/Allow message-header/; s/is different than/is
different from/

s18.8, para 2: s/due to that/because the/; s/what is reasonable/what is
a reasonable/

s18.10, para 3: s/govern only/govern just/; s/Below is the
description/Below are the descriptions/

s18.10: The various descriptions talk about 'media stream'.  Presumably
this should include media streams and RTSP responses.

s18.10, no-cache para: 
OLD:
Note, there is no security function enforcing that the content can't be
cached.
NEW:
Note, there is no security function preventing the caching of content.

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?
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]

s18.11, para 5: s/therefore see/therefore sees/

s18.12, para 1: s/of any next hop that need to be approved/for any next
hop that needs to be approved

s18.12: Figure needs a number and a caption.

s18.14: Consider adding the 'identity' value explicitly to the ABNF.

s18.17, para 6: s/relative URI/relative URI(s)/

s18.10, last para: Should have a reference to RFC 1123 for the date format.

s18.28, para 1: s/properties take effect/properties taking effect/

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. 

s18.32, para 3: s/or request of any type/or requests of any type/

s18.32, para 4: s/to a session context exist/to a session context
exists/

s18.39, para 2: Strictly 'fragment' should be 'fragment identifier'.

s18.40, para 1: s/that takes time/that take time/; s/such a/such as/

s18.41, para 1: s/the Supported/the Supported message-header/

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.

s18.43, para 2: s/result in that a client needs/result in a client
needing/; s/Also functionality as informing/Also functionality that
informs/

s18.43, para 3: s/also the Range header MUST be included/the Range
header MUST also be included/

s18.43, para 9: It might be wise to explicitly expand the NTP acronym
even though it is well-known - its a long distance since the doc told us
not to confuse NPT and NTP.

s18.45, para 4: Harummph! Political Correctness strikes again.  Every
protocol should (and probably does) have a CRAP policy. ;-)

s18.50, Session-Timeout para: s/is kept alive/has been kept alive/

s18.50, time para: s/will stop provide/will stop providing/ 

s18.52, 1st 'No dest_addr' para: s/send media to same address for
which/send media to the same address from which/

s18.52, 2nd dest_addr para: Expand DoS acronym. 

s18.52, 'unicast/multicast' para: s/transmission needs/transmission
need/

s18.52, bottom of page 168:
OLD:
         The host address part of the tuple MAY be empty, for example
         ":58044", in cases when only destination port is desired to be
         specified. 
NEW:
         The host address part of the tuple MAY be empty, for example
         ":58044", in cases when it is desired to specify only the
         destination port. 

s18.52, 2nd para of src_addr section on page 169:
      s/media streams data packets/media stream's data packets/ (I think
there is only one implied - could be "data streams'" if many). 

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? b) should they say
["active:"] or ["active":] - both formats are used?  The ABNF has the
plain words with no brackets or quotes.

18.52, 'connection' section, 1st line:
s/Clients use the setup parameter/Clients use the connection parameter/
(I assume).

s19.2, para 1: s/both on URI level and port level/both on the URI level
and the port level/

s19.3, para 2: s/the client and server also needs to be aware/the client
and server also need to be aware/

s19.3.1, 'Any' para: s/accept whatever certificate presented/accept
whatever certificate is presented/

s19.3.1, 'Proxy' para: s/;/:/

s20: Proxy-Authorization seems to be missing from the ABNF altogether.

s20.2.1, 'smpte-range' production:  The reference should be to Section
4.4 I think - there is no Section 3.4 and s4.4 talks about SMPTE.

The next four comments are inconsistencies that need sorting out:

s20.2.2: Accept-Ranges and RTP-Info are classified as general headers in
Table 1 but appears in response-header here.

s20.2.2: User-Agent is classified as a request header in Table 3 but
appears in general-header here.

s20.2.2: Server is classified as a response header in Table 5 but
appears in general-header here.

s20.2.2: Accept-Credentials is classified as a request header in Table 3
but appears in response-header here.

s20.2.2, response-header production: Alphabetic sort fails at
MTag/Location. :-(

s21, para 2: s/appendix/an appendix/; s/the media security/media
security/

s21.1, Abuse of Server Logs:  [H15.1.1] doesn't really give much advice
beyond what is said here already.  One could copy the one sentence of
'mind out for the lawyers' advice here and save the indirection.

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...)

s21.1, Attacks based on file names etc: The reference should be to
[H15.2].

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?

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.

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?

s21.1, last para: s/will be present by following the specification as
written,/will be instantiated if the specification is implemented as
written,/; s/prevent session hijacking/minimize the risk of session
hijacking/; s/strongly improved/greatly improved/

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). 

s21.2, para 1: s/like RTP/such as RTP,/; s/that exist/exist/

s21.2, Media Confidentiality: s/Thus also the signaling protocol
must/Thus the signaling protocol must also/

s21.2, Media Integity amd Auth: s/will have interest to substitute/will
be interested in substituting/

s21.2, Scope of Multicast: s/it is needed to consider the scope that
delivery has./the scope of the delivery must be considered./

s21.2.1, para 1: s/ascertaining the attackers/ascertaining the
attacker's/

s21.2.1, para 1: 
> Security mechanisms
>    that are acceptable in an increased generality are:
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^ 
Does this mean 'in order of increasing generality'?

s21.2.1, 2nd bullet: s/that accept to be/that have consented to be/

s21.2.1, last para on p204: Expand ICE acronym. (NAT is well-known).
 
s21.2.1, first para on p205: s/username/a username/; Expand STUN acronym

s21.2.2, RTP/RTCP Extensions: s/and disrupt video/and disruption of
video/

s21.2.2, next to last para:
OLD:
it is clear that strong
   security mechanism to protect RTP is necessary to support. 
NEW:
it is clear that it is necessary that a strong security mechanism is
supported to protect RTP.

s21.2.2, last para: s/beyond the mandatory to implement/beyond those
mandatory to implement/

s22: Ought to have the standard note about replacing RFCXXXX with the
number of the document when approved...

s22, para 2: s/follow the below defined procedure/follow the procedure
defined below/

s22, para 3: s/some of the requirements level/some of the registration
policies/

s22.1.3: References back to the sections which define the play.xx
feature tags should be added.  As previously stated, I am not entirely
sure what the required features are to meet the play.basic requirements.
 
s22.2.1: s/Methods are described in Section Section/RTSP Methods are
described in Section/

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?   

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?