Re: [hrpc] Review of draft-irtf-hrpc-guidelines-13

[Gurshabad Grover <[e-mail]>]

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 those 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