Re: [HR-rt] Fwd: Notes from human rights review team november 4th IETF 103 - quick question

[Mallory Knodel <[e-mail]>]

Thanks Corinne,

Another suggestion that's come later is to make the reviews more
findable. We could:

 * Link to the reviews uploaded to gitlab from hrpc.io
 * Publish blogs on each review in hrpc.io
 * Something else.

Keen to find a way forward and operationalise this.

-Mallory

On 05/11/2018 12:59, Corinne Cath wrote:
> Dear all,
> 
> Please find below my notesof our meeting yesterday. They're quite long
> but so was the meeting. 
> 
> Let me know if I missed anything. I also added them in a doc below. 
> 
> Best,
> 
> Corinne 
> 
> 
> *Notes Human rights review team 4 November *
> 
> /Present: Niels, Mallory, Shivan, Juliana, Gurshabad, Corinne /
> 
>  
> 
> _Agenda:_
> 
> /Reviews/
> 
> /Lessons learned/
> 
> /Guidelines draft updates (new version)/
> 
> /Gitlab/
> 
> /Reviews as rubberstamps (legitimacy of what we are doing?)/
> 
>  
> 
> /Reviews:/
> 
> Reviews done currently:
> 
> 1)    Marnu
> 
> 2)    Meeting venue
> 
> 3)    Suit
> 
> 4)    Quic
> 
> 5)    Ipwave
> 
> 6)    Regex
> 
> 
> Upcoming reviews:
> 
> 1)    captive ports
> 
> 2)    doh/dot
> 
> 3)    WebRTC and MDNS
> 
>  
> 
> Question: How expanded do we make these reviews?  NTo will do DoH/DoT in
> one, ESNI is a different discussion. Maybe we take the information from
> the DoH/DoT and turn it in an advocacy paper?
> 
>  
> 
> Question: Why review an RFC?  Because it seems that it would be useful
> to apply our thumb on the scale. The DoH/DoT discussion is not yet
> resolved.
> 
>  
> 
> Question: Should we turn reviews into RFCs? Its dependent on the
> consensus in the group.
> 
> If we turn the reviews into RFCs that might also signal legitimacy for a
> potential issue paper.
> 
>  
> 
> Discussion: what it is the best strategy for doing advocacy at the IETF:
> issue paper or formal review. It’s easier to convince people with
> reviews than with an issue paper. But an issue paper might be relevant
> to do for the wider community. And/and approach.
> 
>  
> 
> Discussion: the audience for the reviews is a reoccurring topic of
> debate in our meeting.
> 
>  
> 
> Shivan mentions WebRTC and MDNS concerns: Mostly the draft is about
> privacy now but might have association and accessibility concerns. 
> Right now, he has comments, unclear if it’s a good fit for a formal review.
> 
>  
> 
> /Lessons learnt:/
> 
>  
> 
> ·With big and influential drafts, the interview/inductive/ethnographic
> approach works well.
> 
> ·  Gurshabad approach worked well (putting RFC 8280 next to the draft
> and match the different questions to different parts of the draft). See
> here for his approach: https://pad.riseup.net/p/fsEgWAHneHCS-keep
> 
>  
> 
> /Guidelines draft updates (new version):/
> 
> 1)    Are people engaging with it?
> 
> 2)    Are people still updating it?
> 
> 3)    Where is it going?
> 
>  
> 
> There are some changes to the guidelines – people who do human rights
> reviews should be updating the RFC 8280. When it was written RFC 8280
> was all fiction and speculative, it was done without doing any reviews.
> 
>  
> 
> What is the projection for where this is going and how we frame it for
> people?
> 
>  
> 
> Gurshabad suggested:
> 
> -   Mentioning that we do other stuff besides protocols
> 
> - The preferable answers should be yes (and) to the questions (up for
> discussion)
> 
> - Guidelines could have an appendix with different review examples.
> 
>  
> 
> We should consider updating the guidelines with:
> 
> -       NTo approach
> 
> -       Gurshabad approach
> 
> -       Amelia approach
> 
>  
> 
> Discussion: should we consider adding a “green consideration” for the
> environmental impacts of a protocol?
> 
>  
> 
> We can start thinking about new frames and flavors to bring in for
> reviews, like we did with feminism:
> 
> -       UNGP
> 
> -       SDGs
> 
> -       Etc.
> 
> 
> /Gitlab:/
> 
> Discussion: do we do each or some reviews as a project on gitlab?  Maybe
> for big or collaborative ones have an issue tracker and tickets?
> 
>  
> 
> Because it would be a low entry place for interested people to have a
> look at what we do on a public repo and get involved. And means chairs
> and others don’t need to hassle people for what is going on with
> different reviews.
> 
>  
> 
> Maybe ask on the list if this is a good idea to:
> 
> -       Open a ticket when you start you review
> 
> -       Close it when you finish
> 
> -       And upload it to gitlab
> 
>  
> 
> /Reviews as rubberstamps (legitimacy of what we are doing?)/
> 
> Discussion: why should people care about our reviews? This came up in
> response to some of the reviews we did. Where people questioned why they
> should care about our reviews. IRTF chair suggested some changes the
> introduction language of reviews. Right now: We find people who are
> doing good work and review that (that’s why we review MLS). But It’s
> harder to get legitimacy for bad drafts and to get people to care (Regex)
> 
>  
> 
> _To do:_
> 
> -  Further conversation about issue paper on DoH/DoT
> 
> -  Bring some of the discussion points to the HRPC meeting
> 
> -  Talk more about who our audiences are for the reviews
> 
> - Further develop the draft guidelines (add NTo, Gurshabad, and Amelia
> approaches)
> 
> -  Ask list what they think about doing reviews on gitlab
> 
> - Give more thought about what our legitimacy model is for reviews
> 
> * *
> 
> 
> 
> -- 
> Corinne Cath - Speth
> Ph..D. Candidate, Oxford Internet Institute & Alan Turing Institute
> 
> Web: www.oii.ox.ac.uk/people/corinne-cath
> <http://www.oii.ox.ac.uk/people/corinne-cath>
> Email: [e-mail] <mailto:[e-mail]> &
> [e-mail] <mailto:[e-mail]>
> Twitter: @C_Cath
> 
> _______________________________________________
> HR-rt mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/hr-rt
> 


-- 
Mallory Knodel
Head of Digital :: article19.org
gpg fingerprint :: E3EB 63E0 65A3 B240 BCD9  B071 0C32 A271 BD3C C780