[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[AVT] Request for approval of draft-ietf-avt-hdrext-15.txt as Standards Track RFC
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 <taylor at nortel.com>
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 <taylor at nortel.com>
Who is the Responsible Area Director?
Cullen Jennings <fluffy at cisco.com>
Is an IANA expert needed?
Yes.
(end)
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www.ietf.org/mailman/listinfo/avt