[AVTCORE] AD Evaluation of draft-ietf-avtcore-rtp-circuit-breakers-13

["Ben Campbell" <[e-mail]>]

Hi,

This is my AD Evaluation of draft-ietf-avtcore-rtp-circuit-breakers-13. 
While I do have some comments and questions, I don't think anything here 
needs to block IETF last call. Please address these along with any other 
last call feedback.

Thanks!

Ben.


Substantive
===========

-4, third paragraph, sentence starting with "This approach SHOULD NOT be 
used..."

Does this mean that, in addition to the fact that non-RTCP peers 
shouldn’t be on the network in the first place, a circuit-breaker 
implementation shouldn’t talk to them even if they are? That is, even 
if the peer has a "good reason" (in an RFC 2119 sense) to violate that 
SHOULD, circuit-breaker implementations should ostracize it? :-)

-4.2, last paragraph, sentence starting with "In this case"

Does this imply that the SHOULD only applies if the sender has reason to 
believe that the SR or RR packets will be too large? or should the 
sender always behave this way?

How does this relate to the guidance (MAY) in section 8?

- 4.3, 6th paragraph:"Implementations that desire this extra sensitivity 
MAY use the full TCP throughput equation in the RTP circuit breaker. "

Is there potential for the extra sensitivity to do harm (beyond the 
higher calculation complexity)?

-4.4, 2nd to last paragraph, last sentence:

Is there any potential guidance on reasonable lower limits to the time 
period considered "significant"?

- 12.2:

It seems like the following references might should be normative: 
I-D.ietf-tsvwg-circuit-breaker, RFC3168, RFC6679


Editorial
=========

- Abstract
s/"will deteriorate"/"will cause the deterioration of"
-- "This acts as a safety measure..."
What is the antecedent for “this”? Congestion control? The 
deterioration? (Also, this sentence contains a comma splice)

- 1:
A very short definition of what we mean by "circuit breaker" might be 
useful.

- 3:
It's a little odd to find 2119 keywords imbedded in term definitions. 
You might consider moving those to procedure sections. (OTOH, it may not 
be worth changing this late in the process.)

-4.2, last paragraph:
What would it even mean to maintain a timeout past the end of the 
related stream?

-4.3,

-- paragraph 6:
typo: s/throughout/throughput

-- paragraph 9: "MUST record the value of the fraction
    lost field in the report block"

Does this mean the field _from_ the report block? (That is, you aren't 
_writing_ the value in the report block?)

-9, last paragraph:

Is this paragraph really related to security? It sounds more like an 
operational consideration.