[AVT] Request for approval of draft-ietf-avt-hdrext-15.txt as Standards Track RFC

[Tom Taylor <[e-mail]>]

This is a request to approve the RTP header extensions draft,
draft-ietf-avt-hdrext-15.txt, as a Standards Track RFC. The PROTO
writeup follows:

(begin)

As required by RFC-to-be draft-ietf-proto-wgchair-doc-shepherding, this
is the current template for the Document Shepherd Write-Up. Changes are
expected over time. This version is dated February 1, 2007.

This is the write-up for draft-ietf-avt-rtp-hdrext-15.txt.

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

(1.a) Who is the Document Shepherd for this document?

    Tom Taylor <[e-mail]>

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?

    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?

    The document has been well reviewed within the Working Group. The only WGLC
    comments were from solicited reviews and the Document Shepherd. One of the
    solicited reviewers was David Oran, who has broad experience across many WGs.

    Document history: This grew out of work on the association of SMPTE time codes
    with RTP streams, when it was recognized that a general capability for
    creation of header extensions, more flexible than that in RFC 3550, would be
    useful. The initial document, draft-singer-rtp-hdrext-00.txt, was published
    2005-6-1. The Chair requested a WG review to decide if this should be a WG
    work item. Agreement came out of the 2005-8 Paris meeting to accept it as
    such. draft-ietf-avt-rtp-hdrext-00.txt was published 2005-8-16. The major
    open item at the time was how to register header extensions. The only
    additional 2005 list activity following that publication was a set of review
    comments from Colin Perkins.

    Discussion picked up in the following year, with over 100 relevant messages
    exchanged on the AVT list, particularly in the July time frame. Those in the
    latter part of the year mostly related to applicability of the mechanism to
    other proposed work in progress. Useful changes continued to be decided and
    implemented in new drafts up through draft-ietf-avt-rtp-hdrext-08.txt
    (published 2006-12-15). WGLC was announced 2006-12-18, to end on 2007-1-14.
    Solicited review comments, both technical and editorial, were received from
    Dave Oran and addressed in draft-ietf-avt-rtp-hdrext-09.txt (published
    2007-2-14). The Document Shepherd had some editorial issues, including a fix
    to the ABNF that was inadvertently missed in updating to version -10.

    hdrext-12 was submitted for publication a year ago, but two major events held
    up publication. The first was a number of concerns expressed by the
    responsible Area Director (see ID Tracker comments, 2007-04-27). The second
    was the discovery of implementations of a similar mechanism using larger
    fields. The latter resulted in an updated draft implementing both 4+4 and 8+8
    bit sub-headers. The AD's concerns were discussed in a phone call in
    September, 2007. However, the AD remained unconvinced that a consensus
    existed in favour of the registration requirements stated in the existing
    version of the draft, and returned it to the Working Group for further
    discussion. A request for opinions was issued to the AVT list on 2008-02-25,
    with the question:

    "Do you find that the current text in draft-ietf-avt-hdrext-14.txt regarding
    naming of header extensions and registration requirements is acceptable?"

    There were eight YES responses, and no NOs. The Chairs found this to be a
    solid consensus and therefore referred the draft back to the IESG for
    publication.

    Version 15 was submitted to cover some unrelated and minor issues.

    See further history in 1(d) below.

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


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

    During the mid-2006 discussions, Stephen Casner expressed concern about the
    impact on RTP architecture if the RTP header extension mechanism is made
    easier to use.  The matter was taken up in the 2006-07 (Montreal) meeting.
    Points were raised about tradeoffs between using the header extension
    mechanism and new profiles, bearing in mind the signalling issues attendant
    upon the latter. There was no resolution and further discussion was referred
    to the RAI-discuss list. Somehow the debate died out and there were no
    adverse comments raised during WGLC.

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

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

    At one time or another most of the regular contributors to the WG have
    commented on this draft. In the Document Shepherd's judgement the WG has
    accepted that the usefulness of the mechanism outweighs the risks to
    interoperability which would come about through misuse of the mechanism. The
    document states normatively that the mechanism must be used only with data
    that can be safely ignored by the receiver. If honoured, that requirement
    will mitigate the risk.

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

(1.f)
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 entered into the ID
Tracker.)

    No.

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

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

    IDnits reports that the ABNF reference (was 4234, now 5234) is out of date.

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

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

    All OK.

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

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

    The IANA Considerations section exists and is consistent with the body of the
    text. It creates a registry for IETF-defined RTP header extensions and
    registers a new SDP attribute. Additions to the new registry are made on the
    basis of "Specification Required".

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

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

    Yes.

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

(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 provides a general mechanism to use the header-
     extension feature of RTP (the Real Time Transport Protocol).  It
     provides the option to use a small number of small extensions in each
     RTP packet, where the universe of possible extensions is large and
     registration is de-centralized.  The actual extensions in use in a
     session are signaled in the setup information for that session.

Working Group Summary

     This document is a product of the AVT Working Group. While this document was
     in progress, concerns were raised about the potential impact of making RTP
     header extensions easier to specify on the RTP architecture and on
     interoperability. The issue was debated at IETF 66 without coming to a
     definite conclusion. RTP profiles are an alternative to header extensions,
     but present significant problems of signalling which are just beginning to
     ber esolved. By the time WGLC came, the AVT WG consensus was to accept the
     header extension mechanism provided in this document. To mitigate the risk
     of interoperability problems, the document specifies normatively that the
     information carried in RTP header extensions defined according to this
     document MUST be such that a receiver can safely ignore this information and
     still be able to process the payload content.

Document Quality

     This document has been in progress since June, 2005. Colin Perkins suggested
     useful changes at multiple stages. Dave Oran performed a final review which
     identified some technical points which were quickly resolved. Two extensions
     are currently being defined based on the proposed mechanism, and others are
     under consideration. Interest in implementations is beginning to appear.

Personnel

   Who is the Document Shepherd for this document?

     Tom Taylor <[e-mail]>

   Who is the Responsible Area Director?

     Cullen Jennings <[e-mail]>

   Is an IANA expert needed?

     Yes.

   (end)


_______________________________________________
Audio/Video Transport Working Group
[e-mail]
https://www1.ietf.org/mailman/listinfo/avt



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