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

[Colin Perkins <[e-mail]>]

Thanks all. Since the review comments have been addressed, I’ll now 
start the IRSG Final Poll.

Colin




On 7 Dec 2022, at 19:58, Mallory Knodel wrote:

> 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