Document: draft-ietf-avt-rfc2833bis-13.txt Reviewer: Michael A. Patton [MAP@MAP-NE.com] Review Date: Wednesday 5/24/2006 6:57 AM CST IESG Telechat Date: Thursday, 25 May 2006 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? 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. ---------------------------------------------------------------- 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). 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. In 2.4.1 the 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). 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. Typos ----- In Section 7: "telephone- event" => "telephone-event"