IANA for additional fields

list of existing implementation

Clarify this current best practices (next version -> innovation)

Version field proposal (as optional) to ensure potential extension,

Point to consider:

• Existing implementation if a new mandatory field is introduced
• Making optional would be a cleaner option (and have a fall-back statement regarding the version if not present)

sensor -> first sensor (seen) - ensuring this is OPTIONAL

Majority of Passive DNS servers are usually returning seconds. Optional millisecond value is a possibility.

The additional fields registry at https://github.com/adulau/pdns-qof/wiki/Additional-Fields contains three fields that have long since been added to the COF draft: sensor_id, zone_time_first, and zone_time_last. I suggest that they be removed from the registry or an additional column be added to the registry table showing the draft version number or RFC number in which each additional field was added to the I-D or RFC (as/if becomes applicable).

Privacy Considerations update for the GDPR

Should we include TTL?

• An implementation is doing an average of the TTL
• It's challenging on the aggregation aspect (median, average, mean)
• Maybe an optional field clearly describing the algorithm used
• ttl_min / ttl_max
• appendix for additional clarification

I think the Overview section and mentions of JSON formatting might need some changes or clarification:

Most people reading this document might get stuck on the exact kind of JSON being used because their parsers will not be explicitly compatible. This document seems to outline the use of Newline Delimited JSON ("application/x-ndjson"), not normal JSON.

The examples in Appendix A do not follow the examples in RFC4627; there is a missing array wrapper around the JSON objects and missing comma separators between objects.

I'd like to recommend the mentions of JSON being changed to JSON-ND or NDJSON or JSON-L. An alternative would be a clarification added to this Overview section that a streaming client is required and JSON parsing is on a per-object basis instead of a whole-response basis.

jq endorses this demo (https://jqplay.org/) for web browsers and it is not compatible with the current examples and definition as-is. The built-in JSON parsers in web browsers and NPM are also not compatible right now.

Open discussion: classification TLP - IEP in the output

.... or remove it, since the authoritative file is the .xml file.
Thx!

So far we only documented the common output format

As the output format pdns-qof is newline separated, should we define a new mime-type?

• http://jsonlines.org/ - discussion wardi/jsonlines#9
• https://github.com/ndjson/ndjson-spec

Maybe it's time to ask for a specific mime-type?

Potential future section to add