Subject: [AVT] PROTO writeup for draft-ietf-avt-rtp-atrac-family-16

From: Tom Taylor <[email-masked]>
Date: Tue, 22 Apr 2008 22:16:02 -0400

The request for publication of draft-ietf-avt-rtp-atrac-family-16 as a Proposed 
Standard has been sent to the IESG. The associated PROTO writeup is attached.

Tom Taylor
Document Shepherd
This is the Document Shepherd Write-Up for draft-ietf-avt-rtp-atrac-family-16, RTP Payload Format for Adaptive TRansform Acoustic Coding (ATRAC) Family. The template for this write-up is drawn directly from RFC 4858, which describes the shepherding process. No later version of the template appears to be available.

   (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?

          Document Shepherd is Tom Taylor <[email-masked]>.
          Yes and yes.

   (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?

          Review has been adequate, with strong guidance from Magnus
          Westerlund and then Colin Perkins. See history following the
          template.

   (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.

   (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 specific concerns. See IPR disclosure
          https://datatracker.ietf.org/ipr/939/. The WG had no issue
          with the existence of the IPR.

   (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?

          I believe the WG as a whole understands and agrees with the draft,
          even though very few have commented on it. Possibly the WG has
          placed its trust in the WG leadership to make sure the document is 
          ready.

   (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 conflict.

   (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?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

          Yes. Absence of intended status noted. Intended status is
          Proposed Standard.

   (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 are split. There is a normative reference to
          draft-ietf-mmusic-decoding-dependency-01.txt

   (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations 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 the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

          IANA considerations are limited to registration of three new
          media types.

   (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?

          Example SDP not so verified, but inspected manually.

   (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
   This document describes an RTP payload format for efficient and
   flexible transporting of audio data encoded with the Adaptive
   TRansform Audio Coding (ATRAC) family of codecs. Recent enhancements
   to the ATRAC family of codecs support high quality audio coding with
   multiple channels.  The RTP payload format as presented in this
   document also includes support for data fragmentation, elementary
   redundancy measures, and a variation on scalable streaming.

          Working Group Summary
   The first predecessor to this document appeared in late 2002. Since 
   then the document has progressed steadily with strong guidance from
   the AVT Chairs. It was accepted as a Working Group item in August 2004.
   Working Group Last Call drew one comment on the media types list and 
   a final Chair's review. All comments have been resolved.

          Document Quality
   The authors have implemented the content of the document. Media type
   review was requested for the three media types on 19/2/2008.

          Personnel
   Document Shepherd is Tom Taylor <[email-masked]>. Cullen Jennings
   is the responsible Area Director.

---------------

Appendix: Document History

draft-hatanaka-avt-rtp-atracx, a predecessor document, was initially published in October, 2002. It was presented at the Atlanta meeting (IETF 55) shortly thereafter and drew comments from Stephen Casner, Magnus Westerlund, Colin Perkins and Roni Even. A second version was presented at the next meeting in San Francisco. It responded to comments from the first meeting, but drew further questions. One point answered in that second presentation was why the authors did not choose to use RFC 2198 for redundancy -- a natural question which is still relevant. -02 was published in June 2003, but drew no list comments. -03 was published in October 2003. Magnus Westerlund reviewed the document extensively (1/11/2003), calling for a redesign. The authors agreed, and the IETF 58 minutes simply note its status as requiring redesign.

The redesign was published as draft-hatanaka-avt-rtp-atrac-family-00.txt in January 2004. This draft expanded its coverage to include earlier ATRAC codecs. Magnus Westerlund gave further strong guidance to the authors. In March, after review at the Seoul meeting, version -01 was published, incorporating the further comments received to this point. Version -02 was published in July 2004, and the draft was accepted as a Working Group item at IETF 60. The draft was reissued as draft-ietf-avt-rtp-atrac-family-00 in August 2004. No further comments are seen on the list that year, but draft-ietf-avt-rtp-atrac-family-01 was published in October.

Versions -02 and -03 of the Working Group draft were published in February and May 2005. Colin Perkins reviewed and identified issues in the -03 version. The key issue was the desire to transmit metadata along with the payload. Colin suggested this would be better done in a new SDES packet in RTCP, but the author did not follow up. Instead, version -04 (published in July 2005) dropped the auxiliary data but added a new member of the ATRAC codec family. The draft drew a couple of minor comments from Colin Perkins and Magnus Westerlund, which were addressed in version -05, issued in December 2005. The main point of discussion was whether the "Intended Usage" entry for a proprietary codec should be "Common" or "Limited usage". The authors pointed out AAC/MP3 provided a precedent for "Common".

Colin Perkins had a couple of comments on version -05 in early January 2006, particularly regarding use of the new media type (RFC 4288) registration template. Version -06 appeared in June 2006. Colin reviewed this version in detail, provided mostly editorial comments. Version -07 was published in December 2006. Version -08, published in June 2007, more fully addressed Colin's comments. Colin had a few more editorial comments, addressed in version -09 (July 2007). Version -10 (August 2007) introduced some small technical modifications. Colin again had comments. Version -11 was published in December 2007, and -12 and -13 in January 2008, each update addressing minor issues.

Working Group Last Call was announced for draft-ietf-avt-rtp-atrac-family-13.txt on 16 February 2008, and closed without comment. Tom Taylor provided a review while announcing an end to WGLC. In the review for media type registration, Harald Alvestrom questioned the absence of a reference for the content of the payload. After due consideration Sony provided the required reference. The updates resulting from this and Tom's comments resulted in versions -14 and -15 (March 2008). The authors made one more update in early April to add  permitted values for the 'rate' parameter (version -16).

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt