[hrpc] IRTF Chair review of draft-irtf-hrpc-guidelines-10

[Colin Perkins <[e-mail]>]

The HRPC RG chairs have requested that draft-irtf-hrpc-guidelines-10 be published as an RFC on the IRTF stream. The IRTF publication process is described in RFC 5743, and comprises a review by the IRSG to ensure technical and editorial quality, followed by a check by the IESG to ensure the work does not conflict with IETF standards activities.

As IRTF Chair, I perform an initial review of all drafts submitted for publication on the IRTF stream before sending them for detailed review by the IRSG. This note provides my review comments, for discussion.


Result: Not ready

RFC 5743 compliance: The draft does not follow the guidelines in RFC 5743


Comments:

Thank you for preparing this document. It’s an interesting read, and raises a number of important questions to address when designing protocols and developing standards. I have both some high-level comments, and a larger number of more detailed comments, on the draft.

1) The UN human rights declarations are clearly important, but different countries and cultures interpret those rights and responsibilities in differing ways, and the extent to which they’re incorporated into national laws also varies. Some countries guarantee additional rights, while others try to restrict rights that are accepted elsewhere. It would help the reader if the document said more about the rights being considered and how the authors interpret them, and gave examples of how those rights are incorporated into various national laws. This would help provide context for the discussion, and may illustrate differences in interpretation of those rights around the world. Section 2 hints at some of this, but more details would provide important context for protocol designers that may not be familiar with the way the relevant rights are described, their interpretation and implications, and their practical incorporation into relevant laws and regulations. 

2) Section 3.1 seems to assume that a protocol is developed, then a human rights review is conducted. A less adversarial phrasing might be to suggest ways in which protocol designers can incorporate awareness of human rights issues into the protocol design process.

3) Section 3.2 includes a detailed list of questions to consider, to illustrate the human rights impact of various protocol design choices. The approach taken, listing questions, followed by some discussion of how the questions relate to human rights, and finally giving some examples to illustrate the issues, is good. The chosen topics are, however, not always presented in a logical order, and there is some considerable overlap between the different questions. The material would benefit from a review of the order of presentation to ensure related material is grouped together, and to reduce duplication (I accept that the nature of the material is that there will always be some overlap between topics).

4) The discussion in Section 3.2 is, at times, phrased in a manner that advocates a particular approach without acknowledging the complexity of the trade-offs that must be made, and that there are, perhaps, reasons why alternative approaches are chosen. It might be helpful to review the material to ensure a neutral point of view is adopted when presenting the questions and issues.

5) The discussion in Section 3.2 is structured in a way that it’s not always clear what actions a protocol designer can take to address the issues raised. I accept that, in many cases, the concrete action depends on the protocol being designed, but general principles can often be stated if the desire is to achieve a certain outcome. Similarly, highlighting principles that are in conflict, where a trade-off may exist between different goals, is important. 



Specific comments on details follow:

RFC 5743 requires certain statements be present in the Abstract and Introduction to the draft. The draft includes these in the Abstract, but not the Introduction.

§1: “The understanding of what human rights are is based on the Universal Declaration of Human Rights and subsequent treaties that jointly form the body of international human rights law“ – The UN UDHR is easy to find, of course, but it would be helpful to reference the subsequent treaties considered. Section 2 has some additional references, but their status is not always clear.


Editorial: the organisation of the document might be clearer if Sections 3.1 and 3.2 were promoted to be top level sections.


Section 3.2.1 considers three topics: where protocol functions are performed, how well the protocol works in certain environments, and whether state is maintained. These are all important to consider, but seem to be largely separable concerns. Separating them might allow for more nuanced discussion of each topic.

This section cites the end-to-end principle, but doesn’t discuss the implications of the choice of end points. The statement that “the end-to-end principle in protocol design is important to ensure the reliability and security” over-simplifies a complex set of concerns around service placement, the different types of security being provided, and how reliability and availability are ensured.

“Considering the fact that network quality and conditions vary across geography and time, it is also important to design protocols such that they are reliable even on low bandwidth and high latency connections” – not all protocols need to be reliable in any conditions, and certain services require some minimum set of resources to be able to operate. There’s perhaps a more nuanced discussion that can be had around understanding the conditions under which a protocol will operate, how it can scale / gracefully degrade across a range of conditions, and what are the implications of the scaling limitations?


Section 3.2.2 mentions confidentiality of metadata but not of data. The discussion would benefit from a discussion of potential threat models: privacy for whom, and against what adversaries? 

What are the trade-offs of confidentiality vs operational needs? RFCs 7258, 7624, 8404, 8546, and 9065 seem relevant, and I’m sure there is a significant amount of related academic work. 

This section would benefit from some discussion around content moderation, wire tapping, and so on.


Section 3.2.3 gives some specific examples of prioritisation relating to low-level packet forwarding. The examples highlight cases where prioritisation is problematic, but not its potential benefits in allowing critical services to operate in environments where resources are constrained, or in supporting user preferences – there is more nuance to the argument than is expressed. 

Section 3.2.3 could usefully discuss other aspects of content agnosticism. There are difficult question around moderation, child protection, legally mandated restrictions on content, or legal requirement to prioritise certain types of content or traffic, that are not mentioned. 

Section 3.2.4 focussed on security, but that’s a very open-ended topic. The guidance might be easier to translate into concrete changes in protocol design if specific classes of attack from BCP 72 were brought into this document and discussed in more detail.

Section 3.2.5 discusses internationalisation, but seems primarily focussed on textual elements in protocol data. That’s an important aspect of internationalisation, but there are many other issues to consider. Languages, names, addresses, dates and times, can all be protocol visible information and are often treated inappropriately. There are also issues around what services and featured can be offered in particular regions, and with what protocol features and mechanisms are used to determine how to internationalise a system and decide what features/services to offer. The document would benefit from broader discussion of these topics.

Section 3.2.6 is focussed on censorship resistance, but an alternative phrasing might be to consider the implications of censorship, content filtering, moderation, and user identity and tracking on human rights. There is more depth and nuance to this topic than is suggested here, that’s important when designing protocols.

Section 3.2.7 on open standards advocates a particular approach to standards setting, but there are many widely used standards that were developed following different approaches. The document could include a more neutral discussion of the trade-offs, recognising that there are benefits as well as problems in different models of protocol standardisation, implementation, and deployment, while still highlighting the implications for human rights.

Section 3.2.8 seems to conflate heterogeneity and extensibility. A protocol may support different types of hardware and scale to meet a wide range of performance characteristics, while providing a single, non-extensible, service. Equally, a protocol may extensible in how certain features can be provided while being entirely unscalable in terms of performance. Both questions are important, but could be more effectively discussed if separated.

Section 3.2.9 is entitled pseudonymity, but the first paragraph begins with a broader discussion of personally identifiable data. That broader discussion is valuable, but this section isn’t well structured.

“consider ways to mitigate the obvious impacts” – state what are those risks. 


Section 3.2.10 discusses anonymity, and says “If your protocol collects data and distributes it (see [RFC6235]), you should anonymize the data”. The phrasing here is overly broad: an email server collects and distributes data, in the form of email messages, but shouldn’t try to anonymise those messages, for example.

Section 3.2.10: “Often protocols expose personal data, it is important to consider ways to mitigate the obvious privacy impacts” – expand on what are the privacy issues, or reference previous discussion. That is obvious to one may not be to another.

The discussion in Sections 3.2.9 and 3.2.10 seems surprisingly focussed on low-level protocol aspects. These are important, but there is also much that could be said about application level protocols. 

Section 3.2.11 would benefit from some examples relating to protocols rather than just mark-up languages. The work Gunnar Hellström has been doing in AVT/AVTCORE around timed text protocols might provide an example.

Section 3.2.12: internationalised DNS might be another example (or maybe for §3.2.5)? I was surprised that Section 3.2.5 and 3.2.12 were so far apart in the document.

Section 3.2.13 discusses decentralisation, but doesn’t clearly tie the concerns listed in the questions to the issue of centralisation of protocols. DINRG held a recent workshop on this topic (https://datatracker.ietf.org/meeting/interim-2021-dinrg-01/session/dinrg) that might inform the discussion.

Section 3.2.14 could more clearly tie the issues of protocol reliability to the identified rights. How do these issues relate to those of integrity discussed in Section 3.2.16?

Section 3.2.15 clearly identifies some issues around confidentiality, but it is less clear is how these issues are distinct from those around privacy discussed in Section 3.2.5.

Section 3.2.18 could more clearly relate issues of adaptability and permissionless innovation to human rights. I agree that the ability to extend and adapt protocols is desirable, but it’s less clear how, for example, the inability to extend a protocol impacts freedom of assembly.

Section 3.2.19 discusses outcome transparency. It’s not clear that the effects of any protocol are “fully and easily comprehensible”, and it would seem that are unintended consequences are, by definition, unpredictable. This section doesn’t seem actionable, and could maybe be removed?

Section 3.2.20 highlights the issue of Remedy, but without some examples, it’s difficult to understand how it can be applied to protocol design. 



Colin Perkins
IRTF Chair