IETF conflict review for draft-irtf-hrpc-research

Note: This ballot was opened for revision 00 and is now closed.

Ballot question: "Is this the correct conflict review response?"

(Deborah Brungard) Yes

(Ben Campbell) Yes

(Spencer Dawkins) Yes

Comment (2017-08-24)
No email
send info
Just to be clear on why I proposed this response - the underlying IRTF document analyses a large number of IETF protocols for impact on human rights, across most areas, including some protocols that are actively under development now, and proposes a checklist of human rights considerations for protocol work in Section 6. So, it is related to IETF work, but does not fall under any of the other possible conflict review responses.

"I hope everyone reads Section 6" isn't an allowable conflict review response, but I hope people do ... :-)

(Suresh Krishnan) (was No Objection) Yes

(Mirja Kühlewind) Yes

(Terry Manderson) Yes

(Alexey Melnikov) Yes

(Kathleen Moriarty) Yes

Comment (2017-08-31)
No email
send info
Thank you for all of the work that went into this draft, which is clearly well researched and will serve as helpful guidance in protocol development considering human rights.  I read through the document and have a couple of comments and found a few nits.  I hope this is helpful.

Section 3
s/Internet Research Taskforce (IRTF)/Internet Research Task Force (IRTF)/


Address translation section - While I agree with the end-to-end principle, I’m curious as to how the draft got to the current phrasing since it’s people that program the router and the decisions around NAT are decided by that programming and apply to groups of addresses typically (all) behind a device. As such a layer of anonymity is provided for the users behind the NAT device with only those with access to the NAT device having knowledge of the mapping.  In some cases that might hinder assembly, but I would think it would enhance it in others.

I’m also not sure how NAT relates to forward routing as described in the previous sentence.  The routing rather than translation would be responsible for correct routing decisions.  If your talking about something malicious or deliberate to impact users, I think separating that out from the technology is important.  It is entirely possible and a concern, so stating it in a way that makes sense would be good.  It probably fits better in section

Here’s the text:
   This process puts the router performing the
   translation into a privileged position, where it can decide which
   subset of communications are worthy of translation, and whether an
   unknown request for communication will be correctly forwarded to a
   host on the other network.

Wouldn’t saying the following be more accurate:
   This process puts the router performing the
   translation into a privileged position, where it is predetermined which
   subset of communications will be translated.  

Then perhaps a statement on those responsible for programming the device to get at your other points?  The rest of the text in this section reads fine and specific to the technology.

S/peer-to-peer remains imporant/peer-to-peer remains important/

This paragraph could use some additional work, but here’s a few glaring typos/edits:
First sentence - drop the last word “to”.
s/retain logs for long enough/retain logs long enough/

Can you break this into a couple of sentences?

Alvaro Retana Yes

(Adam Roach) Yes

(Benoît Claise) No Objection

Comment (2017-08-31)
No email
send info
Interesting read (I browsed through the doc and spent more time on section 6, Spencer).

Warren Kumari No Objection