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

["Tom-PT Taylor" <[e-mail]>]

This is a request to approve the RTP header extensions draft,
draft-ietf-avt-hdrext-12.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-12.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.

   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?

   All OK.

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

(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 be
    resolved. 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?

    No.

  (end)


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