[Mops] Lars Eggert's No Objection on draft-ietf-mops-streaming-opcons-10: (with COMMENT)

[Lars Eggert via Datatracker <[e-mail]>]

Lars Eggert has entered the following ballot position for
draft-ietf-mops-streaming-opcons-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-mops-streaming-opcons/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

# GEN AD review of draft-ietf-mops-streaming-opcons-10

CC @larseggert

## Comments

### Section 6.3, paragraph 0
```
  6.3.  QUIC and Its Behavior
```
I'm surprised this section doesn't refer to draft-ietf-quic-manageability? That
document discusses some of the same (and related) issues.

### Section 6.3, paragraph 1
```
     Although QUIC provides an alternative to the TCP and UDP transport
     protocols, QUIC is itself encapsulated in UDP.  As noted elsewhere in
     Section 7.1, the QUIC protocol encrypts almost all of its transport
     parameters, and all of its payload, so any intermediaries that
     network operators may be using to troubleshoot HTTP streaming media
     performance issues, perform analytics, or even intercept exchanges in
     current applications will not work for QUIC-based applications
     without making changes to their networks.  Section 7 describes the
     implications of media encryption in more detail.
```
"Transport parameter" is a QUIC-specific term to describe connection-level
settings that are negotiated during the handshake. I think this paragraph - and
others that mention transport parameters in this document - mean to talk about
the broader concept of "connection metadata". I would suggest not overloading
the QUIC "transport parameter" term in this way.

### Inclusive language

Found terminology that should be reviewed for inclusivity; see
https://www.rfc-editor.org/part2/#inclusive_language for background and more
guidance:

 * Terms `his` and `he`; alternatives might be `they`, `them`, `their`
 * Term `traditional`; alternatives might be `classic`, `classical`, `common`,
   `conventional`, `customary`, `fixed`, `habitual`, `historic`,
   `long-established`, `popular`, `prescribed`, `regular`, `rooted`,
   `time-honored`, `universal`, `widely used`, `widespread`

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 3.2, paragraph 1
```
-    the contraints on bandwidth at various points in the network.  This
-    analysis is necessary because media servers may react to bandwith
+    the constraints on bandwidth at various points in the network.  This
+           +
+    analysis is necessary because media servers may react to bandwidth
+                                                                   +
```

#### Section 3.2, paragraph 7
```
-       transport-level loss is occuring, but
+       transport-level loss is occurring, but
+                                    +
```

#### Section 5.4, paragraph 3
```
-    (herafter referred to as "ads").
+    (hereafter referred to as "ads").
+        +
```

#### Section 5.5.3, paragraph 1
```
-    hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detction have
+    hop (Wi-Fi, 5G, or LTE), new problems in bandwidth detection have
+                                                          +
```

#### Section 6.1, paragraph 3
```
-    In contrast to adaptive segmented delivery over a reliable tansport
+    In contrast to adaptive segmented delivery over a reliable transport
+                                                                +
```

#### Section 6.3, paragraph 5
```
-    application until the lost packet is retransmitted, allowing in-order
-                                      ^    ^^^^^^ ^^
+    application until a retransmission of the lost packet has been received, allowing in-order
+                      ++++++++++++++++++++                ^^ +++++   ^^ ^
```

#### Section 6.3, paragraph 7
```
-    As noted in Section 6.2, there is an increasing interest in transport
-                                                                 ^^ -----
-    protocol behaviors that respond to delay measurements, instead of
-    ^ ----   --- ^^
-    responding to packet loss.  These behaviors may deliver improved user
-                                      --- ^^
+    As noted in Section 6.2, there is an increasing interest in congestion
+                                                                ++++++ ^^
+    control algorithms that respond to delay measurements, instead of
+    ^^^^     ^^  ++++
+    responding to packet loss.  These algorithms may deliver improved user
+                                       ^^  ++++
```

#### Section 6.3, paragraph 7
```
-    agility, and [RFC9002] defines a basic algorithm with transport
-                                                    ---------------
-    behavior that is roughly similar to TCP NewReno [RFC6582].  However,
-   ---------
+    agility, and [RFC9002] defines a basic congestion control algorithm
+                                           +++++++++++++++++++
```

#### Section 7.2, paragraph 9
```
-    benefitted from this intervention a media streaming operator
-          -
```

#### Section 7.3, paragraph 4
```
-    monitoring of IETF protocols to continue for the forseeable future.
+    monitoring of IETF protocols to continue for the foreseeable future.
+                                                        +
```

### Duplicate references

Duplicate informative references to:
`https://datatracker.ietf.org/meeting/interim-2020-mops-01/materials/slides-interim-2020-mops-01-sessa-april-15-2020-mops-interim-an-update-on-streaming-video-alliance`.

### Outdated references

Reference `[RFC2001]` to `RFC2001`, which was obsoleted by `RFC2581` (this may
be on purpose).

### Grammar/style

#### Section 1, paragraph 12
```
Discussion This document is in the Github repository at: https://github.com/
                                   ^^^^^^
```
The official name of this software platform is spelled with a capital "H".

#### Section 3.6, paragraph 1
```
"throttle" these transfers in order to to mitigate the load that these hosts
                                    ^^^^^
```
Possible typo: you repeated a word.

#### Section 3.6, paragraph 3
```
a [Mishra] reported that after the CoViD-19 pandemic broke out in early 2020
                                   ^^^^^^^^
```
Did you mean "COVID-19" or the alternative spelling "Covid-19" (= coronavirus)?

#### Section 3.6, paragraph 4
```
ffic up 36% over an average day (pre COVID-19)}. We note that other operators
                                 ^^^^^^^^^^^^
```
The word "pre-COVID-19" is spelled with a hyphen.

#### Section 4.1, paragraph 2
```
o, and some tradeoffs may be necessary relative to what is feasible in a hig
                             ^^^^^^^^^^^^^^^^^^
```
In this context, the adverb seems more correct than the adjective "necessary".

#### Section 4.1, paragraph 5
```
rations. However, shorter segments means more frequent intra-coded frames an
                                   ^^^^^
```
It seems that the correct verb form here is "mean".

#### Section 4.2, paragraph 3
```
ecessary to support low-latency live streaming. This level of latency can typ
                                ^^^^^^^^^^^^^^
```
This expression is normally spelled as one or with a hyphen.

#### Section 5.3, paragraph 1
```
oth content and ads) are able to be accessed quickly. The less targeted, the
                                 ^^^^^^^^^^^
```
Avoid the passive voice after "to be able to".

#### Section 6.3, paragraph 12
```
ransport parameters itself, with the exception of a few invariant header fie
                            ^^^^^^^^^^^^^^^^^^^^^
```
Consider using "except" or "except for".

#### Section 7.2, paragraph 5
```
Reading and References The Media Operations community maintains a list of ref
                                 ^^^^^^^^^^
```
An apostrophe may be missing.

#### Section 7.2, paragraph 8
```
C., Zimmermann, R., and A. Bentaleb et al, "A Survey on Bitrate Adaptation Sc
                                    ^^^^^
```
A period is misplaced or missing. (Also in other references.)

## Notes

This review is in the ["IETF Comments" Markdown format][ICMF], You can use the
[`ietf-comments` tool][ICT] to automatically convert this review into
individual GitHub issues. Review generated by the [`ietf-reviewtool`][IRT].

[ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md
[ICT]: https://github.com/mnot/ietf-comments
[IRT]: https://github.com/larseggert/ietf-reviewtool