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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Thu, 08 April 2021 21:18 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
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 81F0A3A1D07 for <avt@ietfa.amsl.com>; Thu, 8 Apr 2021 14:18:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 (1024-bit key) header.d=egensajt.se
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 SF2tpcgAotsF for <avt@ietfa.amsl.com>; Thu, 8 Apr 2021 14:18:27 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [193.42.159.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E44D63A1D05 for <avtcore@ietf.org>; Thu, 8 Apr 2021 14:18:26 -0700 (PDT)
Received: from [192.168.2.137] (h77-53-37-81.cust.a3fiber.se [77.53.37.81]) (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) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 9D1AB2010E; Thu, 8 Apr 2021 23:18:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1617916703; bh=+tS+RjxXfxCBaiRJ/MkTswszP3gLqj6Ca0nY5LDnX8s=; h=Subject:To:References:From:Date:In-Reply-To:From; b=V8E0SKFSA2SIdhhVhQmkHOye4GoJpCKvsf79+0WmLm2CVExi55BuOfpyHylD3IRl+ sQel6V+OQN+7a96nHAk9aQQ45bQ0PhIBee9JEn2ZdXKd7cTH8lT0oeiCwqDeKKlxPn 8sDYICsgZsfvanivrDOzF+nTbjJo8eKSSGaK2FD0=
To: "Murray S. Kucherawy" <superuser@gmail.com>, avtcore@ietf.org
References: <CAL0qLwYOyn6x4Q3od0efGXvFoBjbvpBQsTbB==cUfyi9Ge-vPQ@mail.gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <ae77f5a3-8a54-556c-97fc-ba394e12546a@ghaccess.se>
Date: Thu, 8 Apr 2021 23:18:23 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0
MIME-Version: 1.0
In-Reply-To: <CAL0qLwYOyn6x4Q3od0efGXvFoBjbvpBQsTbB==cUfyi9Ge-vPQ@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------F347EA7CF42BF1712E9A74B6"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/nR5cZt0JoCe2I9EZU3nT34fcpLw>
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:18:33 -0000

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 Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se