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

[Gurshabad Grover <[e-mail]>]

Thanks so much for reviewing the document!

Jane: just posted a new version (-14) of the document that addresses 
your comments and suggestions. 
<https://datatracker.ietf.org/doc/draft-irtf-hrpc-guidelines/>

Brian: Niels and I are working on -15, which will incorporate your 
feedback.

Thanks again!
-Gurshabad

On 9/27/2022 1:48 PM, Jane Coffin wrote:
> 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] 
> <mailto:[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
> 
> 
> _______________________________________________
> hrpc mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hrpc