Change:
[10] https://github.com/quiclog/quictrace2qlog [11] https://qvis.edm.uhasselt.be <del> [12] https://huitema.wordpress.com/2020/07/21/scrubbing-quic-logs- for-privacy/ </del>

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!