Subject: [Gen-art] Re: REVIEW: draft-ietf-avt-rfc2833bis-13.txt

From: "Tom-PT Taylor" <[email-masked]>
Date: Mon, 05 Jun 2006 10:53:16 -0400

Please see my responses below. I have made a number of changes based on 
your review. The document is better for it.

Michael A. Patton wrote:
> Attached is my review of the specified document, submitted as part of
> the Gen-ART process.  For background on Gen-ART, please see the FAQ at
> <http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
> 
> Document Tag: draft-ietf-avt-rfc2833bis-13.txt
> Document Title: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
> Intended Status: Proposed Standard
> Shepherding AD: Cullen Jennings
> Review Trigger: Telechat
> 
> To the Author/Editor: Please wait for direction from your document
> shepherd or AD before posting a new version of the draft.
> 
> 
> ----------------  Begin review  ----------------
> 
> Summary: This draft is basically ready for publication, but has nits that
> 	should be fixed before publication.
> 
> In short, my concerns are over the IANA considerations not being
> complete enough and an unlikely implementation choice not covered in
> the Security Considerations.  Since there should be experts in those
> specific areas also reviewing the document, their decisions on the
> points I raise should be considered final.
> 
> 
> Major concerns
> --------------
> 
> In the Abstract, we have "The remainder of the event codes defined in
> RFC 2833 are deprecated."  However, I don't actually see that in the
> document.  I would expect to see the IANA Considerations list the
> deprecated codes, so that the initial content of the registry marks
> them to avoid reuse.  Later, I do note that these _are_ given in
> Appendix A.  Shouldn't these be included in the IANA Considerations so
> that IANA doesn't miss them?
> 
[PTT]  I've added a list of codes reserved for the data and 
channel-associated signalling documents to the IANA Considerations 
section in 2833bis, and modified the language in the appendix. A 
qualification here: we have assumed that no one ever implemented the 
retired codes. This was rather clear in at least one case, simply 
because the old assignment had an error that would have made it 
unimplementable. We asked on the list before making the changes, of 
course. Some of the codes have actually been reassigned to other uses. 
The others are considered available for assignment as required.
> 
> Minor comments
> --------------
> 
> I'm not sure I believe the last paragraph of the Security
> Considerations.  Depending on the particular end system implementation
> of tone generation (if generated, say, in software rather than with
> hardware), I could see some substantial computational demand for
> particular frequencies and/or proportional to duration.  In that case,
> insertion of chosen packets could have a significant impact.  However,
> I rate this as "minor" because I believe that reasonable engineering
> will probably rule out such implementations for other reasons.
> However, it might be good to mention in the Security Considerations
> that security also indicates robust, low overhead tone generation.
> 
[PTT] Added the words "Provided that gateway design includes robust, low 
overhead tone generation, ..." at the start of the sentence.
> 
> ----------------------------------------------------------------
>    The following editorial issues are noted for the convenience
>    of possible copy editors but are not part of the technical review.
> 
> Clarity
> -------
> 
> Near the end of Section 1.2 I'd suggest changing "changes from [12]"
> to "changes from RFC2833 [12]" which I think makes it clearer, because
> the reference will be meaningful to informed observers (or those woh
> paid attention to the Abstract).
> 
[PTT] Done.

> When I hit Section 1.4, where it starts "Three methods, two of which
> are defined ..." left me wanting an explanation for the difference.  I
> realize that this is just a leadin to the list that follows and
> illuminates the issue, but at the point of that statement it's a
> little disconcerting.  I'd suggest that mentioning the upcoming detail
> with a forward mention will help.  Perhaps replacing the first
> paragraph of 1.4 with something like this:
> 
>    This document provides the means for in-band transport over the
>    Internet of two broad classes of signalling information: in-band
>    tones or tone sequences, and signals sent out-of-band in the PSTN.
>    Listed below are the three methods available for carrying tone
>    signals over RTP.  Two of these are defined by this document, while
>    the third is defined elsewhere.  All three are available for
>    carrying tone signals; only one of them can be used to carry
>    out-of-band PSTN signals.  Depending on the application, it may be
>    desirable to carry the signalling information in more than one form
>    at once.
> 
[PTT] Made changes in the spirit of this proposal. Modified the 
introductory paragraph just cited and also added a sentence or two for 
each of the listed methods.

> In 2.4.1 the <list of values> is explicitly allowed to be unordered.
> I assume that also applies in 2.4.  It should probably be mentioned
> there, and by extension in 7.1.1 as well.  None of the three places
> mentions what to do with overlapping ranges.  Are they disallowed or
> allowed and if allowed, what does it mean?  Either they should be
> explicitly disallowed (I don't expect any implementation to ever
> need to generate them), or specify what to do with them (I expect
> "union" is the right operator).
> 
[PTT] Rewrote the applicable paragraph of 2.4 as follows, and copied it 
to the media type registration:

"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."

Shortened the paragraph in 2.4.1 to:

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

> In section 4.1 in the discussion of Modulation Freqs. there's an aside
> at the end that seems wrong to me and is completely irrelevant.  Those
> frequencies are unrelated to any power grid that I know of, but are
> obviously simple integer fractions of 100 Hz (the only integers
> between 1 and 6 that produce fractions when divided into 100 are 3 and
> 6, which result in those two numbers) which may have been chosen
> because integer frequency division is easier to build simple circuits
> for.  But that's all completely irrelevant, you should just drop the
> whole parenthetical comment.
> 
[PTT] Dropped as suggested.
> 
> Typos
> -----
> 
> In Section 7: "telephone- event" => "telephone-event"
> 
> 
[PTT] Done.

_______________________________________________
Gen-art mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/gen-art

---

From: "Michael A. Patton" <[email-masked]>
Date: Wed, 7 Jun 2006 22:49:42 -0400 (EDT)

Date: Mon, 05 Jun 2006 10:53:16 -0400
   From: "Tom-PT Taylor" <[email-masked]>

Thanks.  That's one of the goals of GenART, to improve readability...

   retired codes.

It's not really possible to know that there were absolutely no
implementations.  I know in the DNS we made that assumption at one
point and when the new use for an old code was well deployed, we
finally ran into the one case where it had...and the appearance of the
new use made a widely deployed appliance (with ROM implementation)
malfunction, leaving us with a very hard choice.  It's from that
experience that I recommend against ever re-using a code, even if
every participant in the WG "knows" that they were never implemented.
If the code space is small enough that codes will eventually be
reused, the obsolete code points should so be marked and reuse should
be delayed as long as possible.

   This was rather clear in at least one case, simply because the old
   assignment had an error that would have made it unimplementable.

Just because the spec was broken doesn't mean that there wasn't some
engineer somewhere who was forced to include it by clueless management
and so he or she just did something...  I have a number of good
stories about this, including the engineer whose management insisted
that every TELNET option be implemented, including the one byte code
with value 256!

   We asked on the list before making the changes, of course.

And, of course, anyone who would implement the obviously broken codes
would be someone who isn't involved and therefore not on the list.

   Some of the codes have actually been reassigned to other uses. 
   The others are considered available for assignment as required.

I'll reiterate that I think it's extremely bad practice to reuse
codepoints, no matter how certain you are that the old value was never
used.  The Internet is a really big place and someone somewhere may
well have used it and not told you.  When that use comes out several
years from now and things start breaking, it will be very hard to
fix.  It's much easier to just write off the codepoint in nearly every
case.

That's sufficient.  If there was more time, I might try coming up with
a wording that makes it clearer.  But, I don't suppose anyone will
actually do the silly thing, so it doesn't need much emphasis.

   > When I hit Section 1.4, ...  Perhaps replacing the first
   >    This document provides ...

Good, I actually like your version even better...

New versions of 2.4 and 2.4.1 address my concerns.  You didn't mention
7.1.1, but a glance at the new draft shows it was fixed as well.

	-MAP

---

From: "Michael A. Patton" <[email-masked]>
Date: Wed, 7 Jun 2006 23:01:13 -0400 (EDT)

Document Tag: draft-ietf-avt-rfc2833bis-14.txt
Document Title: RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals
Intended Status: Proposed Standard
Shepherding AD: Cullen Jennings
Review Trigger: Telechat

This is an updated review based on the revisions in the new draft.

----------------  Begin review  ----------------

Summary: This draft is basically ready for publication, but has one
	 aspect that still concerns me a little.

All of the points in my earlier review have been addressed to my
satisfaction, except for the qustion of reuse of code points.  From my
experience, code point reuse is a recipe for interoperability problems
in the future.  However, if the authors and the WG feel strongly about
this, it's probably not worth pursuing further.  I just note my
concern for the record.

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 08 Jun 2006 11:16:05 -0400

I'm adding the AVT WG to this message to get people's comments there. 
I've reset the subject line. In summary, Michael warns that we will live 
to regret reassigning some of the event codes. We should either retire 
the unused 2833 event codes permanently or at least make them the last 
to be reassigned.

So the question to the list is whether we are committed to the new code 
assignments already, or whether we can reconsider before the IESG gives 
its final approval.

To give an idea of the number of changes that would be required to carry 
this out:

In 2833bis:

Change the IANA Considerations section to reserve the following code 
ranges against reassignment until all others are exhausted: 16, 41-48, 
64-89, 96-112, 138-143 (some ambiguity), 160-167, 170-173. With the 
further changes described below, this will leave the following ranges 
free for immediate use: 17-22, 50-51, 90-95, 113-120, 169, and 206-255. 
It also leaves all of the deprecated 2833 events easily revivable if 
someone wants to write an RFC to bring them back to life.

In 2833bisdata:

We changed the meaning of some of the V.8bis signals, so we should 
probably assign new codes to them if we are being careful. This applies 
to CRdSeg, CReSeg, MRdSeg, and MReSeg. Say that these would get the 
currently unassigned codes 23, 24, 25, and 26.

New codes V8bISeg, V8bRSeg, V32AC, V21L300, and V21H300 use codes that 
RFC 2833 assigned to line events. Give them codes 27, 28, 29, 30, and 31 
instead.

In 2833biscas:

Events 138-142 may or may not have been redefined -- it's hard to know 
because the old events had non-standard designations and it's hard to 
interpret the assignment of "MF S1 ... S3" into the two codes 142-143. 
So for safety's sake, reassign as follows:
MF Code 11 or KP3P/ST3P = 123
MF KP or KP1            = 124
MF KP2 or KP2P/ST2P     = 125
MF ST                   = 126
MF Code 12 or KP'/STP   = 127

The 16 ABCD events were never assigned to specific bit configurations in 
RFC 2833, but my research suggested that if they were ever used, the 
assignment was as we have it now. So I think we're safe in leaving those 
codes unchanged.

RFC 2833 assigned five different codes to continuity testing. I boiled 
these down to two and arbitrarily put them together (codes 167, 168) 
without matching the old semantics. Because the frequencies used in the 
RFC 2833 descriptions do not match those used in the standards cited in 
2833biscas, it seems best to assign new codes:
Continuity check-tone   = 121
Continuity verify-tone  = 122

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 08 Jun 2006 13:47:31 -0400

I'm resending this because it didn't seem to make it out the first time. 
My apologies if you do get it twice.

In 2833bis:

In 2833bisdata:

In 2833biscas:

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 15 Jun 2006 18:36:59 -0400

I have had no comments on this topic from the list, but I have had a 
private communication expressing interest in using some of the 
deprecated RFC 2833 telephone line events. Because of that and because I 
agree with Michael it's the right thing to do, I will make the indicated 
changes. For the event codes corresponding to deprecated events, the 
IANA instructions will be that they can be assigned to their original 
RFC 2833 events if a specification revives them, or otherwise may be 
assigned only if all other codes have been used up. It will be up to the 
reviewing expert to recommend what codes should be assigned.

This resubmission will, I believe, clear all IETF Last Call comments and 
outstanding IESG Discusses.

Tom-PT Taylor wrote:
>>    Please see my responses below. I have made a number of changes 
>> based on    your review. The document is better for it.
>>
>>    [PTT] Added the words "Provided that gateway design includes 
>> robust, low    overhead tone generation, ..." at the start of the 
>> sentence.
>>
>>    >    [PTT] Rewrote the applicable paragraph of 2.4 as follows, and 
>> copied it    to the media type registration:
>>
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt
> 
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 15 Jun 2006 20:45:02 -0400

I have submitted updated documents 2833bis-15 and 2833bisdata-08. I 
believe, as I stated before, that this clears all Discuss and IETF Last 
Call comments.

Changes in 2833bis:
====================

Changed abstract to say this about the deprecated RFC 2833 event codes:

   "The remainder of the event codes defined in RFC 2833 are
    conditionally reserved in case other documents revive their use.  See
    Section 7 and Appendix A for details."

Changed the last part of the second paragraph of section 1.2 to say:

   "Appendix A describes the changes from RFC 2833 [12] and in particular
    indicates the disposition of the event codes defined in [12]."

In section 7 "IANA Considerations", added a paragraph to the expert 
reviewer's duties as follows:

   "The expert is further responsible for providing guidance on the
    allocation of event codes to the proposed events.  Specifically, the
    expert must indicate whether the event appears to be the same as one
    defined in RFC 2833 but not specified in any new document.  In this
    case the event code specified in RFC 2833 for that event SHOULD be
    assigned to the proposed event.  Otherwise event codes MUST be
    assigned from the set of available event codes listed below.  If this
    set is exhausted, the criterion for assignment from the reserved set
    of event codes is to first assign those that appear to have the
    lowest probability of being revived in their RFC 2833 meaning in a
    new specification."

Changed the description of available and reserved codes in section 7 to 
read:

   "Legal event codes range from 0 to 255.  The initial registry content
    is shown in Table 7, and consists of the sixteen events defined in
    Section 3 of this document.  The remaining codes have the following
    disposition:

    o  codes 17-22, 50-51, 90-95, 113-120, 169, and 206-255 are available
       for assignment;

    o  codes 23-40, 49, and 52-63 are reserved for events defined in
       [16];

    o  codes 121-137 and 174-205 are reserved for for events defined in
       [17];

    o  codes 16, 41-48, 64-88, 96-112, 138-168, and 170-173 are reserved
       in the first instance for specifications reviving the
       corresponding RFC 2833 events, and in the second instance for
       general assignment after all other codes have been assigned."

Changed the last part of Appendix A in the spirit of the preceding 
changes. In particular, Table 8 now shows all of the codes for the 
deprecated RFC 2833 events as "Reserved".

Changes in 2833bisdata:
=======================

Changed the following event code assignments in the tables in which they 
appear:

CRdSeg   from 41 to 23
CReSeg   from 43 to 24
MRdSeg   from 46 to 25
MReSeg   from 48 to 26
V32AC    from 64 to 27
V8bISeg  from 65 to 28
V8bRSeg  from 66 to 29
V21L300  from 67 to 30
V21H300  from 68 to 31

Reordered the list in the IANA Considerations section accordingly.

Tom Taylor