Thank you for sending your comments, I have tried to make changes that incorporate comments from the various area reviews, and expect to shortly release an ID revision (12) that has these improvements. Details of the points addressed are below. Gorry --- Summary: I have some minor concerns about this document that I think should be resolved before publication. Major Issues: No major issues found. Minor Issues: Page 3, first paragraph: There are no citations to the claim that non-congestion-controlled traffic "can form a significant proportion of the total traffic traversing a link". Sure, video is a major part of Internet traffic these days, but much Internet video is dynamically adaptive. One or more citations would be useful. -GF: Understood, but I want to consult on the most suitable reference. Section 4: There are so many issues that they should be numbered, so that they can be referred to individually (from another document, for example). -GF: Numbered. Page 11: In my opinion, the second and third requirements on this page should be "MUST"s rather than "SHOULD"s. -GF: Changed: A Circuit Breaker MUST be constructed so that it does not trigger under light or intermittent congestion. -GF: I did not change: ?The default response to a trigger SHOULD disable all traffic that contributed to congestion.? - I query if it really important to dictate the ?default? MUST? Page 12, discussion of "In-Band" near the bottom of the page: This paragraph implies that an in-band control method will always provide fate-sharing of the control and regular traffic. It may provide fate-sharing, but that is by no means assured. For example, the network may be using ECMP, or traffic tunnels for data but not control traffic. -GF: Added: ?This fate-sharing property is weaker when some or all of the measured traffic is sent using a path that differs from the path taken by the control traffic (e.g., where traffic follows a different path de to use of equal-cost multipath routing, traffic engineering, or tunnels for specific types of traffic). ? Section 5: I'm not sure why Section 5 is a separate section, and not integrated into Section 3 as new subsections, which I think would be an improvement. -GF: I had contemplated this move, and have no preference. In the new revision I moved the text to section 3. Page 13, first paragraph: "presented in figure 2" -> "presented in figures 1 and 2?. -GF: done. Page 19, fourth paragraph: This paragraph states that "IP-based traffic is generally assumed to be congestion-controlled". This is true for TCP-based traffic, but I would not make such an assumption for all IP-based traffic. - GF: Rephrased a little, although the present protocol assumption is that UDP-based traffic needs to provide some form of congestion response, the reality is that this is not always the case. Nits: The abbreviation "CB" is defined early in the document, but is hardly if ever used thereafter, rather "Circuit Breaker" is almost always spelled out. It may be useful to actually use the abbreviation. -GF: done within the normative section, where the term is used a lot. Page 3, first paragraph, fifth line, "connection" -> "connections". -GF: done. Figure 1: Move the vertical line between the "Measure" and "Trigger" boxes one space to the right. -GF: Thanks for spotting, done. Page 10, fourth paragraph: "If necessary, MAY combine" -> "If necessary, a CB MAY combine". -GF: done. Page 11, fifth paragraph: "needs to be" -> "MUST" -GF: done. Page 12, second paragraph: There are two separate references to Section 8. One combined reference should be sufficient. -GF: done. Page 12, second to last paragraph: "in-Band" should have the "i" capitalized. -GF: done. Page 15, last paragraph: "tranport" -> "transport" -GF: done. Page 17, fifth paragraph: "Pseudo Wire" -> "PW" -GF: done. Regards, Andy