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

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

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 <[e-mail]> 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/" rel="nofollow">https://datatracker.ietf.org/doc/draft-irtf-hrpc-guidelines/

Thanks everyone,

-Mallory

On Thursday, November 10, 2022, Gurshabad Grover <[e-mail]> 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" target="_blank" rel="nofollow">https://www.sciencedirect.com/science/article/pii/S1071581910000972?casa_token=TjtLihpb6iMAAAAA:_I6AtjHcLtQch3-tyB0tzJTgT_3iV_zqaJ8_Tec2wFh5lz86gWklnoBeAbXDqx8V9pZwKhoczw
_______________________________________________
hrpc mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/hrpc" target="_blank" rel="nofollow">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