> On 1 Nov 2016, at 08:12, Jerry Lundström <je...@dns-oarc.net> wrote: > > Hi Sara, > > On 10/31/16 18:22, Sara Dickinson wrote: >> https://github.com/dns-stats/draft-dns-capture-format >> <https://github.com/dns-stats/draft-dns-capture-format>
Hi Jerry, Thanks for the comments and the detailed review. > > An overall question, did you consider a CBOR extension tag (which does > not require a RFC)? Good question - not really at this stage but it something that could be considered (particularly if this draft moves towards adoption). My understanding of tags is that they are a useful convenience for labelling data items but not a necessity. > > The "file type id" content is not specified but in the CDDL it says > "DNS-STAT", if any should it not be "C-DNS” ? Yes, good spot :-) Agreed it should be C-DNS if anything. > > "format version" exists but there is no indication which format this is. Implicitly version 0, but will make this explicit in the next version. > > Description of "Block statistics" is missing. Yup - will also add in next version. Here is a quick summary total-packets - Total packets received in the stream total-pairs - Total number of matched DNS Q/R pairs written to the C-DNS file unmatched_queries - Unmatched DNS queries written to the C-DNS file unmatched_responses - Unmatched DNS queries written to the C-DNS file malformed-packets - Malformed DNS packets non-dns-packets - Non-DNS packets in the packet stream out-of-order-packets - Number of packets delivered out of order from the capture library missing-pairs - Number or matched DNS Q/R pairs collected, but not written to C-DNS file missing-packets - Number or received packets in the stream not written as PCAP missing-non-dns - Number or malformed/non-DNS packets in the stream not written as PCAP out-of-order-packets - this is a count of the number of times that a packet is received from the capture library where the timestamp on the packet is less than the timestamp on the previously received packet. There is a world of intrigue here when you go digging into the details of how/why this can happen…. The last 3 are somewhat application specific (all are optional). They are so that a collecting application can signal issues with overload where it was not able to output all the packets received in the the stream during the collection window for some reason. Such a collecting application could, for example, write out the malformed/non-DNS packets in PCAP format for later processing in parallel to writing the C-DNS data. > > "Timestamp" in "Block preamble map" is limited to microseconds, maybe > add that each element within the array after the first is a /million to > also allow nano/pico? That seems reasonable, if it can be done in a flexible way where the additional resolution is only written when needed (i.e when not 0) so as to not increase file size unnecessarily. > > Same goes for "time-useconds" and "delay-useconds", maybe allow them to > have a mixed type to either specify microseconds or a "Timestamp" offset > (as array with [seconds,micro,pico...]). > > About malformed and other data in the stream, would it not be possible > to add optional "unrecognized-data" byte string to the appropriate > objects and let the implementation decide? This could also include padding. We do want to come up with some mechanism to represent the malformed DNS packets where possible. That is one option to look at. Sara.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
