Re: [AVTCORE] [Last-Call] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Fri, 07 May 2021 19:45 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 7FFD73A3026; Fri, 7 May 2021 12:45:16 -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, 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 HmiFwbCpCBW1; Fri, 7 May 2021 12:45:11 -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 D94C03A2DF7; Fri, 7 May 2021 12:42:49 -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 2B918203B4; Fri, 7 May 2021 21:42:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620416566; bh=wdidVMKJWSKVexboraJE5pKD6DOXtZNiY4rRyR8GyKI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=h1/E99CAM6O0KTe01ODzA47jQENCJvtf6u60N+jgt2gdKi2W0fILtCsJ16njGHvD4 3a0EEX4H3XzWIqWBXsn7372tCMYwjRMACuSrQWU+uVm/bxH4Ezd9Uk2BbJ9snHZklj MG8PA14PtwKa/0Ie/owbJsIp+wnn7KtQX73YaDus=
To: Peter Yee <peter@akayla.com>, gen-art@ietf.org
Cc: last-call@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, avt@ietf.org
References: <162027251164.6302.1747673550915835779@ietfa.amsl.com> <32ad9a53-3aec-0a0f-ce77-6a3a79603e91@ghaccess.se> <008501d74372$9d96d6c0$d8c48440$@akayla.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <5807a5ac-c350-bb69-2cbe-2ec85125024d@ghaccess.se>
Date: Fri, 7 May 2021 21:42:45 +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: <008501d74372$9d96d6c0$d8c48440$@akayla.com>
Content-Type: multipart/alternative; boundary="------------4EBAB2C1B8B14A0807A4570A"
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/PilGkA5TgC5Dj0qGuBsY7O2jypo>
Subject: Re: [AVTCORE] [Last-Call] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
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, 07 May 2021 19:45:17 -0000

Peter,

I have made the extra few adjustments you proposed.

For the use of "disappeared", I agree that it is an unusual term in this 
context.

I checked RFC 4575, and there it is said that users "depart" or 
"disconnect" from a conference. "Disconnect" feels most familiar, so I 
propose to change the sentence to:

"When a participant on the RTP side is disconnected from the multiparty 
session, the corresponding T.140 data channel(s) SHOULD be closed."

Thanks,

Gunnar

-- 

Gunnar Hellström

GHAccess

gunnar.hellstrom@ghaccess.se  <mailto:gunnar.hellstrom@ghaccess.se>


Den 2021-05-07 kl. 20:55, skrev Peter Yee:
> Thanks for the quick response, Gunnar. I've prefaced my replies below with [PEY].
>
> 		-Peter
>
> -----Original Message-----
> From: Gunnar Hellström [mailto:gunnar.hellstrom@ghaccess.se]
> Sent: Thursday, May 06, 2021 2:14 PM
> To: Peter Yee; gen-art@ietf.org
> Cc: avt@ietf.org; draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org; last-call@ietf.org
> Subject: Re: Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
>
> Thank you for the thorough review. Please see comments inline.
>
> I will split the answers, and start here with answers and change
> proposals for the minor issues:
>
> Den 2021-05-06 kl. 05:41, skrev Peter Yee via Datatracker:
>> Reviewer: Peter Yee
>> Review result: Ready with Issues
>>
>> I am the assigned Gen-ART reviewer for this draft. The General Area
>> Review Team (Gen-ART) reviews all IETF documents being processed
>> by the IESG for the IETF Chair.  Please treat these comments just
>> like any other last call comments.
>>
>> For more information, please see the FAQ at
>>
>> <https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
>>
>> Document: draft-ietf-avtcore-multi-party-rtt-mix-14
>> Reviewer: Peter Yee
>> Review Date: 2021-05-05
>> IETF LC End Date: 2021-05-03
>> IESG Telechat date: Not scheduled for a telechat
>>
>> Summary: This draft specifies updates to RFC 4103 to allow real-time text
>> mixing for both multiparty-aware and multiparty-unaware participants. It has
>> some minor issues that should be addressed before publication. [Ready with
>> issues]
>>
>> Major issues: None
>>
>> Minor issues:
>>
>> Page 7, 1st block, 13th sentence: what constitutes a “reasonable effort”? It
>> might be best to drop this sentence.
> [GH] This reason is important for the desicion on technology selection.
>
> I suggest a change from:
>
> "For best deployment opportunity, it should be possible to upgrade
> existing endpoint solutions to be multi-party aware with a reasonable
> effort."
>
> to
>
> "For best deployment opportunity, it should be feasible to upgrade
> existing endpoint solutions to become multiparty-aware."
>
> [PEY] I'm fine with that.
>
>> Page 7, 2nd block, 2nd sentence, “300 ms”: would it make sense to append
>> “period” or “timeout” after this value?
> [GH] I suggest to change from "every 300 ms." to "with 300 ms intervals."
>
> [PEY] Works for me.
>
>> Page 13, section 3.4, 2nd paragraph, 1st sentence: in regards to “only part”,
>> how is this calculated?
> [GH] I suggest to change from "If the "CPS" value is reached, longer
> transmission intervals SHALL be applied and only part of the text queued
> for transmission sent at end of each transmission interval, until the
> transmission rate falls under the "CPS" value again."
>
> to
>
> "If the "CPS" value is reached, longer transmission intervals SHALL be
> applied and only as much of the text queued for transmission sent at end
> of each transmission interval that can be allowed without exceeding the
> "CPS" value, until the transmission rate falls under the "CPS" value
> again. Division of text for partial transmission MUST then be made at
> T140block borders. "
>
> [PEY] That's clearer. I'd insert "the" before "end".
>
>> Page 15, section 3.12, 2nd paragraph, 1st sentence: The placing of all
>> available redundant levels in the packet is presumably subject to a maximum
>> packet size or the “CPS” limit, if there are obnoxious levels of redundancy
>> specified?
> [GH] Thanks, a good observation. It is already covered in section 3.10,
> but it could be more emphasized there. In 3.12 we are only dealing with
> the redundancy, which must be possible to send and is not included in
> the "CPS" value.
>
> I suggest that the following part of 3.10 is improved from:
>
> "Redundant text SHALL also be included.  See Section 3.12"
>
> to;
> "Redundant text SHALL also be included, and the assessment of how much
> new text can be included within the maximum packet size MUST take into
> account that the redundancy has priority to be transmitted in its
> entirety.  See Section 3.12."
>
> [PEY] That works.
>
>> Page 17, section 3.17.2, 4th paragraph, 2nd sentence: “SHALL prefer” seems odd.
>> It doesn’t say that the marking will actually be done. It’s just preferred. If
>> you’re not going to require the marking in that sentence, then perhaps change
>> “SHALL” to “SHOULD”.
> [GH] Agreed. Done as proposed.
>> Page 19, section 3.20, 2nd paragraph, 2nd sentence: I don’t find the “something
>> specific” particularly enlightening. Like what? An identifier for the method?
> [GH] Proposed to be changed from:
>
> " In that case, the
>      SDP of the offer will include something specific for that method, and
>      an answer acknowledging the use of that method would accept it by
>      something specific included in the SDP."
>
> to:
>
> "In that case, the
>      SDP of the offer will include something specific for that method,
> e.g. an SDP attribute or another media format. An answer selecting the
> use of that method would accept it by
>      a corresponding acknowledgement included in the SDP."
>
> [PEY] That helps. With a comma after the "e.g.". ;-)
>
>> Page 27, section 4.2.2, 4th paragraph: can you elaborate on these “Integrity
>> considerations”? Otherwise, it’s difficult to comply with the SHALL in any
>> meaningful way.
> [GH] The sentence was inserted after discussions with emergency service
> providers, who had an example that it would be valuable to have a
> detailed personalized label of an emergency service agent shown to other
> agents while a less personal label should be used when sent to the
> calling users in emergency.
>
> The security aspects on the label are quite similar to the security
> aspects on the <display-text> elements specified in RFC 4575. Its
> security aspects are specified in
> https://tools.ietf.org/html/rfc4575#section-8
>
> You are right that that example contains mainly SHOULD and RECOMMENDED
> and no SHALL.
>
> I suggest changing:
>
> "Integrity considerations SHALL be taken when composing the label."
>
> to:
>
> "Information available to the mixer for composing the label may contain
> sensitive personal information that SHOULD not be revealed in sessions
> not securely authenticated and protected. Integrity considerations
> regarding how much personal information is included in the label SHOULD
> therefore be taken when composing the label."
>
> [PEY] That's much clearer.
>
>> Page 33, 3rd paragraph, 1st sentence: any reason for the change from “T.140” in
>> the previous and following paragraphs to “t140” in this one?
> [GH] No, they should be "T.140 data channels" for all cases in that
> paragraph.
> I have changed.
>> Page 33, 6th paragraph: how is disappearance determined?
> [GH]The disappearance may be signaled by the SIP conference system RFC
> 4353, RFC 4575 etc. as a conference notification if that system is used,
> or simply by removal of the text media in an RTP session modification.
> There may also be a malfunction detected by keep-alive transactions not
> being maintained. I suggest to not detail how it disappears.
>
> [PEY] Okay by me if that's well understood in this ecosystem. The verb disappearance just made it sound somewhat mysterious as opposed to something that can be signaled.
>> Page 35, section 11, 3rd paragraph, 2nd sentence before creating a new sentence
>> (see nits, below): I’m having troubles tying the adjective “secure” to each of
>> the nouns in the sentence. It works for “signaling” and perhaps “media”, but
>> for “authentication”, one sort of assumes that authentication mechanism is
>> secure and helping to provide the security. Perhaps you could reword that
>> sentence?
> [GH] I propose to change the sentence from:
>
> "Counteractions should be to require
>      secure signaling, media and authentication, and to provide higher
>      level conference functions e.g. for blocking and expelling
>      participants."
>
> to:
>
> "Counteractions should be to require authentication, secure session
> signaling and secure media. Higher level conference functions should
> also be used e.g., for blocking and expelling participants who caused
> security concerns."
>
> [PEY] Yes, I like that. Along with my usual nit about an Oxford comma after "signaling". And a hyphen between "Higher" and "layer". Sorry, that's just how my eyes/brain work. ;-)
>
>
> Thanks,
>
> Gunnar Hellstrom
>
-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se