Re: [Mops] Intdir last call review of draft-ietf-mops-streaming-opcons-10
Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com> Wed, 18 May 2022 17:59 UTC
Return-Path: <spencerdawkins.ietf@gmail.com>
X-Original-To: mops@ietfa.amsl.com
Delivered-To: mops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007D7C15E3E3; Wed, 18 May 2022 10:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.097
X-Spam-Level:
X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5eU4Diu-mKOk; Wed, 18 May 2022 10:59:04 -0700 (PDT)
Received: from mail-vs1-xe32.google.com (mail-vs1-xe32.google.com [IPv6:2607:f8b0:4864:20::e32]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3586C15E3E6; Wed, 18 May 2022 10:58:58 -0700 (PDT)
Received: by mail-vs1-xe32.google.com with SMTP id z6so2755878vsp.0; Wed, 18 May 2022 10:58:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SiV39Hb1fq9mctKE3IpxlJ59fiVCK4pQLJO9lSrVbFg=; b=NlLp9kjurQhBJSrDkhc2SBBcqwuRpqC5AKSIL8hN3KuHNaaH8SR9i3wgQpC0djHjrn vboQCKd0xwNuct9L7D1GymBqGMuSLbU6+tzQoYROKp9YBt/iJ3GhnIZIWf+ssyOWBnNz frI/+TRI6bJFcrnZCIiIMto7cyrawT++Nj2wc7xZ/BNeDWOoxigqfpMX6/imAgVx2Wgp iQOTFOLKdF83JOBTVH0jq7N3zalcKY5wSeVtHPDH9uu9nXT9h+6GKqMSXSko7YFIglUn 6aTe//zq+nQgf/0OmJmoPt1Y7dwXMQN5+IaDtXkrfIwJXkqx3i88HIbso4nvsfLYqpCH YJrg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SiV39Hb1fq9mctKE3IpxlJ59fiVCK4pQLJO9lSrVbFg=; b=IAcGzqXS1M50CB0scoK5kikr79BTENnRev/fqZkH6jSYoBQm71HDIMslmQa9bI1m3w voNhTg+N2H/h06LbkowFiQoE4p67I0V+izcswzVh0Aj2ygUlFXk9RrlD7soL35Rs7GKW LxlhWcyrLvpJogKR9z3h9XyEj+S4KVw6aepK3EetTngg9mXLKHcwvR4KK2BuELQJbV3S 0i/xLpgKi5uZTw4uEbXnXigDo6xSY1KqAGVszBedkILo7PHMzPijzoTsj26a4DXhjEXy J4Bfk+XSg6ITyhR7UYJCnlHJPKfzIIDxFv4MitcmwJkd3MjU8/jGU7yZbaMNKDmOMpxQ YSoA==
X-Gm-Message-State: AOAM533ttLWBIWNoqWLGejh+Z8GNcPZJ+Kr5OWbd4BuWN9fV6bEjvZpV z9HKasb0J+u3yDXDCyRi0u30QW+28LrDWa1H7nA=
X-Google-Smtp-Source: ABdhPJwC8VUsfOmdMyEPp45T0mEhxUVal0o24NCRbKO/qEoBgfiFa4SSWpOmgoaZiy4g+19+Qwpi8Ry+rIVAta66Gik=
X-Received: by 2002:a05:6102:32d3:b0:32d:6f0e:646f with SMTP id o19-20020a05610232d300b0032d6f0e646fmr558253vss.29.1652896737545; Wed, 18 May 2022 10:58:57 -0700 (PDT)
MIME-Version: 1.0
References: <165101722865.2081.3670693790800204057@ietfa.amsl.com>
In-Reply-To: <165101722865.2081.3670693790800204057@ietfa.amsl.com>
From: Spencer Dawkins at IETF <spencerdawkins.ietf@gmail.com>
Date: Wed, 18 May 2022 12:58:31 -0500
Message-ID: <CAKKJt-e5xDZP7a1+N2hzyjjDykPQCJPOWZAuHv7FpAWkx7xTZw@mail.gmail.com>
To: Tommy Pauly <tpauly@apple.com>
Cc: int-dir@ietf.org, draft-ietf-mops-streaming-opcons.all@ietf.org, last-call@ietf.org, MOPS Working Group <mops@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000e4554b05df4d0220"
Archived-At: <https://mailarchive.ietf.org/arch/msg/mops/halyVbOBX9_nygalUbCOMubL2gU>
Subject: Re: [Mops] Intdir last call review of draft-ietf-mops-streaming-opcons-10
X-BeenThere: mops@ietf.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Media OPerationS <mops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mops>, <mailto:mops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mops/>
List-Post: <mailto:mops@ietf.org>
List-Help: <mailto:mops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mops>, <mailto:mops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 18 May 2022 17:59:05 -0000
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> 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 I agreed. I think this is fixed in 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. > - 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 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. 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), but if it's not, I'll fix it. Best, Spencer
- [Mops] Intdir last call review of draft-ietf-mops… Tommy Pauly via Datatracker
- Re: [Mops] Intdir last call review of draft-ietf-… Spencer Dawkins at IETF
- Re: [Mops] [Last-Call] Intdir last call review of… Tommy Pauly