Draft: draft-ietf-pwe3-tdmoip-05.txt Reviewer: Joel M. Halpern [joel@stevecrocker.com] Review Date: Sunday 9/3/2006 7:48 PM IETF LC Date: 9/4/2006 Summary: 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.