Original text:
2.3. <del> TBD: pros, cons, tradeoffs of caching designs at different locations within the network? Peak vs. average provisioning, and effects on peering point congestion under peak load? Provisioning issues for caching systems? </del>  2.4. 2.6. <del> The causes of unpredictable usage described in sec-unpredictable were </del>  more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns.

Reviewer comments:
This is against issue 13.
Do we need anything in here about cache footprint considerations with fragmented MP4 vs. older style ts segments in multiple formats? Could be done as a separate update, but it seems possibly relevant here.
Hearing no other objections, I'll merge this. I'll leave cache footprint fmp4 considerations as a possibility for future prs and resolve this.
NAME had what I think is an excellent suggestion of one line per sentence: URL I've seen other docs use one line per paragraph, which I attempted to use in a recent commit but I kind of hate. Regardless, we should make a whitespace-only pass through the doc and make it all the same. I vote for one line per sentence. (I assume this would not include text inside bullet points and tables--not sure if there's a section of a doc somewhere about the pros and cons of different approaches?)
I'm happy to make a formatting pass and check what kramdown, etc. does with it. Do we want to land the changes in URL first, or reformat first and rebase your PR?
I guess I'm voting for land the changes first and do a whitespace format when we won't have conflicts. Should be pretty quick, right?
(*note, there is another pull request also that would be affected if we do it now: URL )
Closing, don't need to fix this (not expecting many more PRs anyway).
Pulling the TBD out of the draft text and capturing it here instead. Suggestion from mic at IETF 106 (Dave Oran + Glenn Deen responding): Pre-placement for many use cases is useful--distinguish between live vs. cacheable. "People assume high-demand == live, but not always true" with popular netflix example. Pre-placement in caches can ameliorate high-bandwidth needs without having to use e.g. multicast. Explain where it's applicable and not, and what the constraints are. URL (This probably goes in the caching section as that's written.)
+Glenn's comment: also capture latency constraints as a usability/qos part for live+popular vs. pre-recorded and expected-popular.
I would like to think that PR 30 is a start here ...
was merged, but this issue wasn't closed. Closing now ...

Revised text:
2.3.  <ins> When demand for content is relatively predictable, and especially when that content is relatively static, caching content close to requesters, and pre-loading caches to respond quickly to initial requests, is often useful (for example, HTTP/1.1 caching is described in RFC7234).  This is subject to the usual considerations for caching - for example, how much data must be cached to make a significant difference to the requester, and how the benefits of caching and pre- loading caches balances against the costs of tracking "stale" content in caches and refreshing that content. It is worth noting that not all high-demand content is also "live" content.  One popular example is when popular streaming content can be staged close to a significant number of requesters, as can happen when a new episode of a popular show is released.  This content may be largely stable, so low-cost to maintain in multiple places throughout the Internet.  This can reduce demands for high end-to-end bandwidth without having to use mechanisms like multicast. Caching and pre-loading can also reduce exposure to peering point congestion, since less traffic crosses the peering point exchanges if the caches are placed in peer networks, and could be pre-loaded during off-peak hours, using "Lower-Effort Per-Hop Behavior (LE PHB) for Differentiated Services" RFC8622, "Low Extra Delay Background Transport (LEDBAT)" RFC6817, or similar mechanisms. All of this depends, of course, on the ability of a content provider to predict usage and provision bandwidth, caching, and other mechanisms to meet the needs of users.  In some cases (sec-predict), this is relatively routine, but in other cases, it is more difficult (sec-unpredict, sec-extreme). </ins> 2.4. 2.6.  <ins> The causes of unpredictable usage described in sec-unpredict were </ins> more or less the result of human choices, but we were reminded during a post-IETF 107 meeting that humans are not always in control, and forces of nature can cause enormous fluctuations in traffic patterns.