Re: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT)

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Mon, 17 May 2021 21:29 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 3E6BF3A45A8; Mon, 17 May 2021 14:29:35 -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, NICE_REPLY_A=-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 (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 Mp2cZFEResz8; Mon, 17 May 2021 14:29:30 -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 1E9403A45A5; Mon, 17 May 2021 14:29:29 -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)) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 47E9820199; Mon, 17 May 2021 23:29:28 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1621286968; bh=awlg9zBjERklLgOldYQ18MrSpaMu5V7ZDs4yk6A8dSo=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=BglJ2cIiHl1XTG/onUe+sBV2t0fKXw8yHS05ST+SAqU8n5aUEm23R/y09RrLqWvaF 4hR7H2oJDJYw17BFe7QxBWfCmeZ7j74STh6Ql/+/ZSYjLwFGC15vZx8YSIBCber3P7 eW8OgNyGFNqXGccYVEAkPYiatUnjl/U5XAWDG2iQ=
To: Martin Duke <martin.h.duke@gmail.com>, The IESG <iesg@ietf.org>
Cc: avtcore-chairs@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix@ietf.org, avt@ietf.org
References: <162068222166.24279.17528511733896002331@ietfa.amsl.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <0d972786-1d24-5333-116c-ad17fd07c7e7@ghaccess.se>
Date: Mon, 17 May 2021 23:29:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.1
MIME-Version: 1.0
In-Reply-To: <162068222166.24279.17528511733896002331@ietfa.amsl.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/VfHPY7aOsIJn2m94nDF_m8Nt11g>
Subject: Re: [AVTCORE] Martin Duke's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-17: (with COMMENT)
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: Mon, 17 May 2021 21:29:35 -0000

The new version mentioned in a recent mail answering the comments by 
both Martin Duke and Lars Eggert is available.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-avtcore-multi-party-rtt-mix-18.html

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-multi-party-rtt-mix-18


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Regards
Gunnar

Den 2021-05-10 kl. 23:30, skrev Martin Duke via Datatracker:
> Martin Duke has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-17: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> - It is not completely clear to me what the actions in the case of congestion
> are. RFC 4103 RECOMMENDS four steps, the first is going from 300 to 500ms. So
> what is the hiearchy here. My guess is:
>
> Step 1. Senders MUST go from 300ms to 2 seconds
> Step 2. Senders SHOULD (further?) limit the number of characters sent
> Step 3. Senders SHOULD go from 2 seconds to 5 seconds
> Step 4. Senders SHOULD exclude nodes from the session
>
> Is this correct?
>
> - Assuming it is correct, I don't understand the motivation behind the
> congestion considerations in Section 8.
>
> The first and third paragraphs make perfect sense to me. But if the total
> traffic to a receiver, regardless of the number of senders, remains limited to
> 1 packet / 300ms, I don't see why you would change the RFC 4103 guidance of
> 500ms up to 2 seconds. This isn't a DISCUSS because you're welcome to be more
> conservative, but I would like to understand your reasoning.
>
> No need to reply to the comments below:
>
> - In (3.16) and (4.2.2), you mention various privacy-sensitive fields and then
> say "Integrity SHALL be considered..." I think you mean confidentiality?
> Integrity means the data hasn't been altered by an attacker.
>
> - It would be helpful to clarify in this draft that the CPS limit applies only
> to new, not redundant, text, assuming that is in fact the case.
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

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