A General Mechanism for RTP Header Extensions
draft-ietf-avt-rtp-hdrext-15

[Ballot comment]
1. Should not this document be marked as updating RFC3550 (if approved)?

2. Section 10 should be taken out from the final version of the document at publication. Actually the notes to the RFC Editor could have been inserted in the respective sections of the document.

[Ballot discuss]
Section 5 recommends that "the URI SHOULD also be de-referencable by
any system that sees or receives the SDP containing it".  What kind of
resource the URI should point to? Should entities receiving SDP
automatically fetch it? (that seems dangerous) The SHOULD also seems a
bit strange considering that Section 5 also recommends using URNs,
which usually won't be dereferencable.

IANA Last Call comments:

Action 1:

[ IESG Note: Expert Required ]

Upon approval of this document, the IANA will create the following
registry at http://www.iana.org/assignments/TBD

Registry Name: RTP Compact Header Extensions
Registration Procedures: Expert Review
Note: For extensions defined in RFCs, the URI is recommended to
be of the form urn:ietf:params:rtp-hdrext:, and the formal
reference is the RFC number of the RFC documenting the extension.

Initial contents of this registry will be:

Extension URI Description Contact Reference
------------- ------------ --------- -----------



Action 2:

Upon approval of this document, the IANA will make the following
assignments in the "Session Description Protocol (SDP) Parameters”
registry at http://www.iana.org/assignments/sdp-parameters
sub-registry "att-field (both session and media level)"

Type SDP Name Reference
---- ------------------ ---------
att-field (both session and media level)
extmap [RFC-avt-rtp-hdrext-15]


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

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

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

  Who is the Responsible Area Director?

    Cullen Jennings

  Is an IANA expert needed?

    Yes.

  (end)

For the IANA registrations, it looks like things ended on "IETF Consensus" as the registration - there were pretty much no comments on any of it with really only Magnus stating much of an opinion - and Magnus opinion eventually landed on IETF Consensus on his email of Jun 28, 2007. My belief (possibly wrong) is that that the current registration procedure is more or less Standards Action so I am willing to AD sponsor a document that is requires Standard Action or IETF Consensus which is somewhat relaxed. I see no mailing list support for something else so I am unwilling to AD Sponsor this document if it is not going to be this.

Please reference draft-narten-iana-considerations-rfc2434bis for the definition of terms. This is at the IESG and will be the new RFC soon. This new RFC will use the term "IETF Review" for what used to be called "IETF Consensus" so use that term.

I reviewed rest of document very quickly and I may be very confused on some of these comments so let me know ....

In the examples, I did not understand whey the pad was in middle of the series of ID,L,Value tuples - it seemed like it should be after the last one. I don't care how it is done - just seemed like their was an issue here.

Having appbits with undefined semantics is not going to work for me. We would need more explanation of how these were defined when used and more importantly how they were negotiated or just remove them. I would suggesting removing by far the shortest path.

Given we have at least one objection (Magnust) to having both 4+4 and 8+8, we will need to resolve that. I'm fine doing this in IETF LC.

The IANA section will need to give IANA clear instructions on registering the 0x100x 0xBEDE values

The IANA section will have to give clear instruction on what the new hdrext registry looks like

Given this type of registration, I think just having named tags would be much better than URN. In fact I would be explicitly against URN due to the size and that it would be used to ignore the IANA registry

The discussion around the usable range being 4096-4351 seems weird to me and may need updating for the 8+8 stuff.

I'm confused by the
  Either party MAY include extensions in the stream other than those
  negotiated, or those negotiated as "inactive", for example for the
  benefit of intermediate nodes.  Only extensions that appeared with an
  identifier in the valid range in SDP originated by the sender can be
  sent.

This seems somewhat contradictory - anyways, I don't think it would be acceptable to send things that were not negotiated in system using offer/answer.

I'm don't see how the mutual exclusive alternatives will work with offer answer. WHen sending the offer, the device will often receive RTP with the extensions before it received the answer to know what was accepted. Seems like using the cap-neg framework would be better for this.

I'm glad to have a phone call about any of this.

Ok - I had a read of this and went back and read all the list traffic on this one.

My take of this draft is that it does roughly 3 things ...

1) Allows an RTP packet to carry more than one extension

2) Changes the registration policy for registering new extension

3) Provides a SDP method to signal extension such that Tag/Length can be represented in one byte instead of several.

These are all fairly significant changes to RTP and SDP.

Solving 1 seems like a good goal and several people seem to agree with this. I've no problem with this. I am concerned on the 16 byte limitation but assuming the WG is ok with this, that is fine. The interaction with SRTP seem the opposite of what one would want - perhaps their is no way to avoid this. Either way this does need more explanation on why it is this way in the security section.

On the topic of 2 - today it would require a "Standards Action" to extend RTP this way - I don't have a problem with relaxing that to "IETF Consensus" with an IANA registry for the identifiers and pointer to the specification. I would not be keen on something more like "Hierarchical allocation"  - my issue with this is that developers have no hope of even finding out what data may be in the RTP packet and I don't see significant support for this change to RTP. The AVT WG has continually insisted that changes to RTP be reviewed in that WG and I view them unlikely to change this point of view. My recommendation here is to either make no change and stay with "Standards Action" or a minimal relaxation to "IETF Consensus".

On topic 3 - I think the AVT parts of this document have had a lot more review than the MMUSIC parts. I am concerned here about the size of the SDP if we use URN as the identifiers. Depending on how we resolve #2, I think just normal fixed names out of an IANA registry would be adequate here.

I will note that as far as I can tell none of this work has a milestone in either AVT or MMUSIC. Given the late stage of this and that it has been discussed in the AVT WG I'm not exactly sure what to do about it but if we can get something that does not have objections it will be a lot easier to move forward with this simple as an AD sponsored document.

So what I would like to do on this is update it along the lines of what is discussed here and get it to a place where the folks on this email thread are comfortable with it then I will resolve with the mmusic and avt chairs how we intend to move it forward from an exact process point of view but no matter what we do, I want to send if for WGLC in mmusic.

Cullen

PS - Dave - I am totally aware of how long and frustrating a document this has been and my desire is to move it forward in the least frustrating way possible (though it will be frustrating :-) Glad to talk about any of this on the phone - my mobile is 408 421 9990.

---------

Some small issues. It looks like some of the comments and thread with Ron and Dave and others on the list did not really conclude or may not have gotten resolved in the document.

The document says the URI must be dereferenceable but URNs are typically not.

The ABNF needs to slot into the SDP BNF. I can help people fix the BNF if you want.

PROTO Write-up

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

  Tom Taylor

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

  Who is the Responsible Area Director?

    Cullen Jennings

  Is an IANA expert needed?

    No.

  (end)