Subject: [DNSOP] I-D Action: draft-ietf-dnsop-dns-capture-format-07.txt

From: [email-masked]
Date: Tue, 08 May 2018 09:40:57 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Domain Name System Operations WG of the IETF.

        Title           : C-DNS: A DNS Packet Capture Format
        Authors         : John Dickinson
                          Jim Hague
                          Sara Dickinson
                          Terry Manderson
                          John Bond
	Filename        : draft-ietf-dnsop-dns-capture-format-07.txt
	Pages           : 64
	Date            : 2018-05-08

Abstract:
   This document describes a data representation for collections of DNS
   messages.  The format is designed for efficient storage and
   transmission of large packet captures of DNS traffic; it attempts to
   minimize the size of such packet capture files but retain the full
   DNS message contents along with the most useful transport metadata.
   It is intended to assist with the development of DNS traffic
   monitoring applications.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-dns-capture-format-07
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-dns-capture-format-07

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-dns-capture-format-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Sara Dickinson <[email-masked]>
Date: Tue, 8 May 2018 17:55:04 +0100

Hi All, 

This update addresses the following issues:

* Resolve outstanding questions and TODOs
* Make RR RDATA optional
* Update matching diagram and explain skew
* Add count of discarded messages to block statistics
* Editorial clarifications and improvements

Regards

Sara. 

> On 8 May 2018, at 17:40, [email-masked] wrote:
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Richard Gibson <[email-masked]>
Date: Tue, 8 May 2018 15:27:11 -0400

This update addresses all of my earlier comments with the exception of 
implementation-specific extension data using namespaced string keys (as 
opposed to negative-integer keys)—which I assume to be intentional 
because of the "String keys would significantly bloat the file size" 
text in Section 7.1—and the ability to support variable truncation of IP 
addresses—particularly for identifying the full addresses of responders 
while truncating the addresses of requestors, but also for retaining 
more requestor precision in some subnets than others.

This format in its present state /can/ work for my organization, but the 
second gap in particular means we'll be manually hacking around those 
deficiencies by e.g. representing 192.0.2.0/24 as 192.0.2.0/32 in order 
to fully specify 198.51.100.42/32.

On 05/08/2018 12:55 PM, Sara Dickinson wrote:
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo&s=-u1MK57BW5D8-4pRW93F3iGOeUleCbk_ZcBsHqaJ9t8&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat-2D07&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo&s=C3JyMunVCDkuQmIVefLLP1pxe8CEegg7nfoL1klK_To&e=
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_html_draft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat-2D07&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo&s=wyWytvxkoi319adauctYZq3PVsUMYE-kzBYRzKivPjU&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_rfcdiff-3Furl2-3Ddraft-2Dietf-2Ddnsop-2Ddns-2Dcapture-2Dformat-2D07&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo&s=JlUS92uQuF7x5Xjb75Uxjp6fMTaaoEAux_ZacxCvN_U&e=
>>
>>
>> https://urldefense.proofpoint.com/v2/url?u=ftp-3A__ftp.ietf.org_internet-2Ddrafts_&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo&s=L3Jo61TkqDrhjdg5YB-37i96KK9yh5WVilrcK6DUj9Y&e=
>>
>> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo&s=1OG0b26AkBwGSkwxhcNHmA2EPht8H6ZYV2sgkIfomRE&e=
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_dnsop&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=-o8MJF7i0TzXAJRB0ncfTVfWKSyTG7nl_iTLU_A2B7c&m=0BgV4idHXk65D0rJj2ono9LsU6Y9Xut-Y3K4CCQIGYo&s=1OG0b26AkBwGSkwxhcNHmA2EPht8H6ZYV2sgkIfomRE&e=

---

From: Jim Hague <[email-masked]>
Date: Thu, 10 May 2018 10:33:59 +0100

> more requestor precision in some subnets than others.

Apologies; we'd opened GitHub issues for both of these, intending to
keep you updated, and due to mis-communication between the authors
didn't report updates and feedback post-IETF 101. I have bought these
issues up to date with our current responses.

https://github.com/dns-stats/draft-dns-capture-format/issues/58
https://github.com/dns-stats/draft-dns-capture-format/issues/60

While there are other concerns listed in the above, we've not to date
had other support for namespace string keys or variable IP address
truncation on the list; we specifically raised the latter issue in our
presentation at IETF101, and had hallway feedback that the complexity
did not seem warranted for the limited use case.

We'd like to hear comments from others on these specific issues on the
list.
-- 
Jim Hague - [email-masked]          Never trust a computer you can't lift.