Change:
9. <del> TODO : discuss privacy and security considerations (e.g., what NOT to log, what to strip out of a log before sharing, ...) TODO: strip out/don't log IPs, ports, specific CIDs, raw user data, exact times, HTTP HEADERS (or at least :path), SNI values TODO: see if there is merit in encrypting the logs and having the server choose an encryption key (e.g., sent in transport parameters) Good initial reference: Christian Huitema's blogpost [12] </del> <ins> Protocols such as TLS RFC8446 and QUIC RFC9000 provide varying degrees of secure protection for the wire image RFC8546.  There is inevitably tension between security and observability, when logging can reveal aspects of the wire image, that would ordinarily be protected.  This tension equally applies to any privacy considerations that build on security properties, especially if data can be correlated across data sources. qlog operators and implementers should be mindful of the security and privacy risks inherent in handling qlog data.  This includes but is not limited to logging, storing, or using the data.  Data might be considered as non-sensitive, potentially-sensitive, or sensitive; applying the considerations in this section may produce different risks depending on the nature of the data itself, or its handling. However, in many cases the largest risk factors arise from data that can be considered as potenially-sensitive or sensitive. The following is a non-exhaustive list of such fields and types of data that can be carried in qlog data: IP addresses and transport protocol port numbers, which can be used to uniquely identify individual connections, endpoints, and potentially users. Session, Connection, or User identifiers which can be used to correlate nominally separate contexts.  For example, QUIC Connection IDs can be used to identify and track users across geographical networks RFC9000). Stored State which can be used to correlate individual connections or sessions over time.  Examples include QUIC address validation and retry tokens, TLS session tickets, and HTTP cookies. Decryption keys, passwords, and tokens which can be used with other data sources (e.g., captures of encrypted packets) to correlate qlog data to a specific connection or user or leak additional information.  Examples include TLS decryption keys and HTTP-level API access or authorization tokens. Data that can be used to correlate qlogs to other data sources (e.g., captures of encrypted packets).  Examples include high- resolution event timestamps or inter-event timings, event counts, packet and frame sizes. Full or partial encrypted raw packet and frame payloads, which can be used with other data sources (e.g., captures of encrypted packets) to correlate qlog data to a specific connection or session. Full or partial plaintext raw packet and frame payloads (e.g., HTTP Field values, HTTP response data, TLS SNI field values), which can contain directly sensitive information. The simplest and most extreme form of protection against abuse of this information is the complete deletion of a given field, which is equivalent to not logging the field(s) in question.  While deletion completely protects the data in the deleted fields from the risk of compromise, it also reduces the utility of the dataset as a whole. As such, a balance should be found between logging these fields and the potential risks inherent in their (involuntary) disclosure.  This balance depends on the use case at hand (e.g., research datasets might have different requirements to live operational troubleshooting).  Capturing the minimal amount of data required for a specific purpose can help to minimize the risks associated with data usage. qlog implementations that provide fine-grained control over the inclusion of data fields, ideally on a per-use-case or per- connection basis, improve the ability to minimize data. Any data that is determined to be necessary for a use case at hand could be logged or captured.  As per RFC6973, operators must be aware that such data will be at risk of compromise.  As such, measures should be taken to firstly reduce the risk of compromise and secondly reduce the risk of abuse of compromised data.  While a full discussion of both aspects is out of scope for this document, the following paragraphs discuss high-level considerations that can be applied to qlog data. To reduce the risk of compromise, operators can take measures such as: limiting the length of time that data is stored, encrypting data in transit and at rest, limiting access rights to the data, and auditing data usage practices. qlog deployments that provide integrated options for automated or manual data deletion and (aggressive) aggregation, improve the ability to minimize the risk of compromise. To reduce the risk of data abuse after compromise, data can be anonymized, pseudonymized, otherwise permutated/replaced, truncated, (re-)encrypted, or aggregated.  A partial discussion of applicable techniques (especially for IP address information) can be found in DNS-PRIVACY.  Operators should, however, be aware that many of these techniques have been shown to be insufficient to safeguard user privacy and/or to protect user identity, especially if a qlog data set is large or easily correlated against other data sources. Finally, qlog operators should consider the interplay between their use case needs and end user rights or preferences.  While active user participation (as indicated by RFC6973) on a per-qlog basis is difficult, as logs are often captured out-of-band to the main user interaction and intent, general user expectations should be taken into account. qlog deployments that provide mechanisms to integrate the capture, storage and removal of qlogs with more general, often pre-existing, user preference and privacy control systems, improve the ability to protect data sensitive or confidential to the end user.  In qlog, these data are typically (but not exclusively) contained in fields of the RawInfo type (see raw-info). qlog users should thus be particularly hesitant to include these fields for all but the most stringent use cases. </ins> 10.

Discussion:
Adding high-level discussion of privacy and security considerations operators should take into account. This will walk a fine line between being too high-level/vague and trying to do too much in a qlog document that should be done in a more general IETF document that discusses these issues for all possible log formats, not just qlog.
This is a solid start. I think it treads the line well about what should be discussed in the scope of qlog. There might be a small discussion about whether we should mention so many QUIC things in the main schema, rather than in the qlog schema, but at the moment I'd fall on the side of leaving them here.
NAME I have now processed all of your comments, with 2 that probably deserve an extra look. The overall structure is more consistent now, and concrete QUIC/TLS/HTTP mentions are now clear as examples of data types, rather than specific data fields in qlog themselves. I think this is ready for broader review (and as we discussed yesterday, a first merge into the main doc if it can be approved by the editors here). The main missing part is a proper reference to a recent differential privacy survey/discussion which I still need to research (suggestions welcome!). I will also add a section to the event documents that references back to this soon.
NAME Thank you for the review and extensive comments. In discussion with NAME and because we really wanted to have -something- about this in the new drafts, I've merged this first version of the text, including fixes for your smaller but not larger remarks, with the intent of there being continued discussion going forward. To that end, I will create 2 new issues, one for your high-level review about general structure, and one for the "user consent" remark to further track these points for future versions. Thanks again!
This is a lot of text. I like the enumeration of the types of risk, but I fear that the extrapolation from there is both incomplete and a little long-winded. The focus on anonymization is not one that I would emphasize. I know that Christian has toyed with the concept, but that was idle speculation, not anything rigorous. In the end, this text should be very clear that qlog files present a privacy risk to those participating in the connection. They should therefore be treated accordingly.

Any notion that these files might be sanitized in a way that might remove that risk should be changed to focus more on defense in depth. That is, look at access control and retention limits as primary means of protection, not anonymization. I would instead structure this roughly as follows: A brief introductory piece. An articulation of the types of privacy risk that might be presented by capture, storage, and use of qlog data. This part is fairly lengthy and could probably be a subsection. A description of the operational implications and potential actions that might be taken first from a security standpoint, then for privacy remediation. qlog files that are records of interactions with peers are data that those peers (or users) potentially have rights over (I like this point, so make it prominently, but do not refer to laws; do not refer to the GDPR especially). a. Access controls required to enable qlog or to expand the information that is captured. a. Access controls required to access stored qlog files. a. Limits to retention of qlog files. a. Finally, observe that limiting what is captured or anonymization might be possible, but that this could either be insufficient from a privacy perspective, reduce the usefulness of the data, or (highly likely) both. It's easy to focus on the point about not being able to link qlog data with people. But it's safer to treat that as an open research problem than invite implementations and deployments to indulge in amateur research on the topic.Looks good now, thanks!