IETF conflict review for draft-irtf-hrpc-research
conflict-review-irtf-hrpc-research-00

The following approval message was sent
From: The IESG
To: hrpc-chairs@ietf.org,
    Allison Mankin ,
    Internet Research Steering Group ,
    draft-irtf-hrpc-research@ietf.org,
    irtf-chair@irtf.org
Cc: IETF-Announce ,
    The IESG ,
    iana@iana.org
Subject: Results of IETF-conflict review for draft-irtf-hrpc-research-14

The IESG has completed a review of draft-irtf-hrpc-research-14 consistent
with RFC5742.

The IESG has no problem with the publication of 'Research into Human Rights
Protocol Considerations'  as an
Informational RFC.

The IESG has concluded that this work is related to IETF work done in many
working groups, but this relationship does not prevent publishing.

The IESG would also like the IRTF to review the comments in the datatracker
related to this document and determine whether or not they merit
incorporation into the document. Comments may exist in both the ballot and
the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-irtf-hrpc-research/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-irtf-hrpc-research/

The process for such documents is described in RFC 5743

Thank you,

The IESG Secretary

[Ballot comment]
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)/

Section 5.2.3.1.2

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 5.2.3.3.2.

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.

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

Section 5.3.6.2
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/
s/considerig/considering/

Section 5.2.3.6.5
Can you break this into a couple of sentences?

[Ballot comment]
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 ... :-)