Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guidelines-13
Mallory Knodel <mknodel@cdt.org> Fri, 25 November 2022 16:30 UTC
Return-Path: <mknodel@cdt.org>
X-Original-To: hrpc@ietfa.amsl.com
Delivered-To: hrpc@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E170CC14F738 for <hrpc@ietfa.amsl.com>; Fri, 25 Nov 2022 08:30:10 -0800 (PST)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cdt.org
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2zUCjkzwS0UU for <hrpc@ietfa.amsl.com>; Fri, 25 Nov 2022 08:30:06 -0800 (PST)
Received: from mail-pg1-x530.google.com (mail-pg1-x530.google.com [IPv6:2607:f8b0:4864:20::530]) (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) by ietfa.amsl.com (Postfix) with ESMTPS id 8A4F8C14F74C for <hrpc@irtf.org>; Fri, 25 Nov 2022 08:30:06 -0800 (PST)
Received: by mail-pg1-x530.google.com with SMTP id 136so4364164pga.1 for <hrpc@irtf.org>; Fri, 25 Nov 2022 08:30:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cdt.org; s=google; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=uA1Oetg7mHEDQB7tuIffAx4C6QNGeZToPxehCn/Iy9Q=; b=ReSQTGF4B/J4cn0+wBTTUDG6gLiFKlWtRBrbydhsRqhJ2mpHPftK+jBga6V3aTGYbh l0ainwZ/MWC6N0UZDGJJRuLE4OLp5tQY9xn4EVOxzUPlIrHUS1VxuZom9wa2uiS8/cHl v29GS1atigfVbY9TiVqZuuinFvE/TD33k/zWk=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:references:in-reply-to :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=uA1Oetg7mHEDQB7tuIffAx4C6QNGeZToPxehCn/Iy9Q=; b=k5B0NjIas/kl3CoO1G9z2mMxmuUf+MziaDymfFWq/ZmynPnSGazdhmeiDDKMAnUjIY P1dHxbNLGO4IByJRAEMIH+ZYcLe3v/z5Uy77Jg/PUhxxL5VkJK9iReYb2QiMBMwVK34l YddhygCiQoARKectlQecc2AzgFyy3JE6/rOeQ0ppHhTCC5WeP9XNWoCmxqrvWUx+L+Hy ruGxFlA+6PnP9fQ8KfOJNiT8b1jSViDR3cI1vG3rsJzDfmomIPTqFg97ZDoYG/kSftbN krNKHolMl8TM8f5aUzL6afKS6SPTty70HMCJggKIQrihMUKwwSlyCCQ7PLi5LRHZ0RKY 7n2Q==
X-Gm-Message-State: ANoB5pnCSXPZasnK0MgWgXp0xReYorRKF7Fa28bBMICOSL9G7OwqpMbl VlzwfZUEbIPwl1+/nuiByhlFydf6bcBnRkWtLchpPA==
X-Google-Smtp-Source: AA0mqf74agfsSaCjyLgpr5Mlo4gIYHKjznpKJxCXXbBNrnayRx7/B8ZaJAI+U0MK2iw4RDg/pe7CxeTtzyOCl81U0x0=
X-Received: by 2002:a65:6e8d:0:b0:477:ee28:b8d9 with SMTP id bm13-20020a656e8d000000b00477ee28b8d9mr1572986pgb.396.1669393805499; Fri, 25 Nov 2022 08:30:05 -0800 (PST)
MIME-Version: 1.0
Received: by 2002:a05:7300:b10a:b0:89:1c52:e7d3 with HTTP; Fri, 25 Nov 2022 08:30:04 -0800 (PST)
In-Reply-To: <cfabf1ff-8481-692e-f399-97613baa1bcc@cis-india.org>
References: <5F4C1659-9E41-4257-AE1A-8E4937AA1997@trammell.ch> <cfabf1ff-8481-692e-f399-97613baa1bcc@cis-india.org>
From: Mallory Knodel <mknodel@cdt.org>
Date: Fri, 25 Nov 2022 11:30:04 -0500
Message-ID: <CAGVFjMKB6RXZNy5hCF+w38_C+DTbXg4N0gTzjxbMdC=VRmL8Ag@mail.gmail.com>
To: Gurshabad Grover <gurshabad@cis-india.org>
Cc: "Brian Trammell (IETF)" <ietf@trammell.ch>, "hrpc@irtf.org" <hrpc@irtf.org>, "draft-irtf-hrpc-guidelines@ietf.org" <draft-irtf-hrpc-guidelines@ietf.org>, "irsg@irtf.org" <irsg@irtf.org>
Content-Type: multipart/alternative; boundary="000000000000c47cc205ee4e08df"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/e9yTqB7BAD0CFn59jgc4bzrA76M>
Subject: Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guidelines-13
X-BeenThere: hrpc@irtf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: hrpc discussion list <hrpc.irtf.org>
List-Unsubscribe: <https://www.irtf.org/mailman/options/hrpc>, <mailto:hrpc-request@irtf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/hrpc/>
List-Post: <mailto:hrpc@irtf.org>
List-Help: <mailto:hrpc-request@irtf.org?subject=help>
List-Subscribe: <https://www.irtf.org/mailman/listinfo/hrpc>, <mailto:hrpc-request@irtf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Nov 2022 16:30:11 -0000
Thanks to Brian and Jane for these reviews! Gurshabad and Niels have taken those suggestions as per the thread and issued a new version. Brian and Jane, please can you give us an indication you are satisfied or further advice on how to better resolve your issues? Latest version: https://datatracker.ietf.org/doc/draft-irtf-hrpc-guidelines/ Thanks everyone, -Mallory On Thursday, November 10, 2022, Gurshabad Grover <gurshabad@cis-india.org> wrote: > Thank you for this detailed review! The new versions (-15 and -16) of the > drafts address your feedback. Comments in-line. > > On 9/8/2022 4:00 PM, Brian Trammell (IETF) wrote: > >> The abstract and introduction state that the document has been "reviewed, >> tried, and tested" by the RG. "Reviewed" I accept at face value, though it >> is unclear how the document was "tried and tested". Have each of the review >> categories in section 3 been run at least once by the RG/review team? >> Should the document link to some instance of each of these kinds of reviews >> (whether within the RG, or without)? >> >> > The document has been used for several reviews, yes. Added a line in the > introduction to link to a repository of such reviews. > > Section 3 seems to be missing a recommendation about who reviewers should >> be. Is this the shepherd, someone appointed by the WG chair, a cross-IETF >> group of interested people, people with more or less familiarity with the >> specifics of the context the protocol is developed in, all or none of the >> above? >> >> > Section 3 now clarifies this. > > - Sections 4.1 and 4.2 are points on a continuum, basically stating that >> "if your protocol doesn't work in all contexts in which the Internet might >> be deployed, then you're disadvantaging people"... which is true, and >> stronger IMO if stated more directly. Section 4.1 is entitled >> "connectivity" but mixes the end-to-end principle with reliability under >> bandwidth and latency challenges (though Reliability is the title of >> section 4.2). >> >> > I think we're reading this a bit differently. Connectivity is currently > addressing two (distinct, I agree) topics: > > (1) end-to-end design > (2) connectivity in low bandwidth and high latency situations > > Reliability is addressing a separate topic: fault tolerance and graceful > failure. > > - Sections 4.4 and 4.5 seem like they were originally a single section >> named Internationalization and Localization, and then were split. I'd merge >> them again, because many of the points made in one apply to the other and >> vice versa. Accessibility (section 4.18) also seems like it's following the >> same general principle -- internationalization and localization deal with >> application/presentation barriers tied to language, while accessibility in >> a protocol context deals with application/presentation barriers tied to >> mostly-nonlinguistic aspects of user experience, though in an Internet >> context accessibility generally applies to application layer protocols >> payload presentation (and the applications above them). Please consider >> treating them together. >> >> > Have arranged the sections so that Internationalization appears before > Localization. Have also added a sentence that clarifies the distinction: > "Internationalization is related to localization, but they are not the > same. Internationalization is a necessary precondition for localization." > > - Sections 4.6, 4.7, and 4.17 overlap quite a bit -- adaptability goes >> hand in hand with openness of standard and implementation, and adaptability >> and support for heterogeneity are also intrinsically linked. Perhaps these >> are third-level subsections of an overarching second-level subsection? >> >> > Have moved Adaptability to be up with Openness and Heterogeneity Support > now. Answer to the broader question about subsections below. > > - Similarly, sections 4.8-4.10 cover properties of communications security >> protocols, and then we come to section 4.11, entitled Security, and section >> 4.12 on privacy (which overlaps with Confidentiality as a property), >> followed by sections 4.13 and 4.14 on Pseudonymity and Anonymity >> (themselves privacy preserving techniques). These sections also cover >> ground covered by existing formal and informal practices in the IETF, on >> security and privacy considerations within documents. As a user of this >> document, I'd prefer this entire set of considerations to be split out into >> their own section, since unlike the other sections they do cover properties >> of the protocol and its description already covered by existing practice >> and process. What I'd like to know as an HRPC reviewer is what I need to >> look for in existing security and privacy considerations sections to find >> gaps in human rights considerations that might need to be addressed. What's >> the delta between existing S&P guidelines and th >> > ose in this document? > >> >> > The RFCs on security considerations and privacy considerations are much > more comprehensive than the exercise here, and we're primarily pointing to > readers to those. We've just summarised some important questions in this > draft. > > To be clear, I'm not suggesting that the authors and the RG restructure >> the document from a document usability standpoint; rather, I'm pointing out >> what appear to be structural issues in the document in case these are an >> indication that the RG's thinking on these points might be incomplete. Or, >> in other words, the RG did not set out to build a taxonomy, but having >> almost done so, is it worth finishing the job? >> >> > I think we're open in acknowledging that this research is not done and > dusted. Doing human rights reviews in standard-setting environments is > still an evolving practice, therefore we cannot claim we have a full > taxonomy. In previous iterations, we've restructured the draft so that > similar concepts appear together (as far as possible). We chose to > dis-aggregate topics as much as possible to stay as close to > implementations and stay away from abstractions, especially because this > document aims to provide practical guidance. It's also usually suggested in > evaluations to stick to concrete questions, and avoid high-level > concepts/groupings.[0] > > Since reviewers may only look at certain sections, the modularity makes > them self-contained pieces of advice on different topics. Overall, at this > point, we're hesitant to combine sections or create subheadings, because we > see benefit in keeping even related sections separate. > > - Section 4.16 Outcome Transparency asks what appears to me to be an >> impossible question. I'm of course aware of the harms of unintended >> consequences, but I'm not sure how I, as a protocol designer, could >> usefully apply this question to my work. The only wise answer to "are the >> effects of your protocol fully and easily comprehensible...?" is "no", and >> no action I can take not involving a time machine will flip it to "yes". So >> this observation probably belongs in the frontmatter of section 4, as >> opposed to being a guideline itself. Section 4.21 is similarly difficult to >> actually apply: it seems to reduce to "have you thought of anything you >> haven't thought of yet?", which is tautologcially "no". >> >> > Thank you. You're right, we've fixed the phrasing as now encouraging folks > to document expected outcomes instead. > > - Section 4.20 points to an unsolved (and at first glance very difficult >> to solve) problem in providing recourse to remedy, which is an interesting >> point, but maybe not a guideline per se. >> >> > Yes, this was a contentious one in the group. We have no concrete > guideline, but believe that the current text represents the rg consensus. > > Throughout section 4, I found the choice of which rights were impacted by >> which consideration to be mostly arbitrary, in that in most cases I >> couldn't come up with a convincing argument for why the impacts listed were >> tied to the guideline at hand, or a good reason why a missing impacted >> right was missing. The most glaring of these: section 4.12 "Privacy" does >> not list the "Right to Privacy" as impacted, which seems... incorrect. It's >> not clear to me that the Impacts sections are all that useful, though, >> unless someone is trying to pick and choose which human rights not to care >> about (not a use case we should optimize for, IMO), so might be painlessly >> omitted. >> >> > The objective of this exercise was to also clearly establish that these > properties are linked to specific human rights. Given that human rights are > not atomic, but individisble and interrelated, we admit that it is > difficult to be comprehensive in those sections though. Happy to correct > obvious mistakes, like the one you pointed to. > > and as promised, one editorial nit: section 3.1 appears to incorrectly >> cite section 3.3 as the source of guidelines; this should point to section >> 4. >> >> > Thanks for catching that, fixed! > > Again, many thanks for an informative, well-written, and useful document, >> and I hope these comments are similarly useful to you. >> >> > We found this review quite useful. Thanks again, and please let us know if > the changes are to your satisfaction. > > -Gurshabad and Niels > > [0] https://www.sciencedirect.com/science/article/pii/S107158191 > 0000972?casa_token=TjtLihpb6iMAAAAA:_I6AtjHcLtQch3- > tyB0tzJTgT_3iV_zqaJ8_Tec2wFh5lz86gWklnoBeAbXDqx8V9pZwKhoczw > _______________________________________________ > hrpc mailing list > hrpc@irtf.org > https://www.irtf.org/mailman/listinfo/hrpc > -- Mallory Knodel CTO, Center for Democracy and Technology gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780
- [hrpc] Review of draft-irtf-hrpc-guidelines-13 Brian Trammell (IETF)
- Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guide… Jane Coffin
- Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guide… Colin Perkins
- Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guide… Gurshabad Grover
- Re: [hrpc] Review of draft-irtf-hrpc-guidelines-13 Gurshabad Grover
- Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guide… Mallory Knodel
- Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guide… Brian Trammell (IETF)
- Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guide… Niels ten Oever
- Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guide… Jane Coffin
- Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guide… Mallory Knodel
- Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guide… Colin Perkins