Media Type Registration of RTP Payload Formats
draft-ietf-avt-rfc3555bis-05

IANA Last Call Comment:

This document updates the registration requirments for registry for RTP
http://www.iana.org/assignments/rtp-parameters

When this document is approved IANA will change the registry to reflect that
the registration procedures must be in acordance with this document.

We understand this to be the only IANA actions for this document.

[Ballot comment]
Inconsistent use of RFC2119 terms in draft-ietf-avt-rfc3555bis-04 in
  the beginning of Section 2, i.e., before Section 2.1. There are many
  lowercase instances of these terms that should be uppercased IMO. I
  included one example below, there are several other cases.

Section 2., paragraph 2:
>      Required parameters
>          If the payload format does not have a fixed RTP timestamp
>          clock rate, then a "rate" parameter is required to specify the
>          RTP timestamp clock rate.  A particular payload format may
>          have additional required parameters.

  s/required/REQUIRED/

[Ballot discuss]
rfc3555bis-04:

  It looks like the security considerations section should either cite
  RFC 4288 section 4.6 as a detailed description of the security
  analysis that needs to be done for each registration or, even better,
  include the text from RFC 4288.

  rfc3555bis-part2-01:

  This document purports to update a number of existing registrations 
  without making technical changes to the registrations.  Yet, it does
  not appear that a suitable security analysis (see section 4.6 of
  RFC 4288) has been done for each of these registrations.  None of the
  registrations state whether they employ "active content".

  There is an inappropriate circularity in the security considerations.
  Section 4 says:

    "The media type registrations contained in this document do not by
    themselves impose security risks, but some may state security
    considerations specific to the particular registration."

  However, every registration in the document simply points to Section 4.
  Only one (Section 2.1.15) offers any more detail, saying:

    "Audio data is believed to offer no security risks."

  At a minimum, each registration out to indicate whether it includes
  active content.  A more detailed analysis is desirable, but it may not
  be easy to do for these reregistrations.

PROTO Write-up

1.a) Have the chairs personally reviewed this version of the ID and
do they believe this ID is sufficiently baked to forward to the
IESG for publication?

Yes.

1.b) Has the document had adequate review from both key WG members
and key non-WG members? Do you have any concerns about the
depth or breadth of the reviews that have been performed?

The drafts have had adequate review.

1.c) Do you have concerns that the document needs more review from a
particular (broader) perspective (e.g., security, operational
complexity, someone familiar with AAA, etc.)?

I have no concerns.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it, etc. If your issues have been discussed in the WG and the
WG has indicated it wishes to advance the document anyway, note
if you continue to have concerns.

I have no concerns.

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?

These drafts document existing practice. There is strong consensus.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise what are they upset about.

No.

1.g) Have the chairs verified that the document adheres to _all_ of
the ID nits? (see http://www.ietf.org/ID-Checklist.html).

Yes. The idnits tool complains that the RFC 3978 Section 5.5
Disclaimer is missing from 3555bis-04, but that appears to be a bug
in idnits (which I have reported).

1.h) Does the document a) split references into normative/
informative, and b) are there normative references to IDs,
where
the IDs are not also ready for advancement or are otherwise in
an unclear state? (Note: the RFC editor will not publish an RFC
with normative references to IDs, it will delay publication
until all such IDs are also ready for publication as RFCs.)

References have been split. The only normative references to I-Ds are
to sdp-new, which is in AUTH48 currently.

1.i) For Standards Track and BCP documents, the IESG approval
announcement includes a writeup section with the following
sections:


* Technical Summary

These drafts specify the procedure to register RTP payload formats
as audio, video or other media subtype names. This is useful in a
text-based format description or control protocol to identify the
type of an RTP transmission. Media type registrations for the RTP
payload formats defined in the RTP Profile for Audio and Video
Conferences are also included. Some of these may also be used for
transfer modes other than RTP.

* Working Group Summary

These drafts update RFC 3555 to document existing practice with
media type registration for RTP payload formats, as has evolved
in the time since RFC 3555 was published, and taking account of
the updated media type registration rules defined in RFC 4288.
They also update a number of media type registrations, to match
the current template.

* Protocol Quality

These drafts were reviewed for the IESG by Magnus Westerlund and
Colin Perkins, and update RFC 3555 to match existing practice.
Review on the ietf-types list was solicited in May 2006, and there
were no objections.