Gratuitous use of "Note:"

[LPardue]

There's almost 60 notes spread across the three documents. This is too many.

I suspect some of these are note to author, and should be resolved with due process. However, many just seem to be prose that applies directly to the subject matter. Qlog is a bit odd in so far as it's a data scheme definition with few normative requirements but I don't think that warrents us explicitly marking things as notes. Let's just write clear text inside.

[rmarx]

Agreed. I could use a "how to write prose for IETF documents"-guide though. Does something like that exist?

[LPardue]

There's RFC editor pages like https://www.rfc-editor.org/styleguide/ which has some links to things like https://www.rfc-editor.org/rfc/rfc7322.txt. But I suspect they don't target the kind of advice you're aiming for. Style comes from borrowing from other comtemporary drafts, and taking suggestions from co-editors, the WG, the IETF and the RFC editor.

If these notes would be similar to footnotes in a book, it probably isn't acceptable to readers open a blank chapter and see multiple footnotes. Putting normative statements in RFC notes just seems bad, because they could be missed or ignored by a reader.

A quick win is remove all note: prefixes unless they specifically relate to an editorial or design matter with the document. Then convert all editorial or design notes into actual issues before deleting them.

[LPardue]

Furthermore, a subjective opinion is that an RFC doesn't need to justify every decision in the document.

So take for example these notes from https://quicwg.org/qlog/draft-ietf-quic-qlog-quic-events.html#section-3.3.15

Note: we do not for example use a "direction" field (with values "up" and "down") to specify the data flow. This is because in some optimized implementations, data might skip some individual layers. Additionally, using explicit "from" and "to" fields is more flexible and allows the definition of other conceptual "layers" (for example to indicate data from QUIC CRYPTO frames being passed to a TLS library ("security") or from HTTP/3 to QPACK ("qpack")).

Note: this event type is part of the "transport" category, but really spans all the different layers. This means we have a few leaky abstractions here (for example, the stream_id or stream offset might not be available at some logging points, or the raw data might not be in a byte-array form). In these situations, implementers can decide to define new, in-context fields to aid in manual debugging.

This could possibly be simplified down to a statement like:

The data_moved event is defined in the transport category but the "from" and "to" fields can be extended with values to provide flexibility for logging data movements between layers that don't involve the transport. For example, moving data between the HTTP/3 and QPACK components that both reside in the application layer.

[LPardue]

Removed 99% of note:s as they stick out. We can fix more-specific concerns as followup