Re: [AVTCORE] Robert Wilton's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)

Gunnar Hellström <> Tue, 25 May 2021 19:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0020E3A1B8F; Tue, 25 May 2021 12:57:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 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_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id codEsi3Tbb1t; Tue, 25 May 2021 12:57:54 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 066363A1B8C; Tue, 25 May 2021 12:57:53 -0700 (PDT)
Received: from [] ( []) (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: by (Postfix) with ESMTPSA id 9E82C2067A; Tue, 25 May 2021 21:57:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=dkim; t=1621972671; bh=xf6E1aLNLnPEpUcAZOBK4RK2u/a07XzSqIJK+bSgoro=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=Vfsi43E7MXAHk+LJzWhZ5wIcwaSGhpAhkbpeX0Ob2n+GjC8L+xKYzXsbxE5E0y/bG W+yJSNPXLI/Hk1HCd4s9AqbiQ4U3PKDDYVf9gLXs1sutwMSGjuhpIUs4acJGWLce5t SXX2EZOAfYiLbiasK0MvQ245o0a8c2DWcvCaLvxU=
To: Robert Wilton <>, The IESG <>
References: <>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <>
Message-ID: <>
Date: Tue, 25 May 2021 21:57:49 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.10.2
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <>
Subject: Re: [AVTCORE] Robert Wilton's No Objection on draft-ietf-avtcore-multi-party-rtt-mix-18: (with COMMENT)
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 25 May 2021 19:57:59 -0000


Thanks for your review, please see answers inline.

Den 2021-05-20 kl. 10:50, skrev Robert Wilton via Datatracker:
> Robert Wilton has entered the following ballot position for
> draft-ietf-avtcore-multi-party-rtt-mix-18: 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
> for more information about DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> Hi,
> Thanks for this document.  This document is quite a long way from my core
> knowledge base, so I'm not sure whether there is much that I can really add.
> It doesn't seem to have any obvious manageability concerns.
> I was initially surprised by the capability exchange mechanism
> (offer/exchange), in that if both offeror and receiver could support multiple
> options then it is always the the receiver that decides which to use (by only
> selecting one).  I think that this is probably fine.  I don't know which
> parties generally initiate these exchanges, and whether there is ever a case
> where both offeror and receiver support multiple options where it would be
> beneficial for the offeror to make the final decision as to which should be
> used (e.g., when coordinating between more than two devices).
[GH] Since we do not currently have another multiparty method, it is 
hard to say if it would be suitable to answer that both are supported. 
It is a risk that allowing both simultaneously would cause confusion. 
Therefore I prefer to keep it as it is.
> As one minor nit, I would have preferred to see section 1.2, "Selected solution
> and considered alternatives" as an appendix.  I wasn't convinced that it is
> core to understanding this document, but I'm happy to leave it to the authors
> discretion as to whether they should move it, or leave it where it is.

[GH] You have a point in that view. However, another reviewer reported 
that it was very goog to find this information up-front. So, with some 
hesitation, I select to let the alternatives section stay where it is.



> Thanks,
> Rob
Gunnar Hellström