Real-Time Streaming Protocol Version 2.0
draft-ietf-mmusic-rfc2326bis-40

Looks to me like Barry may have reviewed some of the text. I looked and found nothing threatening to routing so I will ballot No Objection.  I did note the following...

In Section 18.21 you have some ambiguity in the instruction to the RFC
Editor. It reads...

      Note: The RTSP 2.0 date format is defined to be the RFC 5322 full
      date format.  This format is more flexible than the RFC 1123 date
      format used by RTSP 1.0.  Thus implementations should use single
      spaces as recommended by RFC 5322 as separators and support
      receiving the obsolete format.

      [[RFC Editor please remove this note: Prior to version 37 of the
      draft, rfc2326bis envisaged sticking with the RFC 1123 format.]]

I think you only want the Editor to remove the note in double square
brackets. But placed where it is, the editor will think they have to 
remove the whole Note, which I doubt is what you want.

UPDATE:
Version -39 addresses my DISCUSS points, and most of my COMMENTs -- THANKS!

I still don't see an RFC Editor note, so I'm leaving that comment.  Also, below I'm leaving my comments that I see have not been addressed.  Maybe that was intentional, but maybe, with all the comments, that was an oversight.  They're all non-blocking, but I do think they're changes that should be made.  I'll say no more about them, though.  (I've also added comments for sections 15 and 16, which I hadn't reviewed yet when I posted my other comments.)

I have not reviewed beyond Section 16, and I had hoped to do so.  That said, it's not fair for me to hold anything up for that, especially as I have a lot of other things going on.  That does sort of get into Pete's comment, that the document is too long to get thorough and complete review.  Waddyagonnado?

========================================================

First, a comment for the responsible AD:
The grammar, punctuation, and English usage in Section 2 and its subsections is
at times very hard to sort through.  I'm going to call out in the comments some
bits that I found particularly troublesome, and will try to suggest
alternatives.  I also suggest that the responsible AD put in an RFC Editor note
asking the editors to pay particular attention here and to give it some heavy
editing for language clarity.  This is a complex document, and a good overview
in clear English will really help.  Here's a suggestion for text for an RFC
Editor note:
------------------------------
RFC Editor note:
Section 2 of this document and its subsections provide "an informative overview
of the different mechanisms in the RTSP 2.0 protocol, to give the reader a high
level understanding".  As such, it's very important that it be clear and well
written.  Some reviewers have found the English to be difficult.  Please take
an especially critical pen to this section, making sure that the grammar and
usage are correct, and that the language is clear.
------------------------------

Comments that have not been addressed in -39:

-- Section 4.7.2 --

   The following different media retention policies
   are envisioned and taken into consideration where applicable:

What is that meant to be saying, really?  Please rephrase it (I have no idea
what "and taken into consideration where applicable" might mean).

   Time-Duration:  Each individual unit of the media will be retained
      for the specified duration.

What does "each individual unit of the media" mean?

-- Section 4.7.3 --

   Dynamic:  Between explicit updates the media content will not change,
      but the content may change due to external methods or triggers,
      such as playlists.

This sounds like doubletalk: it won't change, but it may change.  I think it
needs re-wording.

-- Section 4.7.5 --
It appears that you're mixing example headings (which contain colons) on the
same line as header fields (which contain colons), making the whole thing
unclear.  I suggest putting the example title on its own line, then starting
the example on a new line, like this:

   Example of "On-demand":
      Random Access: Random-Access=5.0, Content Modifications:
      Immutable, Retention: Unlimited or Time-Limited.

-- Section 5.1 --

   In the interest of robustness, agents MUST ignore any empty line(s)
   received where a Request-Line or Response-Line is expected.  In other
   words, if the agent is reading the protocol stream at the beginning
   of a message and receives a CRLF first, it MUST ignore the CRLF.

What's a "Response-Line"?  I also presume the last sentence above is applicable
recursively (you want to ignore any number of leading CRLF sequences), yes?
 Might be good to be clear about that.

-- Section 9.3 --

HTTP and email have both historically had horrendous problems with inaccurate
or missing Content-Type headers.  It's good that you use MUST for Content-Type;
that has to help.  I would be happier (though not at DISCUSS level) if you
should say a few more words about Content-Type here: something about how it
MUST accurately specify the type and subtype of the content, that there are no
defaults for type or subtype, and that attempts to use heuristics to
second-guess this are Very Bad.

-- Section 10.2 --

   The scheme of the RTSP URI (Section 4.2)
   indicates the default port that the server will listen on if the port
   is not explicitly given.

The URI is created by the client, not the server, so it doesn't specify what
port the server "will listen on."  It specifies the port the client will
contact the server on.  I would say it this way:

NEW
   The scheme of the RTSP URI (Section 4.2)
   allows the client to specify the port it will contact the server
   on, and defines the default port to use if one is not explicitly
   given.
END

   This port may
   provide some benefits from non-registered ports if a RTSP server is
   unable to use the default ports.

I think you mean "some benefits over non-registered ports".  "Over", not "from".

      authorize a client establishing a new connection as being a
      legitimate receiver of a request related to a particular RTSP
      session without the client first issuing requests related to the
      request.

There's a lot of "request" in there, and it's confusing.  Maybe this?:

NEW
      authorize a client establishing a new connection as being a
      legitimate receiver of a request related to an existing RTSP
      session, without the client first issuing new requests related
      to the pending request.
END

   To avoid this problem an RTSP agent
   is recommended to buffer incoming messages locally so that any
   response messages can be processed immediately upon reception.

Thus doesn't make sense to me.  If you're buffering them, you're not processing
each one immediately, right?  You won't process a message until it has its turn
to be popped out of the buffer.  What are you really trying to say here?

-- Section 10.7 --

   However, this can cause the situation where multiple RTSP clients
   again send requests to a proxy or server at roughly the same time
   which may again cause an overload situation, or if the "old" overload
   situation is not yet solved, i.e., the length indicated in the Retry-
   After header was too short.

I can't parse this (in particular, I can't make sense of what comes after ", or
if"); please try re-wording, probably splitting the too-long sentence in the
process.

   A more complex case may arise when a load balancing RTSP proxy is in
   use, i.e., where an RTSP proxy is used to select amongst a set of
   RTSP servers to handle the requests, or when multiple server
   addresses are available for a given server name.

Here's an example of a problem with using "i.e.": I can't tell what the scope
of the "i.e." is.  Is it the rest of the sentence ["X (i.e., A, or B)"], or is
it just the first part ["X (i.e., A), or B"] ?  Please clarify the text.

   It is REQUIRED to not set the
   same value in the timer for each scheduling, but instead to add a
   variation to the mean value, resulting in picking a random value
   within the range of 0.5 to 1.5 of the mean value.

Is this meant to say "0.5 to 1.5 *times* the mean value?  "Of" doesn't do that.

-- Section 13.5 --

   PLAY_NOTIFY requests MAY be used with a message body, depending on
   the value of the Notify-Reason header.  It is described in the
   particular section for each Notify-Reason if a message body is used.
   However, currently there is no Notify-Reason that allows using a
   message body.

That last sentence should be a clue that the "MAY" here is wrong.  You're not
describing an option for the implementor.  Depending upon the value of
Notify-Reason, either a body is needed or it isn't.  You can make this "may",
or, better, "will sometimes".

-- Section 15.1 --

   However, it is important to consider if this header
   and its function is required to be understood by the proxy or can be
   forwarded.  If the header needs to be understood, a feature-tag
   representing the functionality MUST be included in the Proxy-Require
   header.  Below are guidelines for analysis if the header needs to be
   understood.

In the first sentence, I think you mean, "or can simply be forwarded."  That
sense is lost without the word "simply".  In the last sentence, the guidelines
aren't for application only if the header need to be understood; they're
guidelines to determine that.  So, "Below are guidelines for analyzing
whether the header needs to be understood."

   The transport header and its parameters also shows that
   headers that are extensible and require correct interpretation in the
   proxy also require handling rules.

I don't understand this sentence at all.  Can you try re-wording it?

   Transport modifying:  The access and the security proxy both need to
      understand how the transport is performed, either for opening
      pinholes or to translate the outer headers, e.g., IP and UDP.

RTSP 2.0 isn't using UDP, right?  So what's that about?

-- Section 16.1.1 --

   In simple terms, a cache entry is considered to be
   valid if the content has not been modified since the Last-Modified
   value.

Strikes me as too simple, and wrong.  It's not possible for either the streamed
or the cached data to have been modified since the Last-Modified value.
What I think you mean to say is, "if the cache entry was created after the
Last-Modified time."

I managed to slog through this beast and am balloting No-Obj on the basis that I do not see any functionality that impacts Internet Area protocols.  I fully support the comments by other ADs that:

1. it seems improbable that two independent implementations would interoperate

2. the size and complexity of the spec makes it nigh unreadable

I have reviewed this to the extent that I think reasonable. and I have few misgivings about the text that aren't editorial.

I have a serious concern about the size and structure of the document.

By my count it took something like 11 years to write this. I think is is rather problematic to attempt to be comprehensive within the scope of single document. Parts of this, the IANA regististries, the security model section, the header defintions, examples, use of SDP, and so on should be separate documents. 

We should not be repeating this experience, either from an editing, implementation or registry management standpoint.

Just a couple of questions about section 10 ... 

In this text: 10.  Connections

   RFC 2326 attempted to specify an optional mechanism for transmitting
   RTSP messages in connectionless mode over a transport protocol such
   as UDP.  However, it was not specified in sufficient detail to allow
   for interoperable implementations.  In an attempt to reduce
   complexity and scope, and due to lack of interest, RTSP 2.0 does not
   attempt to define a mechanism for supporting RTSP over UDP or other
   connectionless transport protocols.  A side-effect of this is that
   RTSP requests MUST NOT be sent to multicast groups since no
   connection can be established with a specific receiver in multicast
   environments.

Is this the right way to say this? (If you try to open a multicast connection to a TCP address, do you get far enough to "send an RTSP request"?) 

In this text: 10.3.  Closing Connections

   A requester SHOULD wait at least 10 seconds for a response before
   concluding that the responder will not be responding to its request.
   After receiving a 100 response, the requester SHOULD continue waiting
   for further responses.  If more than 10 seconds elapses without
   receiving any response, the requester MAY assume that the responder
   is unresponsive and abort the connection by closing the TCP
   connection.

Would it be helpful to say anything about not immediately opening a new connection to the same unresponsive responder?

-- These used to be discuss points

(4) 19 - Why is there no equivalent of HTTP CONNECT for
TLS?  It seems like the choices are to either connect
directly over TLS to the origin server or else to have to
use a proxy that sees all the plaintext and headers.

(5) 19.2 - 2nd last para: Why don't you use SNI here? Just
wondering, but it'd fix a problem if it worked.

The authors response was that they hadn't been considered
and its too late in the day now but that they could be
investigated further later if needed. 

I think that's a shame and means that we're consciously
not doing as well at security as we might. However, I also
accept that this draft has been on the go since 2002 already
so its not likely to undergo any radical change now.

if there's a way to add a mention of these points as 
possible future work that'd be niice.


-- old coments

- If a [HX.Y] reference to 2616 has been updated or
changed by httpbis (which is on the telechat agenda after
this one) then is it correct for RTSP to still refer to
2616? I could imagine that the answer might vary in each
case.  Has someone checked if any such discrepencies exist
between this, 2616 and httpbis? (I could understand that
that'd have been an unreasonable question right up until
now when httpbis has completed IETF LC.)

- 2.1 - is this versioning scheme really still valid?  It
doesn't sound like it. If its not, then it might be good
to say that so folks don't write code that assumes things
will work like this in future.

- 4.3 - I don't believe you can confirm that something
"MUST be chosen cryptographically random" since it could
always be "Ri=E(k,Ri-1)" which will look but not be
random.

- 5.2 - Its probably defined somewhere but is there a way
to make a very long header field, e.g. like a DKIM
signature?

- 8.2 - I don't understand how its safe to treat an
unrecognised response header as a message body header.
That seems hacky and likely to encourage hacks. And I
don't recall that being said for request header fields.

- 10.2 - what are classifiers in n/w monitoring tools?

- 10.4 - typo: "taking long time" 

- 10.4 - the "agent SHOULD establish a new connection" as
a mitigation makes no sense to me - how would a server
(say) know where to connect to a proxy? (Which might be
behind a CGN who knows.)

- 10.5 - doesn't this assume that the RTSP and RTCP/RTP
server sides can communicate, but how can a client know
that?

- 10.5 - is "or when using reliable protocols" still
needed?

- 11.1 - 1st para: I've no idea what the last sentence
there is meant to mean.

- 13.3.1 - if I can change my transport parameters isn't
that a potential DoS vector?

- 13.9 - is there any chance someone will extend
SET_PARAMETER in a dangerous way? e.g. to allow:
C->S: SET_PARAMETER rtsp://eg.com/../etc/passwd RTSP/2.0 
      ...  
      root:x:0:0:root:/root:/bin/bash

- 13.9 - pity you'd used 451 already - Tim Bray's HTTP
451 is cute!

- 13.10 - is REDIRECT all ok with authentication? e.g.
there's no statement that the same dictionary attackable
equivalent for HTTP Basic or Digest MUST be sent if the
server redirects, etc.

- 13.10 -  I don't get what it'd mean for a client to send
a REDIRECT or does "The proxy is responsible for accepting
REDIRECT responses from its clients" mean something else?

- 14 - interleaved binary data, hmmm - buffer overrun
thoughts, lots of lovely complexity...

- 18.4.31-34 - I don't get the 466/470/471 errors, can you
explain?

- 18.7 - again, maybe reference httpbis?

- 18.10 - You don't say whether (D)TLS application PDU
padding is included or not, nor if this can be sent over
TCP.

- 20 - I skipped the ABNF sorry:-)

- 21.2.1: I don't see how "Thus, an RTSP server MUST only
allow client-specified destinations for RTSP-initiated
traffic flows if the server has ensured that the specified
destination address accepts receiving media through
different security mechanisms" can be implemented really.

- 21.2.1 - Doesn't that make [I-D.ietf-mmusic-rtsp-nat]
normative as you're saying its a solution for remote DoS?

I have reviewed this text solely looking for impact on the routing system and see no such impact.