Change:
restart can also be disabled, for example as described in OReilly- HPBN. <del> 4.4.2. </del> <ins> 4.5.2. </ins> In the event of a lost packet on a TCP connection with SACK support (a common case for segmented delivery in practice), loss of a packet

Discussion:
Sorry for the delay on this! Here's a rebased copy of URL we can work from if there's still in adding this section.
NAME my apologies on this - I told NAME and NAME I'd work on this, just before coming down with the plague. Thank you for rebasing the proposal, and yes, we are still interested in adding this section (speaking for the editors, not for the working group). We're in the I-D submission blackout zone now, so let's continue discussion, and we can submit something after IETF 111 opens back up.
I had a few comments in the prior pr, but I'm not sure I quite got across what I meant. I drafted an alternative proposal as a quick straw man example of what I meant, maybe we could do some merger that includes some content along these lines? I was also thinking to put it in the ABR section instead of the bandwidth section, probably. Not sure if this goes too far?
NAME now that we're using Github Actions, it looks like "First-time contributors need a maintainer to approve running workflows", and we actually caught problems when using CircleCI, so we probably want to do that, don't we? If so - who are the maintainers who should be approving this? I'm guessing that this has something to do with URL, but of course, I'm not sure ...
NAME the current slide deck for next week's MOPS session has the issue associated with this PR as our last blocking issue before WGLC, so if we (you, me, NAME NAME can close on this before the meeting, we can update the slide deck and tell the WG that we're just cleaning up for a couple of weeks after IETF 111, and then going forward. Does that make sense to you?
NAME That makes sense to me! I will, unfortunately, not be able to attend IETF 111 due to a previously scheduled commitment, but I will attempt to integrate NAME feedback here beforehand so you can bring that message to the WG session.
Sorry for the late push! We've had even less Internet connectivity than I had expected. Let me know what you think of this synthesis, and whether a section on segmentation and keyframes is worth including. Thanks!

NAME I agree that this probably needs another editorial pass to deduplicate some of the merged text and tighten up the style, but I've tried to clean up all the other loose ends so you can merge this if/when you're ready. Let me know if you need me to make any additional changes in this PR. Thanks!
Thanks Mike, this is fantastic. Much obliged. We'll discuss in the next editor's session, and likely at least one of us will make an editorial pass before long, I expect. (NAME I believe you're still the owner--want to take a final pass? I think another set of eyes would be invaluable here, and your judgement on these matters is impeccable, IMHO...)
NAME has questionable judgement about "impeccable taste", but I should be able to do that ...
Since we're going to be doing a final editorial pass anyway, I'm merging this PR and closing the issue now. I don't see us making significant changes to the current proposed text - as Jake says, it looks quite good. Thanks, NAME for your work on this!
Originally proposed by Matt Stock here: URL
We THINK this is different from general DNS performance impacts, when you do client side ad insertion for URLs that the media provider is handing you based on the specific customer who is looking at the media. The actual problem is probably media player-specific, but but we can probably say something useful in a sentence or two.
BTW: comments are welcomed on whether or not we should acknowledge the existence of DNS-based ad-blockers and their relevance to this issue in this document.
So, now that I've slept on this (sort of), I was leaning toward adding at least a sentence or two about DNS-based ad-blockers, because that was a topic I THOUGHT I understood, but apparently not in much depth. ISTM that the question I SHOULD have asked, is "that's a fascinating question. Is there anything that a media provider can do differently, if we describe the issue?" ISTM that if what we say would be actionable for the designated audience, it makes sense to say it in the draft.

If a player implementer is aware of the potential for trouble from a change in hostname for a stream, they could run that request a little early as a mitigation to give time for the DNS to settle out, or to do any kind of pre-request to an upcoming non-recently-used hostname or something. Also the operator could chose to run server-side ads instead. (That might not be an exhaustive list, but it's at least a couple examples.) Maybe also worth mentioning it can be more of an issue if you're running a tight latency budget. But yeah, I think it's at least somewhat actionable for operators if the issue is on their radar.
Conclusion way back when was that we'd add text if we got to it with a deadline that we missed long ago. So this is won'tfix.
Describe in general terms segments and frame types, tradeoffs associated with segment size and keyframe interval selection. (related to idle-time and caching) Thanks NAME for the suggestion as part of URL
This is about low-latency and where you can start rendering in a media stream. Mention and explain briefly? This isn't quite about the NETWORK, but it's about caching, which is probably in the network. Keyframes can also be used for thumbnails when you hover over something. More keyframes gives you more flexibility in where you can start rendering, but is also larger and comes with a bandwidth and path occupancy cost.
Insert this material in "For further reading" (}?
This is now addressed in the reading list section. Issue can be closed.
My thought here was that stream characteristics like GOP sizing place a constraint on switching opportunities for renditions (ABR) and ad insertion, which can have an impact on bandwidth utilization, etc. I thought some explanatory text might help pull those sections together a bit more, but I'm fine with it just being covered in the further reading, too.
It is not very easy to correctly discuss the trade-offs between the key frame internal, segment size, encoding quality, impact on the storage, request rate and all that. There are detailed studies that do an excellent job on explaining these trade-offs, so referring the readers to these studies is better IMO.
Closing this issue as the further reading section identifies the relevant studies.

Advertising is an important part of the video delivery landscape and has an impact on network design and operational considerations in streaming video, for sure. NAME gave a pull request that's a decent start here: URL There are some unanswered comments in that pull request, but we should consider adding such a section and refining it even in the absence of responses.
Ads are evil :) Could the IETF ban them?
NAME will review proposed text in PR