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

[Colin Perkins <[e-mail]>]

Thank you, Jane and Brian, for the detailed IRSG reviews. The authors 
should now review these comments and discuss with the IRSG reviewers, 
then update the draft as necessary.

Colin



On 27 Sep 2022, at 9:18, 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]>
> 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