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

["Brian Trammell (IETF)" <[e-mail]>]

Greetings, all,

I've reviewed draft-irtf-hrpc-guidelines-13 for the IRSG. 

I believe the document is on the right track, and thank the authors and the RG for what has clearly been a lot of work. However, in my opinion the document still needs a bit more work, or at least consideration, before it is ready for publication as an IRTF RFC. 

tl;dr: section 4 is a very useful discussion, but I think the document and the work would benefit from a more systematic examination of the guidelines in section 4, which will probably lead to changes in structure more than changes in content.

Indeed, the document is quite useful in its current state, and I quite enjoyed reading it. Though it claims not to be a taxonomy or an exhaustive study, the considerations in section 4 seem pretty thorough to me. The rest of my comments follow in no particular order, though I'll save purely editorial comments for the end.

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)?

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?

Though happy with its completeness, I found myself unsatisfied with the structure of section 4, and I wonder whether this is an editorial issue or a signal of something deeper. Certain subsections of section 4 can be naturally grouped together -- in some cases, leading me to wonder whether they should be merged. Other subsections tie pretty deeply into existing processes (formal or cultural) within the IETF, which raises the question of whether the document should directly address the gaps between these processes and their ideal, from a human rights standpoint.

Specifically:

- 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).

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

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

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

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?

That said, there are a couple of guidelines that stand out to me as less applicable, specifically:

- 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".

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

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. 

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.

Again, many thanks for an informative, well-written, and useful document, and I hope these comments are similarly useful to you.

Cheers,

Brian