[Perc] Barry Leiba's No Objection on draft-ietf-perc-private-media-framework-10: (with COMMENT)
Barry Leiba via Datatracker <noreply@ietf.org> Tue, 14 May 2019 04:57 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: perc@ietf.org
Delivered-To: perc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 3B35A12009C; Mon, 13 May 2019 21:57:10 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-perc-private-media-framework@ietf.org, Nils Ohlmeier <nohlmeier@mozilla.com>, perc-chairs@ietf.org, perc@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.96.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <155780983023.23741.290642209182221824.idtracker@ietfa.amsl.com>
Date: Mon, 13 May 2019 21:57:10 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/perc/hEiQQhlD_Q2IBjFKXEjcej4-a3M>
Subject: [Perc] Barry Leiba's No Objection on draft-ietf-perc-private-media-framework-10: (with COMMENT)
X-BeenThere: perc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Privacy Enhanced RTP Conferencing <perc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/perc>, <mailto:perc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/perc/>
List-Post: <mailto:perc@ietf.org>
List-Help: <mailto:perc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/perc>, <mailto:perc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 14 May 2019 04:57:10 -0000
Barry Leiba has entered the following ballot position for draft-ietf-perc-private-media-framework-10: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-perc-private-media-framework/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for a clear document. Just a bunch of editorial comments here: In the Abstract, it’s probably past the time to talk about what the solution *aims* to do, so, “The solution builds upon existing security mechanisms....” Similarly in the Introduction, “This document defines improved security so as to lower the barrier....” (Or just strike the sentence, as the first sentence of the next paragraph has it covered.) And the last sentence of the Introduction, “This document defines a framework for enhanced privacy....” In Section 2 you define “Trusted Endpoint”, but then also use “Endpoint” and “endpoint” through the document. Are these all meant to be the same thing (that is, all things called “endpoints” here are Trusted Endpoints)? If so, please capitalize “Endpoint” consistently, and say “Trusted Endpoint (or simply Endpoint)” in the definition. — Section 3.1.1 — The key exchange mechanisms specified in this framework prevents the Media Distributor Make it “prevent” to agree with “mechanisms”. or better than traditional conferencing (i.e. non-PERC) deployments. You need a comma after “i.e.”. Or better still, here and elsewhere in the document, just eliminate the Latin abbreviation and just say, “traditional conferencing (non-PERC) deployments.” — Section 4.1 — It’s not clear from the diagram or explanation, so please clarify for me: there one e2e key per endpoint, and every endpoint knows the key for all the other endpoints, yes? I think it would be worth saying this clearly and explicitly, either here (my preference, to set it up early) or in Section 4.5. — Section 4.5.2 — Endpoints MUST generate a new E2E encryption key whenever it receives a new EKT Key. Make it “An Endpoint MUST....” — Section 5 — I suggest avoiding the phrase “key requirements” to avoid confusion about the word “key”. Maybe say “critical requirements” or “important requirements” instead. — Section 5.2 — Similarly, the Key Distributor's certificate fingerprint can be conveyed to endpoint in a manner that can be authenticated This needs to be one of “an endpoint”, “the endpoint”, or “endpoints”. — Section 5.3 — The title should either be “Conference Identification” or “Conference’s Identification”. — Section 6.5 — Each endpoint generates its own E2E Key (SRTP master key), thus distinct per endpoint. Make it “thus there is a distinct E2E Key per endpoint.” Endpoints that receive media from a given transmitting endpoint gains knowledge Make it “gain knowledge”. — Section 8.2.1 — the Media Distributor can attempt to consume the receiving endpoints resources. Make it either “endpoint’s resources” (for one endpoint) or “endpoints’ resources” (for multiple endpoints). — Section 8.2.3 — However, due to fact that the Media Distributor is allowed Make it “due to the fact that”, or, better, “because”.
- [Perc] Barry Leiba's No Objection on draft-ietf-p… Barry Leiba via Datatracker
- Re: [Perc] Barry Leiba's No Objection on draft-ie… Paul E. Jones
- Re: [Perc] Barry Leiba's No Objection on draft-ie… Barry Leiba