Subject: [AVT] request to publish draft-ietf-avt-rtp-svc-22

From: Roni Even <[email-masked]>
Date: Thu, 09 Sep 2010 15:32:54 +0300

Hi Robert,

I'd like to request that draft-ietf-avt-rtp-svc-22, RTP Payload Format for
SVC Video, 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 three WGLC. The third one was to allow people to
verify the consistency with draft-ietf-avt-rfc384bis. The comments were
addressed. Before the first WGLC, the document merged two proposals and a
lot of editorial work from all authors. 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 are 6 IPR statements
(https://datatracker.ietf.org/ipr/search/?option=document_search
<https://datatracker.ietf.org/ipr/search/?option=document_search&document_se
arch=draft-ietf-avt-rtp-svc> &document_search=draft-ietf-avt-rtp-svc ).
There were discussions on the list and in previous IETF meetings but they
were all addressed and there was a consensus to accept this work with all
these IPR statements. The merging of the two initial individual drafts was
done in correlation with the finalizing of some of the IPR statements.

    (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.  There
was a design team that put a lot of effort to draft the final document. It
was presented in AVT sessions and was heavily discussed considering that
this is a payload specification which are usual simple.

    (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 some comments and warnings which are OK.

The media subtype was sent to review to ietf-types and there were no
comments.

    (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 two normative references to  

internet-drafts which are in publication stages.

    (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 describes an RTP payload format for Scalable Video Coding

   (SVC) as defined in Annex G of ITU-T Recommendation H.264, which is
technically identical to Amendment 3 of ISO/IEC International Standard
14496-10.  The RTP payload format allows for packetization of one or more
Network Abstraction Layer (NAL) units in each RTP  packet payload, as well
as fragmentation of a NAL unit in multiple  RTP packets.  Furthermore, it
supports transmission of an SVC stream

   over a single as well as multiple RTP sessions.  The payload format

   defines a new media subtype name "H264-SVC", but is still backwards

   compatible to [I-D.ietf-avt-rtp-rfc3984bis] since the base layer,

   when encapsulated in its own RTP stream, must use the H.264 media

   subtype name ("H264") and the packetization method specified in [I-

   D.ietf-avt-rtp-rfc3984bis].  The payload format has wide

   applicability in videoconferencing, Internet video streaming, and

   high bit-rate entertainment-quality video, among others."

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 was a very heated discussion before the two proposals were merged.
Once agreement was achieved the work progress smoothly using a design team.

           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 is a payload specification for H.264 scalable video coding. It is being
used in some streaming and video conferencing applications. It is referenced
by other standard bodies. 

           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.