- Did you have a look at the guidelines in Section 7 of [RFC6973] ("Privacy Considerations for Internet Protocols")? - Could your protocol in any way impact the confidentiality of protocol metadata? - Could your protocol counter traffic analysis? - Could your protocol improve data minimization? - Does your document identify potentially sensitive data logged by your protocol and/or for how long that data needs to be retained for technical reasons?

- If your protocol impacts packet handling, does it use user data (packet data that is not included in the header)? - Does your protocol make decisions based on the payload of the packet? - Does your protocol prioritize certain content or services over others in the routing process? - Is the protocol transparent about the prioritization that is made (if any)?

- Did you have a look at [BCP72] ("Guidelines for Writing RFC Text on Security Considerations")? - Have you found any attacks that are somewhat related to your protocol yet considered out of scope for your document? - Would these attacks be pertinent to the features of the Internet that enable human rights (as described throughout this document)?

- Does your protocol have text strings that have to be understood or entered by humans? - Does your protocol allow Unicode? If so, do you accept texts in one charset (which must be UTF-8) or several (which is dangerous for interoperability)? - If character sets or encodings other than UTF-8 are allowed, does your protocol mandate proper tagging of the charset? - Did you have a look at [RFC6365]?

- Does this protocol introduce new identifiers or reuse existing identifiers (e.g., Media Access Control (MAC) addresses) that might be associated with persons or content? - Does your protocol make it apparent or transparent when access to a resource is restricted? - Can your protocol contribute to filtering in such a way that it could be implemented to censor data or services? If so, could your protocol be designed to ensure that this doesn't happen?

- Is your protocol fully documented in such a way that it could be easily implemented, improved, built upon, and/or further developed? - Do you depend on proprietary code for the implementation, running, or further development of your protocol? - Does your protocol favor a particular proprietary specification over technically equivalent and competing specification(s) -- for instance, by making any incorporated vendor specification "required" or "recommended" [RFC2026]? - Do you

- Does your protocol support heterogeneity by design? - Does your protocol allow for multiple types of hardware? - Does your protocol allow for multiple types of application protocols? - Is your protocol liberal in what it receives and handles? - Will your protocol remain usable and open if the context changes? - Does your protocol allow well-defined extension points? If so, do these extension points allow for open innovation?

- Did you have a look at [RFC6973] ("Privacy Considerations for Internet Protocols"), especially Section 6.1.1 of that document?

- Have you considered [RFC6973] ("Privacy Considerations for Internet Protocols"), especially Section 6.1.2 of that document? - Does the protocol collect personally derived data? - Does the protocol generate or process anything that can be, or that can be tightly correlated with, personally identifiable information? - Does the protocol utilize data that is personally derived, i.e., derived from the interaction of a single person or from their device or address? - Does this p

- Is your protocol designed to provide an enabling environment for people who are not able-bodied? - Have you looked at the W3C Web Accessibility Initiative [W3CAccessibility] for examples and guidance?

- Does your protocol uphold the standards of internationalization? - Have you taken any concrete steps towards localizing your protocol for relevant audiences?

- Can your protocol be implemented without one single point of control? - If applicable, can your protocol be deployed in a federated manner? - What is the potential for discrimination against users of your protocol? - Can your protocol be used to negatively implicate users (e.g., incrimination, accusation)? - Does your protocol create additional centralized points of control?

- Is your protocol fault tolerant? - Does your protocol degrade gracefully? - Can your protocol resist malicious degradation attempts? - Do you have a documented way to announce degradation? - Do you have measures in place for recovery or partial healing from failure? - Can your protocol maintain dependability and performance in the face of unanticipated changes or circumstances?

- Does this protocol expose information related to identifiers or data? If so, does it do so to each of the other protocol entities (i.e., recipients, intermediaries, and enablers) [RFC6973]? - What options exist for protocol implementers to choose to limit the information shared with each entity? - What operational controls are available to limit the information shared with each entity? - What controls or consent mechanisms does the protocol define or require before personal data or ident

- Do you have sufficient measures in place to confirm the truth of an attribute of an entity or of a single piece of data? - Can attributes get garbled along the way (see Section 6.2.4 ("Security"))? - If relevant, have you implemented IPsec, DNSSEC, HTTPS, and other standard security best practices?

- Is your protocol written in such a way that it would be easy for other protocols to be developed on top of it or to interact with it? - Does your protocol impact permissionless innovation (see Section 6.2.1 ("Connectivity") above)?

- Are the effects of your protocol fully and easily comprehensible, including with respect to unintended consequences of protocol choices?