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**** >
- [AVTCORE] Request for publication of draft-ietf-a… Roni Even
- Re: [AVTCORE] Request for publication of draft-ie… Richard Barnes