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

[Mallory Knodel <[e-mail]>]

Thanks so much to Jane and Brian and the IRSG for the reviews! -M

On Wednesday, December 7, 2022, Jane Coffin <[e-mail]>
wrote:

> Apologies from me as well for not replying sooner.
> The diff version addresses comments and edits that I had.  I
> appreciate the work that went into this.
> I, too, am satisfied that the guidelines are ready for publication.
>
> Best,
> Jane
>
> On Fri, Nov 25, 2022 at 11:56 AM Brian Trammell (IETF) <[e-mail]>
> wrote:
>
>> 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/
>>
>> 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_Tec2wFh5lz86gWklnoBeAbXDqx8V9p
>>> ZwKhoczw
>>> _______________________________________________
>>> hrpc mailing list
>>> [e-mail]
>>> 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
>>
>>
>>

-- 
Mallory Knodel
CTO, Center for Democracy and Technology
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9 B071 0C32 A271 BD3C C780