Subject: [AVT] Request to publish draft-ietf-avt-rapid-rtp-sync-10

From: Roni Even <[email-masked]>
Date: Wed, 05 May 2010 14:17:02 +0300

Hi Robert,

I'd like to request that draft-ietf-avt-rapid-rtp-sync-10, Rapid
Synchronization of RTP Flows, be published as Standard Track RFC. 

I've reviewed the draft in detail, and the AVT working group was given the
opportunity to comment. The draft is documented in sufficient detail to meet
the registration requirements, and doesn't conflict with other work in AVT.
Accordingly, please consider it for publication.

Thanks,

Roni Even

Document Shepherd Write-Up

    (1.a)  Who is the Document Shepherd for this document?  Has the

           Document Shepherd personally reviewed this version of the

           document and, in particular, does he or she believe this

           version is ready for forwarding to the IESG for publication?

The document shepherd is Roni Even. I have reviewed the document,  

and believe it is ready for publication.

    (1.b)  Has the document had adequate review both from key WG members

           and from key non-WG members?  Does the Document Shepherd have

           any concerns about the depth or breadth of the reviews that

           have been performed?

The document went through  a WGLC. The comments were minor and were
addressed. Before the WGLC, the document started as a merger of two
proposals and was in the WG for eight months as a WG document in order to
let people review it. The document shepherd has no concerns about the review
process.

    (1.c)  Does the Document Shepherd have concerns that the document

           needs more review from a particular or broader perspective,

           e.g., security, operational complexity, someone familiar with

           AAA, internationalization or XML?

No concerns.

    (1.d)  Does the Document Shepherd have any specific concerns or

           issues with this document that the Responsible Area Director

           and/or the IESG should be aware of?  For example, perhaps he

           or she is uncomfortable with certain parts of the  document, or
has concerns whether                there really is a need for it.  In any

           event, if the WG has discussed those issues and has indicated

           that it still wishes to advance the document, detail those

           concerns here.  Has an IPR disclosure related to this document
been filed?  If so, please include a reference to the disclosure and
summarize the WG discussion and conclusion on this issue.

No concerns. There is an IPR statement
(https://datatracker.ietf.org/ipr/1140/) . There were no concerns about the
IPR in the WG.

    (1.e)  How solid is the WG consensus behind this document?  Does it

           represent the strong concurrence of a few individuals, with

           others being silent, or does the WG as a whole understand and

           agree with it?

The document has good consensus from the WG there was a good mailing list
discussion on the individual drafts that resulted in a WG document.  It was
presented in AVT sessions and the editors (Colin Perkins and Thomas Schierl)
are very familiar with RTP and RTCP.

    (1.f)  Has anyone threatened an appeal or otherwise indicated  

           extreme discontent?  If so, please summarize the areas of
conflict in

           separate email messages to the Responsible Area Director.   

         (It  should be in a separate email because this questionnaire is

           entered into the ID Tracker.)

No.

    (1.g)  Has the Document Shepherd personally verified that the

           document satisfies all ID nits?  (See

           http://www.ietf.org/ID-Checklist.html and

           http://tools.ietf.org/tools/idnits/).  Boilerplate checks are

           not enough; this check needs to be thorough.  Has the  

           document  met all formal review criteria it needs to, such as the
MIB

           Doctor, media type and URI type reviews?

The idnits tool reports no nits.

    (1.h)  Has the document split its references into normative and

           informative?  Are there normative references to documents  

           that  are not ready for advancement or are otherwise in an
unclear

           state?  If such normative references exist, what is the

           strategy for their completion?  Are there normative  

           references that are downward references, as described in
[RFC3967]?  If

           so, list these downward references to support the Area

           Director in the Last Call procedure for them [RFC3967].

References have been split. There are no normative references to  

internet-drafts which are in progress. 

    (1.i)  Has the Document Shepherd verified that the document IANA

           consideration section exists and is consistent with the body

           of the document?  If the document specifies protocol

           extensions, are reservations requested in appropriate IANA

           registries?  Are the IANA registries clearly identified?  If

           the document creates a new registry, does it define the

           proposed initial contents of the registry and an allocation

           procedure for future registrations?  Does it suggest a

           reasonable name for the new registry?  See [RFC2434].  If the

           document describes an Expert Review process has Shepherd

           conferred with the Responsible Area Director so that the IESG

           can appoint the needed Expert during the IESG Evaluation?

The IANA considerations section exists; the registries are identified there
are no new registries.

    (1.j)  Has the Document Shepherd verified that sections of the

           document that are written in a formal language, such as XML

           code, BNF rules, MIB definitions, etc., validate correctly in

           an automated checker?

No such sections

    (1.k)  The IESG approval announcement includes a Document

           Announcement Write-Up.  Please provide such a Document

           Announcement Write-Up?  Recent examples can be found in the

           "Action" announcements for approved documents.  The approval

           announcement contains the following sections:

           Technical Summary

              Relevant content can frequently be found in the abstract

              and/or introduction of the document.  If not, this may be

              an indication that there are deficiencies in the abstract

              or introduction.

"This memo outlines how RTP sessions are synchronised, and discusses how
rapidly such synchronisation can occur.  We show that most RTP sessions can
be synchronised immediately, but that the use of video switching multipoint
conference units (MCUs) or large source specific multicast (SSM) groups can
greatly increase the synchronization delay.  This increase in delay can be
unacceptable to some applications that use layered and/or multi-description
codecs.

This memo introduces three mechanisms to reduce the synchronisation delay
for such sessions.  First, it updates the RTP Control Protocol (RTCP) timing
rules to reduce the initial synchronisation delay for SSM sessions.  Second,
a new feedback packet is defined for use with the Extended RTP Profile for
RTCP-based Feedback (RTP/AVPF), allowing video switching MCUs to rapidly
request resynchronisation.  Finally, new RTP header extensions are defined
to allow rapid synchronisation of late joiners, and guarantee correct
timestamp based decoding order recovery for layered codecs in the presence
of clock skew."

Working Group Summary

              Was there anything in WG process that is worth noting?   

             For   example, was there controversy about particular points or

              were there decisions where the consensus was particularly

              rough?

There is nothing specific to note.

           Document Quality

              Are there existing implementations of the protocol?   

              Have a significant number of vendors indicated their plan to

              implement the specification?  Are there any reviewers that

              merit special mention as having done a thorough review,

              e.g., one that resulted in important changes or a

              conclusion that the document had no substantive  

               issues?  If  there was a MIB Doctor, Media Type or other
expert review,

              what was its course (briefly)?  In the case of a Media  

              Type review, on what date was the request posted?

This document explains and updates the timing consideration for RTCP in RFC
3550. It also defines new protocol that is referenced by other documents
like payload specification for H.264 SVC
http://tools.ietf.org/html/draft-ietf-avt-rtp-svc-21 

           Personnel

              Who is the Document Shepherd for this document?  Who is  

              the Responsible Area Director?

Roni Even is the document shepherd. 

The responsible area director is Robert Sparks.