RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals
draft-ietf-avt-rfc2833bis-15

[Ballot comment]
> If the specification is created by an outside body, the IETF-appointed expert must ...

Trying to understand if the rules are clear enough to be followed.
What's "an outside body"? Does it cover only other SDOs, companies,
persons? What about individual submissions through the RFC Editor?
And wouldn't the same checks need to be done even if the document
was an IETF product?

I'd suggest dropping the "if" part and just saying what the
expert needs to do.

Nits (I get these from a script that I run for all documents):

s/occurence/occurrence/
s/occuring/occurring/
two ways to write echo canceller / cancellor
s/renable/re-enable/

[Ballot comment]
> If the specification is created by an outside body, the IETF-appointed expert must ...

Trying to understand if the rules are clear enough to be followed.
What's "an outside body"? Does it cover only other SDOs, companies,
persons? What about individual submissions through the RFC Editor?
And wouldn't the same checks need to be done even if the document
was an IETF product?

I'd suggest dropping the "if" part and just saying what the
expert needs to do.

[Ballot discuss]
I question whether the requirement that all implementations of the
telephone event codes must implement SRTP is reasonable.  Is the
vendor community actually behind this requirement?

I also question whether this requirement will actually give us
interoperability without a mandatory-to-implement key management solution .

If this is really going to be implemented and will add real-world
security, I'm all for it.  If it is a requirement that is added but
that will not be implemented in practice, I would rather see us
document the vulnerability and publish a spec that matches
implementation reality.  There are cases where it is appropriate for
specs to lead implementations in security requirements; I'm nott sure
this is one of them.  But again, if there is strong support for this
requirement I can be convinced to withdraw the discuss.

[Ballot comment]
1. idnits complains wrt. 2119 boilerplate on both documents. The reason seems to be that the recommended 2119 bolerplate text is not reproduced ad-literam.

2. The abbreviations list in draft-ietf-avt-rfc2833bisdata-06.txt is not complete. PBX and MIME are being used in the document and not included in the list

[Ballot discuss]
draft-ietf-avt-rfc2833bis-13:
 
  The title page header and the Introduction need to mention that
  this document obsoletes RFC 2833.

  The security considerations section says:
  >
  > Because the data compression used with this payload format is applied
  > end-to-end, encryption may be performed after compression so there is
  > no conflict between the two operations.
  >
  Encryption MUST be performed after compression.  Compression after
  encryption will result in very poor compression performance indeed.

  draft-ietf-avt-rfc2833bisdata-06:

  The title page header needs to indicate that this document updates
  rfc2833bis.

[Ballot comment]
INTRODUCTION, para. 15:

>    Companion documents add event codes to this registry relating to
>    modem, fax, text telephony, and channel-associated signalling events.
>    The remainder of the event codes defined in RFC 2833 are deprecated.

        What are the companion documents? I'm guessing at least
        draft-ietf-avt-rfc2833bisdata-06, which isn't cited. Are there others?
        Without this information, it's hard to know what the "remainder of the
        event codes defined in RFC 2833" that are being deprecated actually are.

IANA Last Call Comments:


Upon approval of this document the IANA will update the references to be this document
for the following:

MIME Media types
audio/telephone-event
audio/tone
http://www.iana.org/assignments/media-types/audio/

RTP Payloads
telephone-event
tone
http://www.iana.org/assignments/rtp-parameters


IANA will also create a new registry for the audio/telephone-event types with the initial
assignments from section 7 of the document. Registration procedures will be Specification
Required and Expert Review.

An expert will need to be appointed.

Should this new registry be placed at the following location?:
http://www.iana.org/assignments/media-type-sub-parameters

Do we understand the IANA Actions correctly?

PROTO write up

Date:    Thu, 01 Dec 2005 15:14:20 +0100
From:    Magnus Westerlund
To:      IESG Secretary
cc:      Allison Mankin ,
Colin Perkins
Subject: Request to publish: draft-ietf-avt-rfc2833bis and draft-ietf-avt-rfc28
  33bisdata

Hi,

The AVT WG would like to request that draft-ietf-avt-rfc2833bis are
published as proposed standards which obsolete RFC 2833. AVT also
request that draft-ietf-avt-rfc2833bisdata is published as proposed
standard. I, Magnus Westerlund will be WG shepherd of these documents.
The documents belong together and should be published as consecutively
numbered RFC. They have also gone through WG last call together,
therefore only a single writeup will be provided.


    1.a) Have the chairs personally reviewed this version of the Internet
        Draft (ID), and in particular, do they believe this ID is ready
        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?

Yes,

    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.)?

No

    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.  In any event, if your issues have been discussed in the WG
        and the WG has indicated it that it still wishes to advance the
        document, detail those concerns in the write-up.

No

    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?

Solid consensus


    1.f) Has anyone threatened an appeal or otherwise indicated extreme
        discontent?  If so, please summarise the areas of conflict in
        separate email to the Responsible Area Director.

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

    1.h) Is the document split into normative and informative references?
        Are there normative references to IDs, where the IDs are not
        also ready for advancement or are otherwise in an unclear state?
        (note here that 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.)

Yes

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

Technical Summary:

draft-ietf-avt-rfc2833bis:

This document defines the RTP Payload format for telephony events over
RTP and the usage of DTMF in this payload format. It also establish a
registry in which further telephony events using this payload format may
be registered in. The document also defines an RTP Payload format for
tones used in telephony systems. The payload format is capable of
describing single, multiple or modulated tones.

draft-ietf-avt-rfc2833bisdata:

This document defines 31 additional events to be used with the RTP
payload format for telephony events defined in
draft-ietf-avt-rfc2833bis. The defined event cover the usage with a
number of ITU specifications such as V.8, V.8 bis, V.21, V.25,
V.32/V.32bis, and T.30.

Working Group Summary:

There is consensus in the WG to publish these documents.

Protocol Quality:

These documents are updates of RFC 2833 which is obsoleted. The
implementation experience for RFC 2833 has been taken into account in
these updates. The documents have been reviewed by both IETF and ITU-T
Study Group 16.

Asked for a reviewer from the SIPPING or IPTEL world more than a
week ago - deadline for review Jan 19.  But no reviewer has
said they are reviewing.  Dean had said he would ask Jiri Kuthan
and Jonathan Rosenberg said he is looking at the reviewer question.
Perhaps will un-delegate the invitation to reviewers and ask
for URGENT review myself now.