On Wed, Jul 5, 2017 at 8:05 AM, Jim Hague <j...@sinodun.com> wrote:
> Timestamps, on the other hand, I always regarded as a basic data type,
> so naturally a structure. Plus, of course, there's one per
> query/response item, so in a block the size savings are in the 10-15k
> bytes region, which is rather more significant.
>
In that case, I'm even more convinced that all of them (block preamble
"earliest-time", Q/R data item "time" and "delay", malformed packet item
"time") should have the same structure—either variable-precision arrays or
{"seconds", "useconds", "pseconds"} maps.
> * In section 7.18, "and an unsigned key" appears to be meaningless and
> > should probably be removed.
>
> In most places where we are discussing a map, we've specified the type
> of the map key in the text, though I notice we're not 100% consistent
> with that.
>
All the keys in those maps (and in every map, as far as I can tell) are
strings, for which "unsigned" is a meaningless concept.
> Example use
> > cases:
> [...]
> > * Extend the block preamble (section 7.7) to override file preamble
> > fields like "host-id" and "server-addresses", enabling fleet-wide file
> > merges.
>
> I don't quite follow why you'd need to put this informational-only stuff
> into the block preamble rather than the file preamble/configuration. Can
> you expand on that a bit?
>
Some of our processing can benefit from merging telemetry (e.g., all hosts
at a site), which would produce files containing blocks that don't share
values for fields currently in the file preamble. In fact, we might even
decide to treat "block" as the only relevant unit, using block preamble
extension fields for *everything* in the standard file preamble except
version information.
> *Opt-in Lossyness*
> This raises a question about a tension between the background of C-DNS
> to date and the slightly different angle you are coming from. We've been
> very much focused on using C-DNS to record traffic in a form where the
> packets can be recreated in wire format (i.e. as PCAP). The optional
> data items mean that data may be missing from those packets, but the
> core query and response will still be present.
>
Agreed. But it's _so close_ that I felt these suggestions were worth
raising—not to water down the primary use case, but to cover a few more
with some tradeoffs.
moves the recording to a point where reconstructing wire format means
> that the application doing the reconstruction has to not just omit
> information not present in C-DNS, but must start generating values to
> fill in for the missing items. This feels a bit like a step that needs
> discussion; we need to think over the design from your point of view.
> Possibly those fields should be optional, but with recommendations for
> how to populate them when/if generating PCAP.
>
That sounds great.
We'll be doing a 10 minute slot on C-DNS in Prague, and would welcome
> discussion there.
I don't expect to be there personally, but we'll have a well-informed
representative.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
