[AVT] Changes in draft-ietf-avt-rfc2833bis-14.txt

Draft-ietf-avt-rfc2833bis has been resubmitted with the addition of 
changes arising during the IETF Last Call, Gen-Art review, and IESG 
review process. The following is a detailed list of the changes from 
draft-ietf-avt-rfc2833bis-13.txt.

1. Added "Obsoletes: 2833 (if approved)" in document header.

2. Modified the Abstract, by replacing the word "deprecated" at the end 
of the third paragraph with "available for reassignment", and adding 
more text. The complete insertion is as follows:

"available
    for reassignment.  See Appendix A for details, which include
    reassignment of some event codes that apparently had no
    implementation in the past and duplicated the meaning of other codes
    that have been retained.

    [RFC Editor: please change the Informative reference following RFC
    4103 to the RFC number assigned to
    draft-ietf-avt-rfc2833bisdata-07.txt, one of the "companion
    documents" referred to above.]"

3. In the terminology section, deleted the clause "and indicate 
requirement levels for compliant implementations" from the first 
paragraph to bring it into exact alignment with RFC 2119. Also added a 
definition for "PBX".

4. In section 1.2, second-last line, added "RFC 2833" in front of 
"[12]", the corresponding reference.

5. In section 1.4, made the following changes for greater clarity:

(a) In the first paragraph, replaced the sentence:

"Three methods, two of which are defined by this document, are available 
for carrying tone signals; only one of the three can be used to carry 
out-of-band PSTN signals."

with the sentence:

"Tone signals can be carried using any of the three methods listed below.

(b) Added the following sentence to the first list item:

"These methods are out of scope of the present document, but may be used 
along with the payload types defined here."

(c) Changed the first sentence of the third list item from:

"As a third option, a gateway can recognize the tones and translate them 
into a name, such as ringing or busy tone or DTMF digit '0' (Section 2)."

to:

"As a third option, a sending gateway can recognize tones such as 
ringing or busy tone or DTMF digit '0', and transmit a code which 
identifies them using the telephone-event payload defined in this 
document (Section 2)."

6. Replaced all occurrences of "MIME" with "media" or "media type" as 
required. This affected the second line of section 2.1, the section 
title and the first paragraph of section 2.4, section 2.4.1 (multiple 
instances), the third paragraph of 2.5.1.1, the first paragraph of 
section 4.3.3, the section title of section 4.3.4 and the first para of 
section 7.

7. To deal with a comment on the ordering of event codes in the "events" 
media type parameter, and the possibility of overlapping ranges, 
modified the second paragraph of section 2.4 as follows:

Old:

"  The "events" parameter lists the events supported by the
    implementation.  Events are listed as one or more comma-separated
    elements.  Each element can either be a single integer or an integer
    followed by a hyphen and a larger integer, representing a range of
    consecutive event codes.  No white space is allowed in the argument.
    The integers designate the event numbers supported by the
    implementation."

New:

"  The "events" parameter lists the events supported by the
    implementation.  Events are listed as one or more comma-separated
    elements.  Each element can either be a single integer providing the
    value of an event code or an integer followed by a hyphen and a
    larger integer, presenting a range of consecutive event code values.
    The list does not have to be sorted.  No white space is allowed in
    the argument.  The union of all of the individual event codes and
    event code ranges designates the complete set of event numbers
    supported by the implementation."

This paragraph also replaced the previous text describing the "events" 
parameter in section 7.1.1 (the media type registration).

Finally, the paragraph in section 2.4.1 following the line:
       a=fmtp:<format> <list of values>
was changed to the following:

"The list of values has the format and meaning described above."

8. In section 3.1, first paragraph, added "(Private branch telephone 
exchange)" after "PBX".

9. In section 4.1, bullet beginning "Modulation frequencies...", deleted 
the parenthetic comment:

"(These fractional frequencies appear to be derived from AC power grid 
frequencies.)"

10. Made several changes to the Security Considerations section.

Second para old:

    The telephony-event payload defined in this specification is highly
    compressed.  An interchange of just two bits can result in a major
    change in meaning as decoded at the receiver.  Thus the telephony-
    event payload type is in particular need of protection of integrity.

New:

    The telephony-event payload defined in this specification is highly
    compressed.  A change in value of just one bit can result in a major
    change in meaning as decoded at the receiver.  Thus message integrity
    MUST be provided for the telephony-event payload type.

In the third para, made support of SRTP a "SHOULD".

Added a second indented item following this paragraph, reading:

"     In some deployments it may be preferable to use other means to
       provide protection equivalent to that provided by SRTP."

Deleted the paragraph talking about the order of compression versus 
encryption, since we are not really talking about compression in the 
first place, and encryption always has to follow compression when the 
latter is used.

Added the phrase:
  "Provided that gateway design includes robust, low overhead tone 
generation,"
in front of the final paragraph.

11. In the second paragraph of section 7 (IANA Considerations), deleted 
the phrase:
"If the specification is created by an outside body,"
from the beginning of the last sentence before the bullets describing 
what the designated expert must consider.

12. Added the following to the paragraph of section 7 beginning: "Legal 
event codes ...":

"  Codes 32-41, 43, 46, 48-49, and 52-68
    are reserved for events defined in [16].  Codes 128-142, 144-159,
    167-168, and 174-205 are reserved for [17].  All remaining codes are
    available for assignment as required."

([16] refers to 2833bisdata, [17] refers to 2833biscas.)

13. Changed reference [16] (2833bisdata) from "Work in Progress" to "RFC 
yyyy". Unfortunately, failed to follow up with a note to the RFC Editor. 
If necessary, that can be fixed in AUTH48.

14. Made a slight change to two sentences in the middle of the final 
paragraph of Appendix A before the table. (The intervening sentence is 
unchanged.)

Old:

    Two companion documents describe
    events related to modems, fax, and text telephony [16] and to
    channel-associated telephony signalling [17]. ... The remaining
    events defined in RFC 2833 are deprecated
    because they do not appear to have been implemented, but the registry
    remains open should any of them be needed in the future.

New:

    Two companion documents [16] and
    [17] describe events related to modems, fax, and text telephony and
    to channel-associated telephony signalling respectively. ... The
    remaining events defined in RFC 2833
    are deprecated and their codes made available for reassignment
    because they do not appear to have been implemented, but the registry
    remains open should any of them be needed in the future.

Changes were made to Table 8 in line with this clarification.

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt