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

Richard Barnes <rlb@ipv.sx> Mon, 01 April 2013 17:40 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6AD21F8D0D for <avt@ietfa.amsl.com>; Mon, 1 Apr 2013 10:40:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.037
X-Spam-Level:
X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.940, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckOBsra9GwwF for <avt@ietfa.amsl.com>; Mon, 1 Apr 2013 10:40:33 -0700 (PDT)
Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 99FF321F8D01 for <avt@ietf.org>; Mon, 1 Apr 2013 10:40:33 -0700 (PDT)
Received: by mail-oa0-f49.google.com with SMTP id j6so2169400oag.22 for <avt@ietf.org>; Mon, 01 Apr 2013 10:40:33 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=IziIK7yxnY9Oy0ASs2ZFRM2zVCSUaF6SlIlyngJL47k=; b=MaGL3Wct5f4vnEvMo5niBEkJbgSe75VLVsCN2jVZVEKegmHrHkE2WhUc6GwOyClr/T NlM9xi4eJOD8jyWa6urD5mPvg0ETUUCfSaCU/5Z58SFpRNZEf1rhKQxRE4TzZXMFpL6t p7r8qKkN4TBGuOLdeO4f54yUoDcEQnmu03xeahfq6awwcIFcllAk52smu1yi5S+avgZ4 a3bobz13X10drgvzaS9e4MvqlkhY3oRDXphSshnv5f1cHGWS8Wk42L17goYwxyN6hU/X UBs/97rgve8fw3tQBA45MDLwpnrRAs7uolYMGaEFN3mS0zqlbLv2OC3zmAhURTIhRfg/ NXYg==
MIME-Version: 1.0
X-Received: by 10.60.14.104 with SMTP id o8mr4299840oec.127.1364838033154; Mon, 01 Apr 2013 10:40:33 -0700 (PDT)
Received: by 10.60.160.201 with HTTP; Mon, 1 Apr 2013 10:40:33 -0700 (PDT)
X-Originating-IP: [192.1.51.16]
In-Reply-To: <05c501ce2de1$fedab280$fc901780$@gmail.com>
References: <05c501ce2de1$fedab280$fc901780$@gmail.com>
Date: Mon, 01 Apr 2013 13:40:33 -0400
Message-ID: <CAL02cgRexiCKzWMCS9UfYZkb8dZ04gOTEZbEw5DjcKLsEv5Gag@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: Roni Even <ron.even.tlv@gmail.com>
Content-Type: multipart/alternative; boundary="e89a8fb1ef1624bd1b04d9501ed5"
X-Gm-Message-State: ALoCoQklYS6eQt1M52OX6bg09nmcA/U1O4wIYn9qg5+r4xDabcALVnn5E63TZBcttNjxAylFm/7K
Cc: iesg-secretary@ietf.org, rai-ads@tools.ietf.org, avt@ietf.org, Magnus Westerlund <magnus.westerlund@ericsson.com>
Subject: Re: [AVTCORE] Request for publication of draft-ietf-avtcore-idms-09
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/avt>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Apr 2013 17:40:35 -0000

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 <ron.even.tlv@gmail.com> 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****
>