* The shepherd writeup mentions IPR 2557 in relation to this draft. However, the IPR declaration is only associated with the original individual draft. The IPR declaration needs to be updated to refer to the WG draft. * The introduction says that this technique is needed to help monitor time & loss sensitive traffic. That would seem to indicate a need to associate these counters with individual flows. Has anyone done any calculations on how these counters will scale? Section 5 seems to indicate that there were only a few number of counters implemented via ACLs. * The draft sets out to develop this technique without augmenting packet formats. That makes the statement in section 3.1.1 about how to color packets is out of scope a bit disingenuous. I would have preferred a brief description of the few available options on coloring packets in this section. * The mention of maintaining timestamps for delay measurements is under-specified. Would the 32-bit NTP timestamp format be sufficient? The 64-bit NTP timestamp format? Guidance on how to carry out experimentation with this approach seems useful. Does the concept of adding timestamps per color block conflict with the first bullet of section 7 (only uses features already available on routers)? * If the above statement on per-flow counters is not true, can I not accomplish the same capability by harvesting ifMib stats per interface and compare xmit/recv/drop stats across the network? * The description of the Telecom Italia experiment references a 5-minute window per color. For time sensitive traffic like IPTV, how useful was the 5-minute reporting window? Were corrective actions taken prior to calls being handled by support? * The Telecom Italia experiment writeup does not mention how the counters were harvested from the routers. Were readily available tools used to do this?