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

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Sun, 11 April 2021 21:09 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 A362C3A1E7B for <avt@ietfa.amsl.com>; Sun, 11 Apr 2021 14:09:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 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_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 nqCCDiCiCsgx for <avt@ietfa.amsl.com>; Sun, 11 Apr 2021 14:09:39 -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 2C5083A1E7A for <avtcore@ietf.org>; Sun, 11 Apr 2021 14:09:38 -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 8FA3F20492; Sun, 11 Apr 2021 23:09:35 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1618175375; bh=cv/wYTw20QT4LiAGX2nlrgrOMfkg+4OLB9mH7O+6v1w=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=cmQK6Ws0cxg+PJGUethBty1ER9sLDR51sKQCTk4t1v1hePXFhViSsZsYAlykaCWKU JORmSygsO5UJa63DB6GJcqJ78ws5ns2OL1gZBLMc0n1f42Rxesb4YH9vdGcG3RsrFC u97kvaYdXRdJNJCAO/96eumFBdF3ywWKi9RZ05/I=
To: "Murray S. Kucherawy" <superuser@gmail.com>
Cc: avtcore@ietf.org
References: <CAL0qLwYOyn6x4Q3od0efGXvFoBjbvpBQsTbB==cUfyi9Ge-vPQ@mail.gmail.com> <ae77f5a3-8a54-556c-97fc-ba394e12546a@ghaccess.se> <CAL0qLwa00gKirVk_xWn1htfkYqkLzmcN43=d8XyZ_WSTBqFAig@mail.gmail.com> <9a73e3cd-3321-55fd-9ebc-3702bc46195e@ghaccess.se> <CAL0qLwbrJZiLTaBisdy9bo1JZVQ3Z-jJK1k-5JYnSgUM6DcADw@mail.gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <ddafdf4b-aa22-bc32-3982-19ca63c0a1d7@ghaccess.se>
Date: Sun, 11 Apr 2021 23:09:35 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1
MIME-Version: 1.0
In-Reply-To: <CAL0qLwbrJZiLTaBisdy9bo1JZVQ3Z-jJK1k-5JYnSgUM6DcADw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------C9607FB5117E8B000B3FAA14"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/FAWTM8AvVnFLQvjJknRd2dGHnIc>
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: Sun, 11 Apr 2021 21:09:45 -0000

A new version is available at

https://datatracker.ietf.org/doc/draft-ietf-avtcore-multi-party-rtt-mix/

It is intended to fulfill all review comments.

Section 4.2 with all SHOULDs has to do with interoperability between components. Most SHOULDs are now changed to SHALL. The reason to have SHOULD before, was that the section is about achieving interoperability with currently installed implementations, and in some future or in controlled environments there may be no such legacy devices and implementation of 4.2 should therefore be optional. That is now indicated in the leading paragraph of 4.2, and the rest can therefore be SHALLs.

Some places in section 3, where SHOULD and RECOMMENDED were used without motivation of alternatives or assignment of specific figures, are now changed either to SHALL or to include motivations.

Thanks

Gunnar
  

Den 2021-04-10 kl. 00:26, skrev Murray S. Kucherawy:
> On Fri, Apr 9, 2021 at 2:47 AM Gunnar Hellström 
> <gunnar.hellstrom@ghaccess.se <mailto:gunnar.hellstrom@ghaccess.se>> 
> wrote:
>
>     -On including RFC8174 in a group reference to BCP 14:
>
>     I think RFC 8174 is a good clarification for use of "SHOULD" and
>     "should" etc., but I failed to create the proper reference to BCP
>     14 in xml for xml2rfc v.3.
>     There are various instructions and examples available, but I
>     cannot make them work in practice.
>     Temporarily I copied the way that draft-ietf-avtcore-rtp-vvc-08
>     handles it, by just mentioning BCP 14 in text in the boilerplate
>     and not include it in the reference list.
>     Do you know a good xml template for the BCP 14 boilerplate?
>
> It appears to be common to just include normative references to RFC 
> 8174 and RFC 2119.
>
>     -On review of SHOULD etc. in sections 3 and 4.
>
>     Do you mean that I shall review the use of the RFC 2119 words in
>     sections 3 and 4 and judge if I can use the SHALL/MUST wording,
>     and if I want to keep SHOULD, then insert advice for decision of
>     when to follow the advice.
>
>     A possibility is to have SHOULD only in the introduction in 4.2
>     and then SHALL in the rest of 4.2.x because it is only applicable
>     for implementations selecting to implement the procedures
>     introduced in 4.2.
>
> Generally I believe SHOULD provides an implementer with a choice.  
> Clearly that choice is weighted (unlike MAY), but still when the 
> reader is left with a choice but doesn't know how to make it, the 
> document may actually be making things worse.  Thus my advice is to 
> say something of the form "you SHOULD do X, unless Y".
>
>     The current wording in 4.2 is:
>
>     "4.2.  Multi-party mixing for multi-party unaware endpoints
>
>        When the mixer has indicated RTT multi-party capability in an SDP
>        negotiation, but the multi-party capability negotiation fails
>     with an
>        endpoint, then the agreed "text/red" or "text/t140" format SHALL be
>        used and the mixer SHOULD compose a best-effort presentation of
>        multi-party real-time text in one stream intended to be
>     presented by
>        an endpoint with no multi-party awareness."
>
>     Could it be sufficient to use SHALL in most places in all 4.2.x
>     sections and change the beginning of 4.2 to:
>
>     "4.2.  Multi-party mixing for multi-party unaware endpoints
>
>        When the mixer has indicated RTT multi-party capability in an SDP
>        negotiation, but the multi-party capability negotiation fails
>     with an
>        endpoint, then the agreed "text/red" or "text/t140" format SHALL be
>        used and the mixer SHOULD compose a best-effort presentation of
>        multi-party real-time text in one stream intended to be
>     presented by
>        an endpoint with no multi-party awareness,*when that is desired
>     in the actual implementation. The following specifies a procedure
>     for that situation"*
>
>     - and then mainly use SHALL in the rest of section 4.2.
>
>
> Yes, that's a definite improvement.  The other alternative is to avoid 
> the ambiguous use of SHOULD, such as:
>
> "When the mixer has indicated RTT multi-party capability in an SDP 
> negotiation, but the multi-party capability negotiation fails with an 
> endpoint, then the agreed "text/red" or "text/140" format SHALL be 
> used and the mixer will then typically compose a best-effort 
> presentation of multi-party real-time text in one stream intended to 
> be presented by an endpoint with no multi-party awareness."
>
> Here you would avoid use of SHOULD altogether, which is something to 
> consider if the thing you're describing has nothing to do with 
> interoperability between components anyway.
>
> -MSK

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