Security use cases

[LPardue]

          This first sentence is not precise about whether it refers to the logging use case or the use case of the logged exchange.

Originally posted by @martinthomson in https://github.com/quicwg/qlog/pull/353#discussion_r1410158849

[LPardue]

also see https://github.com/quicwg/qlog/pull/353/files#r1410163988 where the text says

Operator and implementers need to balance the value of logged data against 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).

and Martin comments

It seems like the difference in these examples is WHO has access to the data and the level to which the different entities might be trusted, so maybe this isn't so much about use cases.

[rmarx]

It could be I'm conflating the things sure, but from my perspective, research datasets from e.g., active measurements, are obtained for a very different "use case" than generic operational logs.

Similarly, for the research "use case" you need more in-depth data (e.g., to do in-depth debugging) than for the operational "use case".

So I can see where the comment is coming from, but I'm not sure I agree it's mainly about WHO has access to the data, decoupled from the use case...

[rmarx]

As part of https://github.com/quicwg/qlog/pull/364, the original sentence:

Any data that is determined to be necessary for a use case at hand could be logged or captured.

was edited into

Depending on the observability use case any data could be logged or captured.

I personally think this adequately clarifies which "use case" we're talking about in the original text of this issue.

HOWEVER it does not really address the other point in the 2nd comment:

It seems like the difference in these examples is WHO has access to the data and the level to which the different entities might be trusted, so maybe this isn't so much about use cases.

As that part of the text is still:

Operators and implementers should balance the value of logged data with the
potential risks of (involuntary) disclosure, which can depend on use cases
(e.g., research datasets might have different requirements to live operational
troubleshooting).

That imo might be fixed by doing something like (last sentence part added):

Operators and implementers should balance the value of logged data with the
potential risks of (involuntary) disclosure, which can depend on use cases
(e.g., research datasets might have different requirements to live operational
troubleshooting) **and/or which entities have access to the data.** 

if you agree @LPardue, I'll make a PR for that change and we can close this issue with it.

[LPardue]

I'm not sure that addional fragment helps much. I took a stab at something a little different, in case it works or inspires you.