Re: [Mops] [Last-Call] Intdir last call review of draft-ietf-mops-streaming-opcons-10

Hi Spencer,

Thanks for capturing these! These all look good to me.

Best,
Tommy

> On May 18, 2022, at 10:58 AM, Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> wrote:
> 
> Hi, Tommy, 
> 
> My apologies for my slow email response. 
> 
> We've entered GitHub issues for each of these comments, as below ... 
> 
> On Tue, Apr 26, 2022 at 6:53 PM Tommy Pauly via Datatracker <noreply@ietf.org <mailto:noreply@ietf.org>> wrote:
> Reviewer: Tommy Pauly
> Review result: Ready with Nits
> 
> Thanks to the authors for a well-written document. It is structured clearly,
> and explains the space nicely.
> 
> I have a few nit comments that could improve the document further (written as
> an IntArea review, but with some general nits as well):
> 
> - Section 3.2.1 says, "There are many reasons why path characteristics might
> change suddenly...". It may be good to mention MTU changes as part of the path
> changes, since changes in the maximum packet sizes supported by paths can be
> disruptive to traffic (requiring new PMTUD, etc).
> 
> This is https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/131 <https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/131>
> 
> I agreed. I think this is fixed in https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/pull/135 <https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/pull/135>
>  
> - There are places that could benefit from more citations. For example, Section
> 3.5 says, "Historical data shows that users consume more videos and at a higher
> bit rate than they did in the past..." but does not explain what data this is.
> 
> This is https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/132 <https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/132>.
>  
> - In Section 6.1 (on UDP), DNS queries are described as follows: "DNS, which is
> often used to send a single-packet request to look up the IP address for a DNS
> name, and return a single-packet response containing the IP address." I'm not
> sure how valuable this example is for explaining UDP, but if it is kept, please
> say that *multiple* packets are sent to get *multiple* addresses. With IPv6 and
> IPv4, clients query for both A and AAAA records, and handle multiple addresses,
> especially for IPv6.
> 
> This is https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/133 <https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/133>
> 
> I agree with you on this one. The text may not survive comment resolution on Michael Scharf's TSVART review, but I'll fix this, if it does. 
> 
> - As a bit of transport commentary, I don't find the setup of Section 6
> compelling. While UDP is a transport in a technical sense, for the purpose of
> media, it is almost always a layer upon which the protocol doing the congestion
> control work runs. To that end, QUIC is just another more standardized case of
> this, just like SCTP over UDP. Rather than talking about "UDP's behavior" vs
> "TCP's behavior", I suggest talking about how applications over UDP for media
> behave vs applications over TCP for media behave.
> 
> This is https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/134 <https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/134>.
> 
> I agree. I think the resolution here may subsumed in resolving comments from Michael's TSVART review (for example, https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/134 <https://github.com/ietf-wg-mops/draft-ietf-mops-streaming-opcons/issues/134>), but if it's not, I'll fix it.
> 
> Best,
> 
> Spencer
> -- 
> last-call mailing list
> last-call@ietf.org
> https://www.ietf.org/mailman/listinfo/last-call