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

"Murray S. Kucherawy" <superuser@gmail.com> Fri, 09 April 2021 22:26 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 89A9E3A163E for <avt@ietfa.amsl.com>; Fri, 9 Apr 2021 15:26:38 -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 sT2BnTTYLunA for <avt@ietfa.amsl.com>; Fri, 9 Apr 2021 15:26:34 -0700 (PDT)
Received: from mail-vk1-xa35.google.com (mail-vk1-xa35.google.com [IPv6:2607:f8b0:4864:20::a35]) (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 AD1C73A1542 for <avtcore@ietf.org>; Fri, 9 Apr 2021 15:26:18 -0700 (PDT)
Received: by mail-vk1-xa35.google.com with SMTP id d82so1595623vkd.3 for <avtcore@ietf.org>; Fri, 09 Apr 2021 15:26:18 -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=Yhbm/PtovFhNeTGO4zvZRBhLByOT+nAhbePM7hGlNu4=; b=g4R4FOZDDvspxnowqAzJg8o2QlpaMHzYNzyNNmR3DZkY3ANVGdz8dBaKfnEVP40TP3 A53+R2jN2Z7ofVHZ5scXBFB38d7tl8bAIoFHZal8jVoTCzwtWbpUljexQhbHHpbKAIR7 ltzI9lLYx7DtYONsU0lx+26rpg/HHfoOL4wJfoECmw3OtPMQoK2918czVh/7SUNj/SjR I6eCa7ZobD6srZ3Ue0NlecQXJk8wzffOk+6cvG8fpfNsE7VkGVeCvXkEc0qNcNGmvtxC GbxJWocp+EjyDhH2KHQNkDNjDfPB922worVQuJTJOoexoTA87uV7FhhT4+VKsuFYS7Kq 4lKA==
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=Yhbm/PtovFhNeTGO4zvZRBhLByOT+nAhbePM7hGlNu4=; b=mTcKm43ql5iX9b33Q9oxlifKiwbtcpaAUWMTT4IjhdQASsAe7iS9le8P1GnbsVeaNT +Qny2yJrZJo0mozPn0z3I+R4ueLnDdBF7Kmd6rko1RSQ87kvA159sPp8hOC42awtscZt IUORYZpDiBMQtxBMJThLWyOXkVZ99euO2qUV45fbFzFjfVFav/JJy0FMAE7feZmCsAI7 HFbIWQjsXbVIE6nO4UoGf5v7sQNbI1ckuPCPBncmMaalJDoFCIxgBMoTOej/FbxEz/Y5 5ZuB4nAniT+XzMswaFuUBKSU/a21mOKKy5X5TcHpidGjEuZFMYrqOeKh8cP+ppVyZNF1 i8Ng==
X-Gm-Message-State: AOAM532vjOpP37j5LGlLFhDboXkP0x5FbAAsTTfn+bjWG9Y+LBvZyHmr 6UWmEFx07XqqYXX0wacsIMIhCTsSkRHma30OlrZI6Tcq
X-Google-Smtp-Source: ABdhPJw0TAl9M9JT9QdYGug212XBfeJWZeDgGtRACmNK2IdDUIgHcl0b2ExEjiTuWXeZMzAMm7gdiRJ5Qr1UwBRJyoE=
X-Received: by 2002:ac5:cb0b:: with SMTP id r11mr13284514vkl.13.1618007176012; Fri, 09 Apr 2021 15:26:16 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <9a73e3cd-3321-55fd-9ebc-3702bc46195e@ghaccess.se>
From: "Murray S. Kucherawy" <superuser@gmail.com>
Date: Fri, 9 Apr 2021 15:26:05 -0700
Message-ID: <CAL0qLwbrJZiLTaBisdy9bo1JZVQ3Z-jJK1k-5JYnSgUM6DcADw@mail.gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@ghaccess.se>
Cc: avtcore@ietf.org
Content-Type: multipart/alternative; boundary="000000000000f8673205bf91a65f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/W6Mco13IQ3dIGQUtR7GsBOVjADc>
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: Fri, 09 Apr 2021 22:26:45 -0000

On Fri, Apr 9, 2021 at 2:47 AM Gunnar Hellström <
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