ietf
[Top] [All Lists]

Re: Gen-art additional LC review of draft-ietf-mmusic-rfc2326bis-34

2013-06-07 04:35:56
Hi Elwyn,

Many thanks for the detailed review. We will address the nits you have
raised, but I cut them out of this reply to focus on the more
substantial issues you have brought up.

See inline below.

On 2013-06-06 02:11, Elwyn Davies wrote:
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.

These syntax changes where discussed in the reviews I got on the URI
list. That resulted in the explicitness in the template, but I forgot
about adding anything into Section 4.2. I see no issue with adding the
following clarification to Section 4.2:

   The details of the syntax of "rtsp" and "rtsps" URIs has been changed
   from RTSP 1.0.  These changes are:

   o  Support for IPV6 literal in host part and future IP literals
      through RFC 3986 defined mechanism.

   o  A new relative format to use in the RTSP protocol elements that is
      not required to start with "/".

   Neither should have any significant impact on interoperability.  If
   one is required to use IPv6 literals to reach an RTSP server, then
   that RTSP server must be IPv6 capable, and RTSP 1.0 is not a fully
   IPv6 capable protocol.  Thus, RTSP 2.0 support will be needed anyway.
   The second change will only occur in RTSP messages, that are
   explicitly identified as being RTSP 2.0 messages, thus a RTSP 1.0
   only agent will not be required to parse this variant.

I hope this makes it clear that these syntax changes is unlikely to hurt
the interoperability.



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.


I assume you mean this Section 12 paragraph:

   If a pipelined request builds on the successful completion of one or
   more prior requests the requester must verify that all requests were
   executed as expected.  A common example will be two SETUP requests
   and a PLAY request.  In case one of the SETUP fails unexpectedly, the
   PLAY request can still be successfully executed.  However, the
   resulting presentation will not be as expected by the requesting
   client, as only a single media instead of two will be played.  In
   this case the client can send a PAUSE request, correct the failing
   SETUP request and then request it to be played.

I think I agree with your assessment, that it would have been nice.
However, we should have thought of that when we introduced this type of
pipelining 7 years ago. Making any changes to this at this stage is
counter productive. The reality is that all the "nice" features and
necessary clarifications has been retrofitted into RTSP 1.0 by the ones
that have been using RTSP 1.0. So changing anything will separate the
RTSP 1.0 and RTSP 2.0 implementations. The good thing is that I can't
remember any substantial complaints about this issue.

I hope this resolves your comments.

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(_dot_)westerlund(_at_)ericsson(_dot_)com
----------------------------------------------------------------------