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?
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 <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).
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"
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
