On Sep 21, 2016, at 3:15 PM, George Michaelson <g...@algebras.org> wrote: > I really like this document. I particularly like that it explicitly > addresses how the JSON format it uses can represent *malformed* DNS > state, as seen on the wire. This is very important, because some > canonicalize-and-map-the-DNS efforts I've seen have focussed on > well-formed packets, and this one stands out as saying "no, we have to > be able to represent incorrect state, because that exists on the wire, > and we need to show it sometimes" > > It has multiple encoding possibilities for the DNS RR. I'm a little > confused what difference it makes, that you'd want 'all the things' > here. If the argument is 'long crypto hashes are better done as > base64' then why do we have the hex at all?
Hex is easier to type for short blobs. > Is that to preserve > bit-field legibility for instance? Or, to encode unintelligible > off-the-wire sequences which present as a valid RR but you can't > decompose into their constituents? Maybe its just a little guidance > when you saw the hex being used? rather than B64. Really, it's just there because some people prefer one way over the other for some fields. > Do you need to be explicit that transform through this JSON would > permit re-emission of the wire content onto a network, and have the > packets function? Is that even a goal? Not a goal. (Particularly for badly-formed DNS responses :-) ) > The streaming reference sort-of > made me think this might be a goal, but it wasn't explicit to me in a > cursory reading. > > I think this is a good document. I think its close to baked for me. Thanks! And thanks to the many folks who have suggested (and will hopefully continue to suggest) changes. It's way better than the -00. --Paul Hoffman _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
