RTP Payload Format for the Adaptive TRansform Acoustic Coding (ATRAC) Family
draft-ietf-avt-rtp-atrac-family-24

[Ballot discuss]
Section 5.3.1: "This value SHOULD be zero for an unfragmented frame."

Can someone please explain how any any other value than 0 can be allowed for an unfragmented frame. By the definition of the field all other values will be interpreted as this being a fragment. Even if C=0 the inconsistency between having the filed be seperate from 0 indicates that some fragements should have preceeded this packet. And if that packet was lost one can't determine that previous packet didn't contain a fragment. I suggest to change the SHOULD to a MUST.

Section 7.6 Signaling of dependency for enhancements layers in offer/answer session. The specification doesn't talk about signalling of that despite the fact that it is as useful to setup a session with offer/answer as with declarative usage. Can you please motivate the choice of not talking about this for offer/answer?

Text has been added in 7.6 but the corresponding text in 7.7 was removed which I don't it should.

[Ballot discuss]
According to BCP 13 (RFC 4288), the change controller for a standards
track media type registration needs to be the standards body itself.

I'd find one of the following acceptable:
  "the IETF"
  "IETF AVT WG delegated from the IESG"
  "the IESG"
I recommend splitting author and change controller into separate fields,
as both are useful.

[Ballot discuss]
While the Security Considerations references RFC 4855, it does not directly address
some of the aspects that 4855 requires or recommends in the security analysis.
In particular,  4855 states:

      o  All registrations MUST state whether or not they employ such
        "active content", and if they do, they MUST state what steps
        have been taken to protect users of the media type from harm.

[Since this is all about audio, I would guess that there is no active content, so it would be
a one sentence fix.  However, I am just guessing.... ]

Since these media types employ compression, the following issue should
also be addressed:

      o  A media type that employs compression may provide an
        opportunity for sending a small amount of data that, when
        received and evaluated, expands enormously to consume all of
        the recipient's resources.  All media types SHOULD state
        whether or not they employ compression, and if they do they
        should discuss what steps need to be taken to avoid such
        attacks.

I would appreciate it if the authors could review the second list in
RFC 4855's security considerations.  There may be other relevant
issues that I failed to recognize.

[Ballot discuss]
Please consider the comments provided by Scott Brim in his Gen-ART
  Review.  The document has been revised since the comments were submitted,
  but there has been no discussion of the comments themselves, so it is
  unclear whether they were considered or not.  This review deserves a
  response.

[Ballot discuss]
Section 4.5.2:

I think this section is missing to answer one important factor on how one determines which streams in each of the base and enhancement RTP sessions that belong together. I get the strong impression that the timestamp synch text is only discussing the issue of finding the frames that belong to the audio stream frame position. The common solution for this problem has been to either use CNAME bindings to find them or require the same SSRC in both RTP session. I think the problem needs to be discussed at least here.

Section 5.3.1: "This value SHOULD be zero for an unfragmented frame."

Can someone please explain how any any other value than 0 can be allowed for an unfragmented frame. By the definition of the field all other values will be interpreted as this being a fragment. Even if C=0 the inconsistency between having the filed be seperate from 0 indicates that some fragements should have preceeded this packet. And if that packet was lost one can't determine that previous packet didn't contain a fragment. I suggest to change the SHOULD to a MUST.

Section 7.6 Signaling of dependency for enhancements layers in offer/answer session. The specification doesn't talk about signalling of that despite the fact that it is as useful to setup a session with offer/answer as with declarative usage. Can you please motivate the choice of not talking about this for offer/answer?

[Ballot discuss]
Section 4.5.2:

I think this section is missing to answer one important factor on how one determines which streams in each of the base and enhancement RTP sessions that belong together. I get the strong impression that the timestamp synch text is only discussing the issue of finding the frames that belong to the audio stream frame position. The common solution for this problem has been to either use CNAME bindings to find them or require the same SSRC in both RTP session. I think the problem needs to be discussed at least here.

Section 5.3.1: "This value SHOULD be zero for an unfragmented frame."

Can someone please explain how any any other value than 0 can be allowed for an unfragmented frame. By the definition of the field all other values will be interpreted as this being a fragment. Even if C=0 the inconsistency between having the filed be seperate from 0 indicates that some fragements should have preceeded this packet. And if that packet was lost one can't determine that previous packet didn't contain a fragment. I suggest to change the SHOULD to a MUST.

[Ballot comment]
Section 5.3.1:
  Number of Frames (NFrames): 4 bits
  The number of audio frames in this packet.

Shouldn't this be defined as "The number of audio frames in this packet are field value + 1"?

[Ballot discuss]
Section 4.5.2:

I think this section is missing to answer one important factor on how one determines which streams in each of the base and enhancement RTP sessions that belong together. I get the strong impression that the timestamp synch text is only discussing the issue of finding the frames that belong to the audio stream frame position. The common solution for this problem has been to either use CNAME bindings to find them or require the same SSRC in both RTP session. I think the problem needs to be discussed at least here.

Section 5.3.1: "This value SHOULD be zero for an unfragmented frame."

Can someone please explain how any any other value than 0 can be allowed for an unfragmented frame. By the definition of the field all other values will be interpreted as this being a fragment.

IANA Last Call comments:

Upon approval of this document, the IANA will make the following
assignments in the "Audio Media Types" registry at
http://www.iana.org/assignments/media-types/audio/

ATRAC3 [RFC-avt-rtp-atrac-family-16]
ATRAC-X [RFC-avt-rtp-atrac-family-16]
ATRAC-ADVANCED-LOSSLESS [RFC-avt-rtp-atrac-family-16]

We understand the above to be the only IANA Action for this
document.

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