Currently, bson redaction keeps keys and hides (non-sub-object) values. For oplog entries where the actual application data is enveloped, some values can conceivably be displayed. This information would be useful when trying to put a timeline of what a node is doing when diagnosing issues.

I don't know where the dividing line would be on what can and cannot be persisted to a log file, but perhaps in order of usefulness:

• The `ts` and `t` fields (timestamp and term)
  <falling off a steep cliff of usefulness, to me>
• `op` (operation type, e.g: insert/update...)
• `ui` (collection uuid)
• `ns` (collection namespace)
  <another cliff>
• `lsid` (logical session id)

I don't believe we can intelligently determine when a redaction is for an oplog entry. What would certainly satisfy my intention is to have a method that redacts a BSONObj as if it were an oplog entry and a brief/best effort scan of repl logging code to use the new method. If the functionality exists, we can convert log lines as they become identified.