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

[Magnus Westerlund <[e-mail]>]

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  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: [e-mail]
----------------------------------------------------------------------