I am the assigned Gen-ART reviewer for draft-ietf-pwe3-tdmoip-05.txt.
For background on Gen-ART, please see the FAQ at
<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>.
(Minor note: I am copying only the first of the authors as otherwise
filters may complain about the number of adressees. I will send a
separate copy to the other authors, as I expect the copy to the WG
list to be delayed.)
Please resolve these comments along with any other
Last Call comments you may receive.
This document is nearly ready for publication as an RFC. There are
some items which warrant attention.
Question: Section 3 appears to define specific bits on the wire. It
defines the order of RTP vs other headers, and defines the setting of
specific bits in the RTP header. Later sections define wire formats
for other headers. Given such definitions, I would expect the
document to be either Experimental or Standards track, rather than
Informational. I presume that this has been addressed, but since the
tracker does not show anything, I am raising the question.
(I suspect that the WGs view is that the formats are all normatively
defined elsewhere, and are just being collected here for
reference. Collecting packet formats by value, rather than by
reference, is nice for books, but not usually a good idea for
RFCs. And at least the RTP header order and header field settings
appear to be defined normatively here.)
Further, the presence of distinctly marked "informative" appendix
indicates that the document is defining expected behavior and is
itself more than informational.
moderate: The introduction does not tell me what this document is
about. A few sentences along the lines of the technical summary in
the tracker would help.
moderate: The paragraph on SAToP in section 2.seems to characterize a
loss rate of one fifth of one percent as an "extremely reliable and
overprovisioned PSN." While I do not want to get in to an argument
about what is acceptable, it is to be noted that even TCP will have
performance problems with a link with a 0.2% loss rate. ISPs with
loss rates much lower than that are still not usually referred to as
"extremely reliable." I would recommend simply removing the sentence.
moderate: following the discussion of severly errored seconds (in the
SAToP context in section 2), there is text indicating that the use of
structure aware transport may allow one "to effectively conceal
packet loss events." This concealement is not actually described as
a feature of the protocol anywhere else. The erorr handling in
section 6 quite nicely describes what to do with lost packets, and it
is not to conceal the error. It does generate the error indication
so errors are associated with the right place.
moderate: Is the entire control word description after figure 2
copied from RFC 4385, or does this text probide more specific
meanings / settings / usage in the structured TDM context? (I
suspect it is just a copy of 4385. If so, I would suggest a shorter
description, maybe just the field name, and text saying that one
should see 4385 for the full format. Copying text between RFCs is
not a good idea.) Whatever the case is, the text needs to be clear about it.
moderate: After reading section 5.3 several times, I am still left
guessing as to what the actual payload format will be when
transporting HDLC data using TDMoIP. I presume it is described here
somehwere, but I can't find it.
minor: The Introduction uses the abbreviation PSN without ever
expanding it. The first use should be "Packet Switch Network (PSN)"
minor: I find the characterization of UDP over IPv4 as being a
distinct type of packet switch network from L2TPv3 over IP an odd
distinction. They are different protocols (UDP vs L2TPv3), but they
are not different networks. This may be conventional usage in some
context, but is not a common IETF usage.
minor: The paragraph (3rd paragraph in section 2) defining the
number of 64Kbit channels carried in a T1 / E1, and the chunk size
for those channels appears to be too concise. A few more words would
clear up what number is the number of channels, and what number is
the chunk size used to carry a block for a single channel. As
written the reader must stop and study the text to figure out what
was intended.
minor: The first usage of "SAToP" (in section 2) should have the
acronym expanded. I should not have to go to the references to
determine the name of the protocol.
----
INT TDM over IP
draft-ietf-pwe3-tdmoip-05.txt
AD: Mark Townsley
Reviewer: Joel Halpern
_______________________________________________
Gen-art mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/gen-art
