Original text:
3.1.3. <del> Where media is both sent and received; This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation.  This may be done as client/server, or peer to peer with a many to many relationship of both senders and receivers.  The target for latency may be as large as 200ms or more for some media types such as audio, but other media types in this use case have much more stringent latency targets. </del>  3.2. <del> For the video conferencing/telephony use case, there can be additional scenarios where the audience greatly outnumbers the concurrent active participants, but any member of the audience could participate.  As this has a much larger total number of participants - as many as Live Media Streaming lmstream, but with the bi- directionality of conferencing, this should be considered a "hybrid". There can be additional functionality as well that overlap between the two, such as "live rewind", or recording abilities. Another consideration is the limits of "human bandwidth" - as the number of sources are included into a given session increase, the amount of media that can usefully understood by a single person diminishes.  To put it more simply - too many people talking at once is much more difficult to understand than one person speaking at a time, and this varies on the audience and circumstance.  Subsequently this will define some limitations in the number of potential concurrent or semi-concurrent, bidirectional communications that occur. 3.3. </del> The use cases in this section like those in interact do set some expectations to minimise high and/or highly variable latency, however their key difference is that are seldom bi-directional as their basis

Reviewer comments:
NAME I think this is ready for review and merging .
Duplicated "without without waiting" in Section 2.1. I wish I had spotted "where a user wishes to observe or control the graphical user interface of another computer through local user interfaces" in 3.1.2 - I'd suggest saying this as "where a user wishes to observe or control the graphical user interface of another computer through user interfaces that are local to the user". I think "This may include audio from both microphone(s) and/or cameras, or may include "screen sharing" or inclusion of other content such as slide, document, or video presentation" in 3.1.3 might need adjusting. Doesn't this need to say, "This may include audio from microphone(s) and/or cameras, and may include "screen sharing" or inclusion of other content such as slide, document, or video presentation"? (Also, we named everything except video as a media type, but if we're changing that paragraph anyway, we can add video as well) in 3.2, I had difficulty parsing "As this has a much larger total number of participants - as many as Live Media Streaming , but with the bi-directionality of conferencing, this should be considered a "hybrid"." I wasn't sure "much larger than what?" Is this intended to say something like "This use case can have an audience as large as Live Media Streaming as described in Section 3.3.3, but also relies on the interactivity and bi-directionality of conferencing as in Video Conferencing as described in Section 3.1.3. For this reason, this type of use case can be considered a "hybrid". (if we're forward-referencing section 3.3.3 in Section 3.2, this might be clearer if we swapped the order of Sections 3.2 and 3.3) In section 3.3.1, are there any non-hypothetical media types beyond "audio and/or video"? In Section 3.3.3, I asked you to distinguish between the live edge and the trailing edge (thank you for that), but I didn't realize that "either because the local player falls behind edge" was now unqualified. Is this "either because the local player falls behind the live edge**"? In 4.9.1, "this is infeasible in many use cases where provisioning of client TLS certificates is unsupported or infeasible." has two "infeasible"s. Perhaps one could be "impractical"? Your choice which, of course.
In submitting the -00 working group version, we tripped over an incompatibility between XML2RFC and google-i18n-address 3.0.0. The details are at URL and at URL I took the shortcut of removing the country: attributes for the authors in -00, but (per the comments on those issues, a version of XML2RFC that has been deployed, so we can add our country attributes back when we're fixing the nits identified in this issue. And NAME says it's "The Netherlands", but I'll let NAME and NAME wrestile that one out ... :zippermouthface:

Revised text:
3.1.3.  <ins> In the Video Conferencing/Telephony use case, media is both sent and received.  This use case typically includes audio and video media, and may also include one or more additional media types, such as "screen sharing" and other content such as slides, documents, or video presentations.  This may be done as client/server, or peer to peer with a many to many relationship of both senders and receivers. The target for latency may be as large as 200ms or more for some media types such as audio, but other media types in this use case have much more stringent latency targets. </ins> 3.2.  The use cases in this section like those in interact do set some expectations to minimise high and/or highly variable latency, however their key difference is that are seldom bi-directional as their basis