Re: [Mops] streaming-opcons-07 review

Thanks Chris.

I addressed all your comments at:
https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/pull/93

I leave it to my esteemed coauthors to accept the PR ;) Any comments are
also welcome on the PR.

-acbegen

On Fri, Dec 10, 2021 at 10:03 PM Chris Lemmons <alficles@gmail.com> wrote:

> Nits and observations:
> §2.2 "handwidth" should be "bandwidth".
> §2.6 "faiis" should be "fails".
> §2.6 ISP acronym is used without expanding the first use for those
> unfamiliar with it.
> §2.7 IXP and VPN acronyms used without definition as well.
>
> For the acronyms, ISP and VPN might be well known enough to avoid
> spelling out, but IXP probably needs spelling out the first time. I
> usually err on the side of spelling them out, though, to avoid
> ambiguity.
>
> §4.5.2 Does "goodput" need explanation or do we think readers will be
> familiar with the term? Could a reference help here?
> §4.6.2 "Many assumes" should be "Many assume" or "Many people assume".
> §5 Most of the document uses "Adaptive BitRate", but here we use
> "Adaptive Bitrate". We should be consistent with capitalization.
> §5.2 "we have trusted the TCP protocol" reads oddly because the P
> already stands for protocol. Perhaps just "we have trusted TCP"? Also
> in the last paragraph with "Although TCP protocol behavior".
> §5.3 "transport protocol behaviors that responds" should be "transport
> protocol behaviors that respond".
> §5.3 "something completely different" needs full stop.
> §7.3 Traffic Control CDN has graduated Apache incubation. The new
> address is https://trafficcontrol.apache.org/ .
> §7.6.* Should most of these links be references? Or are just links ok?
> I know with any kind of linking there's a risk of staleness, but these
> are probably useful enough to provide, I'm just not sure exactly what
> the right formatting should be.
> §9 It's odd to say basically nothing in the "Security Issues" section.
> We've got multiple sections (including all of section 6) that touch on
> security and privacy implications of various kinds of behaviours in
> the streaming media space. Maybe a sentence or two here that points to
> the rest of the doc while acknowledging that since we're not defining
> a new protocol, we're not creating new problems? Or maybe it's fine as
> is. It just feels strange to me.
>
> Procedural question: We have references to drafts in the document.
> Does its publication need to be held until those references can be
> resolved?
>
> Relatedly, 7234 is very likely to be obsoleted by
> draft-ietf-httpbis-cache-19 (which is in the RFC Editors queue) soon.
> Should we update the reference in §2.4 assuming this document is
> published after that?
>
> And, of course, an apology for being so very late to review this. It's
> a substantial document and it has a _lot_ of really valuable guidance.
> Perhaps most valuable of all are the very well-collected references
> that point the reader to a lot of other documents, organizations, and
> initiatives. If we hammer out the last few details, I support this
> draft.
>
> --
> Mops mailing list
> Mops@ietf.org
> https://www.ietf.org/mailman/listinfo/mops
>