Re: [AVTCORE] Request for publication of draft-ietf-avtcore-idms-09

[Richard Barnes <[e-mail]>]

Thanks, Roni.  Confirming receipt.  This hasn't shown up in the datatracker
yet as Publication Requested, but hopefully it will soon.
--Richard


On Sun, Mar 31, 2013 at 3:33 AM, Roni Even <[e-mail]> wrote:

> Hi Richard,****
>
> I'd like to request that draft-ietf-avtcore-idms-09, Inter-destination
> Media Synchronization using the RTP Control Protocol (RTCP), be published
> as Standard Track RFC. ****
>
> ** **
>
> I've reviewed the draft in detail, and the AVTCore 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
> AVTCore. Accordingly, please consider it for publication.****
>
> ** **
>
> Thanks,****
>
> Roni Even****
>
> ** **
>
> ** **
>
> (1) What type of RFC is being requested (BCP, Proposed Standard, Internet
> Standard, Informational, Experimental, or Historic)? Why is this the proper
> type of RFC? Is this type of RFC indicated in the title page header? ****
>
> This is a standard track RFC defining new RTCP packets and procedures for
> synchronizing media between multiple sites.****
>
> The title page header indicates it.****
>
> (2) 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:****
>
> This document defines a new RTP Control Protocol (RTCP) Packet Type and
> RTCP Extended Report (XR) Block Type to be used for achieving
> Inter-Destination Media Synchronization (IDMS).  IDMS is the process of
> synchronizing playout across multiple geographically distributed media
> receivers. Typical use cases in which IDMS is usefull are social TV,
> shared  service control (i.e. applications where two or more
> geographically  separated users are watching a media stream together),
> distance  learning, networked video walls, networked loudspeakers, etc.***
> *
>
> ****
>
> Working Group Summary:****
>
> This document went through a working group last call. There were comments
> and the document was updated to resolve all comments. The work started in
> ETSI and since it have to do with RTCP it was brought to the IETF AVTCore
> WG. The last issue that took some time was to update the ETSI document
> clarifying that the change control will be at the IETF.****
>
> Document Quality:****
>
> The document got good reviews from AVTcore members.  ****
>
> Personnel:****
>
> Roni Even is the Document Shepherd and the Responsible Area Director is Richard
> Barnes.****
>
> (3) Briefly describe the review of this document that was performed by the
> Document Shepherd. If this version of the document is not ready for
> publication, please explain why the document is being forwarded to the
> IESG. ****
>
> The shepherd reviewed the document very carefully in all the versions
> including the last one 09.****
>
> (4) Does the document Shepherd have any concerns about the depth or
> breadth of the reviews that have been performed? ****
>
> This document got good review by mutiple people from AVTcore and all
> comments were addressed.****
>
> (5) Do portions of the document need review from a particular or from
> broader perspective, e.g., security, operational complexity, AAA, DNS,
> DHCP, XML, or internationalization? If so, describe the review that took
> place. ****
>
> No need for any such review.****
>
> (6) Describe any specific concerns or issues that the Document Shepherd
> has 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. ****
>
> No concerns****
>
> (7) Has each author confirmed that any and all appropriate IPR disclosures
> required for full conformance with the provisions of BCP 78 and BCP 79 have
> already been filed. If not, explain why?****
>
> Yes, the shepherd has confirmed with all authors.****
>
> (8) Has an IPR disclosure been filed that references this document? If so,
> summarize any WG discussion and conclusion regarding the IPR disclosures.
> ****
>
> No IPR disclosure****
>
> (9) 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? ****
>
> There was a strong consensus to start this work at the IETF when it was
> brought. Multiple people contributed to the work and as a result the WG
> identified two new work items that are addressed in other new documents
> which are currently in progress.****
>
> (10) Has anyone threatened an appeal or otherwise indicated extreme
> discontent? If so, please summarise the areas of conflict in separate email
> messages to the Responsible Area Director. (It should be in a separate
> email because this questionnaire is publicly available.) ****
>
> No****
>
> (11) Identify any ID nits the Document Shepherd has found in this
> document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts
> Checklist). Boilerplate checks are not enough; this check needs to be
> thorough. ****
>
> No ID nits in this document.****
>
> (12) Describe how the document meets any required formal review criteria,
> such as the MIB Doctor, media type, and URI type reviews. ****
>
> Not applicable****
>
> (13) Have all references within this document been identified as either
> normative or informative? ****
>
> yes****
>
> (14) 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 plan for their completion? ****
>
> There is a normative reference to draft-ietf-avtcore-clksrc-03 that will
> start WGLC very soon.****
>
> (15) Are there downward normative references (see RFC 3967)? If so, list
> these downward references to support the Area Director in the Last Call
> procedure. ****
>
> no****
>
> (16) Will publication of this document change the status of any existing
> RFCs? Are those RFCs listed on the title page header, listed in the
> abstract, and discussed in the introduction? If the RFCs are not listed in
> the Abstract and Introduction, explain why, and point to the part of the
> document where the relationship of this document to the other RFCs is
> discussed. If this information is not in the document, explain why the WG
> considers it unnecessary. ****
>
> No****
>
> (17) Describe the Document Shepherd's review of the IANA considerations
> section, especially with regard to its consistency with the body of the
> document. Confirm that all protocol extensions that the document makes are
> associated with the appropriate reservations in IANA registries. Confirm
> that any referenced IANA registries have been clearly identified. Confirm
> that newly created IANA registries include a detailed specification of the
> initial contents for the registry, that allocations procedures for future
> registrations are defined, and a reasonable name for the new registry has
> been suggested (see RFC 5226). ****
>
> This document defines a new extension URI to the RTP Compact Header
> Extensions sub-registry of the Real-Time Transport Protocol (RTP)
> Parameters registry. The registration was reviewed by the document shepherd
> and it follows the registration requirements. ****
>
> ** **
>
> No new IANA registries are defined.****
>
> ** **
>
> (18) List any new IANA registries that require Expert Review for future
> allocations. Provide any public guidance that the IESG would find useful in
> selecting the IANA Experts for these new registries. ****
>
> No new IANA registries.****
>
> (19) Describe reviews and automated checks performed by the Document
> Shepherd to validate sections of the document written in a formal language,
> such as XML code, BNF rules, MIB definitions, etc. ****
>
> There is an ABNF definition for using the new RTCP packet using RFC3264
> offer answer. This is common for any new RTCP packe****
>