Re: [AVTCORE] AD review of draft-ietf-avtcore-multi-party-rtt-mix

"Murray S. Kucherawy" <superuser@gmail.com> Thu, 08 April 2021 21:32 UTC

Return-Path: <superuser@gmail.com>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5375C3A1C2F for <avt@ietfa.amsl.com>; Thu, 8 Apr 2021 14:32:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.096
X-Spam-Level:
X-Spam-Status: No, score=-2.096 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_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dfC499inJo45 for <avt@ietfa.amsl.com>; Thu, 8 Apr 2021 14:32:06 -0700 (PDT)
Received: from mail-ua1-x933.google.com (mail-ua1-x933.google.com [IPv6:2607:f8b0:4864:20::933]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 776A83A1D8E for <avtcore@ietf.org>; Thu, 8 Apr 2021 14:32:06 -0700 (PDT)
Received: by mail-ua1-x933.google.com with SMTP id 33so1174549uaa.7 for <avtcore@ietf.org>; Thu, 08 Apr 2021 14:32:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=RxvjQGCKqjz1w++r+yLx67Eu6SNfw1orbFiSF/hW3XQ=; b=Xznqc68/vZcuknK1Yad63KQmSOiPtC3MIv6hytq/C9IJ4GjpGx4JhyxbvmOFx3vdxb QCdSCeLnkZEMMvAbNSYx8vUNTOLwQaiQ+oTCUSWYRycnNtsYmhsAvGkU/arDp0dONAeM uzY0cXTMt8+pnycIN3SeJR+pc76eaeUjEbqui8teB/+Azm9wxKTVIZ+ZP0a/L0KLbjg+ eEQyyX6KqF7rdTNL37lfzjECJGm9FZM11T9GXgfjJEO4TdwRd1XsW3ej3zkReNEDiZii aNAXGjqQZGzzPefhZ84AWhXaLyP5mBbPZm+uruiD7xVMWcU8474i3x1OkhU90F2eYqcy 9HGg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RxvjQGCKqjz1w++r+yLx67Eu6SNfw1orbFiSF/hW3XQ=; b=hEb3P5HMm6nIOX22PQiqyrXOLjaIku+wqSi1gwdFlTE1t267PgivWUOqgoFEWpU47S AbMROqCPTntXLNam4GgTSXUqgyUapRla7EcY2GT93oUZJPJfndHMSV/9XDK3Y3j9d3n1 ZAjGf+HIq6HPFwdh5FSHMN8lluBNLiQagH5zETchpFrQBFlLxNfFBS5c2B8hUUbV6+zo a1ZwVTT/aJm+zzW5O9U0wpjdI5DBG5VZwSL/sSDT+9ifxLZAYPP+MDdq8u6VOOKrTK/3 1/frVe3OlM6LMxQQ/WEDdFVD1CJHBpdwxyiEuBzZI6Xq4tXpxH71jWn79vSiACpQxbFF lQAQ==
X-Gm-Message-State: AOAM533UUCIB1Jy3gDU3c5RihZn2FaOJ1708M9ghGStAGZDOBh91W9Gg 2IKrEUWnh8e6Euxgri1sY6HBn1Y8vZN775WFWpVhf38S
X-Google-Smtp-Source: ABdhPJxZYkC4KcbVDfrO0TWQ4ri1MrvjQwOH0XxJXbt/b3z65GRIJF1z1j9YQbOOOC+DbFgzU6Vicx6KeqBit4aBiD8=
X-Received: by 2002:ab0:44c3:: with SMTP id n61mr8637277uan.47.1617917524528; Thu, 08 Apr 2021 14:32:04 -0700 (PDT)
MIME-Version: 1.0
References: <CAL0qLwYOyn6x4Q3od0efGXvFoBjbvpBQsTbB==cUfyi9Ge-vPQ@mail.gmail.com> <ae77f5a3-8a54-556c-97fc-ba394e12546a@ghaccess.se>
In-Reply-To: <ae77f5a3-8a54-556c-97fc-ba394e12546a@ghaccess.se>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Thu, 8 Apr 2021 14:31:53 -0700
Message-ID: <CAL0qLwa00gKirVk_xWn1htfkYqkLzmcN43=d8XyZ_WSTBqFAig@mail.gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@ghaccess.se>
Cc: avtcore@ietf.org
Content-Type: multipart/alternative; boundary="00000000000053517a05bf7cc70f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/vpnMEITEgQi8WgdD77cBhbRpHMQ>
Subject: Re: [AVTCORE] AD review of draft-ietf-avtcore-multi-party-rtt-mix
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 08 Apr 2021 21:32:11 -0000

Hi Gunnar,

All of this looks good, thank you!

If you post a new version with those changes (you may have already; I
haven't checked), I'm comfortable sending the Last Call now.  We can sort
out specific text for the SHOULDs, etc., along the way; the various
reviewers might have suggestions on that topic, and maybe we can do some of
this in parallel.

-MSK

On Thu, Apr 8, 2021 at 2:18 PM Gunnar Hellström <
gunnar.hellstrom@ghaccess.se> wrote:

> Hello Murray,
>
> Thanks for the review,
>
> I have answered and acted on all but the SHOULD and RECOMMENDED etc. in
> sections 3.4 -4. The response on them will be provided soon.
>
> See answers inline,
> Den 2021-04-08 kl. 06:45, skrev Murray S. Kucherawy:
>
> Hello friends, sorry for the delay getting this review done.
>
> I think this is generally in good shape, though I admit my understanding
> of WebRTC isn't as strong as I'd like.  My review is therefore mostly about
> form rather than substance.
>
> At any rate, I have the following comments to offer after a first review.
> Please let me know what you think.
>
> --
>
> The Abstract is unusually long.  I would suggest reducing it to a
> paragraph or two, or maybe three.  My lay opinion is that the first two
> paragraphs could be left for the Introduction section, but other approaches
> are also probably available.
>
> [GH] Moved one paragraph to the intro, deleted another because it had
> similar wording in the intro.
>
>
> In many places, references look odd (e.g., "RFC3550[RFC3550]").  This may
> be an artifact of the way the XML generates the text or HTML forms but it
> might be worth a quick review to get it to look right.
>
> [GH]Done
>
>
> In Section 1.1, please use the new BCP 14 boilerplate (combining RFC 2119
> and RFC 8174).  Also in that section, "as defined in" should be "are
> defined in".
>
> [GH]Done
>
>
> In Section 1.3, "where a calltaker want to take" should use "wants"
> instead of "want".
>
> [GH]Done
>
>
> Is the "SHOULD" in Section 2.2 a piece of interoperability advice, or is
> it advice about presentation?
>
> [GH] Intended to be for interoperability.   I suggest to insert wording to
> result in:
>
> SHOULD *in order to maintain interoperability,* if nothing else is
> specified for the application, format transmitted text to that
> participant....
>
>
>
> In Sections 2.4, 3.20, and 7, in multiple places, "sdp" should be in all
> caps.
>
> [GH] Done
>
>
> In Section 3.2, remove "being".
>
> [GH] Would it be even more clear to replace "being" with "is" ?
>
>    "As soon as a participant is known to participate in a session with
>    another entity and is available for text reception, a Unicode BOM
>    character SHALL be sent to it....."
>
>
>
> Section 3.4 has a bunch of "SHOULD" and "RECOMMENDED" that are not
> explained.  See comment below about Section 8 for my thinking here.  This
> continues throughout the rest of Section 3's subsections and much of
> Section 4.
>
> [GH] For 3.4, the explanation is at the end of the section: "The intention
> is to keep the latency low and network load limited while keeping a good
> protection against text loss in bursty packet loss conditions."
>
> But that is a summary explanation. I can insert explanations for each
> timing figure in the section.
>
> I stop handling this comment here for now and will return to it soon with
> another response..
>
>
> In Section 3.20, "this sections shows" should be "this section shows".
>
> [GH] Done
>
> In Section 4.2.6, "these facts makes" should be "these facts make".
>
> [GH] Done
>
>
> Section 8 has a bare "SHOULD", by which I mean advice is given with no
> context.  "SHOULD" and "RECOMMENDED" present a choice; why might an
> implementer legitimately decide not to follow this advice?  If there's no
> good reason, should these be "SHALL"/"MUST" instead?
>
> [GH] Agreed, in this case SHALL is right.
>
>
> Section 11, second paragraph: "restricted of privacy reasons" should
> probably be "restricted for privacy reasons".
>
> [GH] Done
>
>
> Section 11, third paragraph: "masquerading" should be "masquerade".
>
> [GH] Done
>
>
> Section 11 should also probably refer to Section 3.19.
>
> [GH] A reference added last in 11: "Further security considerations
> specific for this application are specified in section 3.19."
>
>
> Commonly, a "Changes" section (Section 12 here) is marked with a note like:
>
>     [RFC Editor: Please remove this section prior to publication.]
>
> (At least I presume that's the intent for this section as well.)
>
> [GH] Done
>
>
> Thanks,
>
> Gunnar
>
> -MSK
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenanceavt@ietf.orghttps://www.ietf.org/mailman/listinfo/avt
>
> --
> Gunnar Hellström
> GHAccessgunnar.hellstrom@ghaccess.se
>
>