Apologies for the slightly late early review. Also, note: I'm not a YANG doctor, and don't play one on Youtube, so I assume the usage of netconf in this proposal is at the very worst unproblematic; I'm only looking at transport/CC relevant issues here.

This document still needs some work, but I assume the authors are aware of this as they're the ones who stuck the various TBDs in the text. :) That said, what's there is encouraging and I think this work is on the right track.

Open questions:

(1) This document maps its concepts incompletely to the terminology of RFC 8084, in a way that I found (as someone who also had to reread 8084 to complete this review) found confusing. Pointedly 8084 assumes a feedback loop where the egress meter (on the downstream end of a protected path) causes the ingress meter to trigger when the circuit breaker trips, while this document seems to assume that the control point is at the egress meter. I'm not actually certain whether this matters, since tripping downstream will eventually unload the upstream path. I also note that the authors note that other reviewers found the 8084 terminology confusing. It probably makes sense for this document to note explicitly that it is modifying the architectural assumptions in 8084 (replacing an "ingress meter" with an ingress rate declaration via netconf, and moving the control point forward).

(Thanks for section 1.3, by the way, it made this review *way* easier to jump into than would otherwise have been the case)

(2) Parallel to current discussions in SCONE, which is dealing with an adjacent problem (throughput guidance for unicast flows to avoid traffic shapers, which are their own kind of single-point circuit breaker), the choice of a timescale is important when defining a trigger function, and I expect the currently TBD section 2.3.1 will go into this in some detail when it is no longer TBD.