Re: [hrpc] [irsg] Review of draft-irtf-hrpc-guidelines-13
Jane Coffin <jane@connecthumanity.fund> Wed, 07 December 2022 19:57 UTC
Return-Path: <jane@connecthumanity.fund>
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 ECB87C152560 for <hrpc@ietfa.amsl.com>; Wed, 7 Dec 2022 11:57:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.895
X-Spam-Level:
X-Spam-Status: No, score=-6.895 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=connecthumanity-fund.20210112.gappssmtp.com
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 6JWXjwH3YAtG for <hrpc@ietfa.amsl.com>; Wed, 7 Dec 2022 11:57:53 -0800 (PST)
Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (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 96EF5C1524C9 for <hrpc@irtf.org>; Wed, 7 Dec 2022 11:57:09 -0800 (PST)
Received: by mail-ot1-x329.google.com with SMTP id q18-20020a056830441200b006704633f258so5606629otv.0 for <hrpc@irtf.org>; Wed, 07 Dec 2022 11:57:09 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=connecthumanity-fund.20210112.gappssmtp.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=9W1RQFHtqcsmrMg5Dig96irRKLzbCIGWkDhRdVsFt44=; b=ft0JNOr63V58xKio8euOBWqJmFLBm9dprX5I/bvKBYGnwAbiGlFwyEpDJhpb9BQ4sT ujQNgDslcIpjsVrIBOJ8uhXoT6qTjHpwqKXGhmwjuAwKZivrqT6RtH6nMuP4gJsw41x8 1BsFUA5VBYv/eevM1TDvkHiPQX01IIWOYceVAfy/1/i859eCz5oGbamppUhsjMpchKL8 KbJMH/yYyLNpvXZ1ATmSGtaw43ETALva9ckAF9sAd1zLJJWdT4fundX4vBUMVH+2VOxA Rlhn7rJ2DZnVo54OYrquaU49EvjGNeWEFYNAczbW109spVfgIFcmVX5/fFNfVv+FpJQg Y8dg==
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:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=9W1RQFHtqcsmrMg5Dig96irRKLzbCIGWkDhRdVsFt44=; b=Q0avmY6W/KIAbpzFS6AqopZzwRQm3set6zUHt61rM3s1163kKUNZPlw3iRZkrQcR/o K7Auzf76tTnJnoiR01MreXSzdiV73OZOyHTLlYkU+6FL+BSM8KvHnFbDL8n5ZtwsLc+z jMGQa1vqEAg2zu3JJyAfoPx9VKvQ6jfmbV5ToYyiSL/IUMi+pDCIHEyXsOshUg7S7PA1 ZRdORTUlqZ0MxsVOzcXFacVfcWc2x6U2ENFTahlj0XYNgwSuCoszL+SpxsrWN3TZvZHf glOcoNIlGYnTGEZVCGPy+qLuZiHj0QlgDzP+nXpn2L1JaIBHJNqWMz/N5plAkpThUHD6 CvSg==
X-Gm-Message-State: ANoB5ploBA7jbWWr2qOCbFxGsIFTw8CJbRP//462g2g/hPECSMR976vU Ke+HQKvKXmW2oCGS+qI4OBRIgFAS67B0eQsaOwxuWw==
X-Google-Smtp-Source: AA0mqf6bodS2Bj3RPSEqzFrHu0KOD9ajybHU1BGIqQP35PnoZTzwYYgQD+FOi/wK15ERh7reMBGNPV5a0ix/JxFUxpc=
X-Received: by 2002:a05:6830:118a:b0:66e:6dc2:cc1c with SMTP id u10-20020a056830118a00b0066e6dc2cc1cmr17054479otq.316.1670443028812; Wed, 07 Dec 2022 11:57:08 -0800 (PST)
MIME-Version: 1.0
References: <CAGVFjMKB6RXZNy5hCF+w38_C+DTbXg4N0gTzjxbMdC=VRmL8Ag@mail.gmail.com> <5971A2E9-4FDC-475D-A8F1-C334B856C1DB@trammell.ch>
In-Reply-To: <5971A2E9-4FDC-475D-A8F1-C334B856C1DB@trammell.ch>
From: Jane Coffin <jane@connecthumanity.fund>
Date: Wed, 07 Dec 2022 14:56:58 -0500
Message-ID: <CAAk_8j2z6=bHaOLmo5xU57J0KMTreGSG=vyiWPpS4fFjms=yLg@mail.gmail.com>
To: "Brian Trammell (IETF)" <ietf@trammell.ch>
Cc: Mallory Knodel <mknodel@cdt.org>, Gurshabad Grover <gurshabad@cis-india.org>, hrpc@irtf.org, draft-irtf-hrpc-guidelines@ietf.org, irsg@irtf.org
Content-Type: multipart/alternative; boundary="00000000000059ac0e05ef425315"
Archived-At: <https://mailarchive.ietf.org/arch/msg/hrpc/JNgRH0Ths8C7OaeL1VT45pe_HWo>
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: Wed, 07 Dec 2022 19:57:58 -0000
Apologies from me as well for not replying sooner. The diff version addresses comments and edits that I had. I appreciate the work that went into this. I, too, am satisfied that the guidelines are ready for publication. Best, Jane On Fri, Nov 25, 2022 at 11:56 AM Brian Trammell (IETF) <ietf@trammell.ch> wrote: > Apologies for missing the reply on the 10th (left the meeting in London > and kind of forgot about the IRTF for a couple of weeks :) ) thanks for the > ping, Mallory! > > And many thanks Gurshabad and Niels for addressing my comments, and the > edits to the document; having reviewed the diff I’m satisfied that the > guidelines are ready for publication. > > Cheers, > > Brian > > Sent from my iPhone > > On 25 Nov 2022, at 17:30, Mallory Knodel <mknodel@cdt.org> wrote: > > 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/S1071581910000972?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