Re: [AVTCORE] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Thu, 06 May 2021 21:14 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 A592E3A320E; Thu, 6 May 2021 14:14:19 -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 pCisobx60z5H; Thu, 6 May 2021 14:14:14 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (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 2CFDA3A320D; Thu, 6 May 2021 14:14:13 -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 CDE3D20A0F; Thu, 6 May 2021 23:14:08 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1620335649; bh=65Vp3lqJOPwPf74+0lJS+83Bd1agaIt2BQr+f43DAkI=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=R20w6LU7ofzI/g5Pz1MlJiRAoWviGTl5l03MFH05iO+cwobuZgJNLJ+/N9w3p94IR 8sAm1c0KsaDd1PE3nd8HseenDKNAMxQmuxbh8a+AYspBOrs+hTRc/RZXwF7ND/aPfC g9Yoi5z88BzlI++v8lXoCiTybBuSsX+kfISUd1Sk=
To: Peter Yee <peter@akayla.com>, gen-art@ietf.org
Cc: avt@ietf.org, draft-ietf-avtcore-multi-party-rtt-mix.all@ietf.org, last-call@ietf.org
References: <162027251164.6302.1747673550915835779@ietfa.amsl.com>
From: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Message-ID: <32ad9a53-3aec-0a0f-ce77-6a3a79603e91@ghaccess.se>
Date: Thu, 06 May 2021 23:14:06 +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: <162027251164.6302.1747673550915835779@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/D21Bzeopuyfd9tydbBvq__FZNn4>
Subject: Re: [AVTCORE] 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: Thu, 06 May 2021 21:14:20 -0000
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." > > 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." > > 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. " > > 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." > > 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." > > 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." > > 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. > > 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." Thanks, Gunnar Hellstrom -- Gunnar Hellström GHAccess gunnar.hellstrom@ghaccess.se
- [AVTCORE] Genart last call review of draft-ietf-a… Peter Yee via Datatracker
- Re: [AVTCORE] Genart last call review of draft-ie… Gunnar Hellström
- Re: [AVTCORE] Genart last call review of draft-ie… Gunnar Hellström
- Re: [AVTCORE] Genart last call review of draft-ie… Peter Yee
- Re: [AVTCORE] Genart last call review of draft-ie… Peter Yee
- Re: [AVTCORE] [Last-Call] Genart last call review… Gunnar Hellström
- Re: [AVTCORE] Genart last call review of draft-ie… Gunnar Hellström
- Re: [AVTCORE] [Last-Call] Genart last call review… Lars Eggert