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

[Jane Coffin <[e-mail]>]

Hi All -

I have done a review of the HRPC guidelines doc as well.
Please see the attached.

Jane

On Thu, Sep 8, 2022 at 1:30 PM Brian Trammell (IETF) <[e-mail]>
wrote:

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