Re: [Gen-art] [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: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4262B3A2DF7; Fri, 7 May 2021 12:45:17 -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=unavailable 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 g1liZQhE_5dm; Fri, 7 May 2021 12:45:12 -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 7B3963A302A; Fri, 7 May 2021 12:42:53 -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: Gunnar Hellström <gunnar.hellstrom@ghaccess.se>
Message-ID: <5807a5ac-c350-bb69-2cbe-2ec85125024d@ghaccess.se>
Date: Fri, 07 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/gen-art/ZKJHDSd3ElSsaUj-LtNfCyi7B_o>
Subject: Re: [Gen-art] [Last-Call] Genart last call review of draft-ietf-avtcore-multi-party-rtt-mix-14
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 07 May 2021 19:45:18 -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
- [Gen-art] Genart last call review of draft-ietf-a… Peter Yee via Datatracker
- Re: [Gen-art] Genart last call review of draft-ie… Gunnar Hellström
- Re: [Gen-art] Genart last call review of draft-ie… Gunnar Hellström
- Re: [Gen-art] Genart last call review of draft-ie… Peter Yee
- Re: [Gen-art] Genart last call review of draft-ie… Peter Yee
- Re: [Gen-art] [Last-Call] Genart last call review… Gunnar Hellström
- Re: [Gen-art] Genart last call review of draft-ie… Gunnar Hellström
- Re: [Gen-art] [Last-Call] Genart last call review… Lars Eggert