[DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)

Adam Roach <adam@nostrum.com> Wed, 21 November 2018 02:09 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7EBAF124C04; Tue, 20 Nov 2018 18:09:04 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Adam Roach <adam@nostrum.com>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-dns-capture-format@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs@ietf.org, tjw.ietf@gmail.com, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.89.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154276614451.29753.3535998981795767703.idtracker@ietfa.amsl.com>
Date: Tue, 20 Nov 2018 18:09:04 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pZ_4c1XqSkWlhUYt2OOdyObALbQ>
Subject: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 21 Nov 2018 02:09:04 -0000

Adam Roach has entered the following ballot position for
draft-ietf-dnsop-dns-capture-format-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------



I support Benjamin's DISCUSS regarding a treatment of the privacy issues related
to this capture format.

---------------------------------------------------------------------------

id-nits reports:

  ** There are 11 instances of too long lines in the document, the longest
     one being 9 characters in excess of 72.

  -- The document has examples using IPv4 documentation addresses according
     to RFC6890, but does not use any IPv6 documentation addresses.  Maybe
     there should be IPv6 examples, too?

(See https://www.iab.org/2016/11/07/iab-statement-on-ipv6/ for more information
about the second issue)

---------------------------------------------------------------------------

§5:

>  o  CBOR is an IETF standard and familiar to IETF participants.  It is

While CBOR is standards-track, it's nowhere near standard yet. Suggest:
"...is an IETF specification..." (See BCP 9)

---------------------------------------------------------------------------

§9.1:

>  DNS style name compression is used on the individual names within the

Nit: "DNS-style"

---------------------------------------------------------------------------

Appendix A:

>   file-type-id  : tstr .regexp "C-DNS",

I'm far from a CDDL expert, but I just read through that specification, and it
seems to me that this is a bit overwrought. I think you can accomplish the same
with the much simpler production:

    file-type-id  : "C-DNS",

Similarly:

>   major-format-version => uint .eq 1,
>   minor-format-version => uint .eq 0,

would seem to mean the same as the simpler:

>   major-format-version => 1,
>   minor-format-version => 0,

---------------------------------------------------------------------------

Appendix B:

>  The next name added is bar.com.  This is matched against example.com.

bar.com is allocated to a private individual who has already had to contend with
a lot of unwanted traffic (see https://www.bar.com/ for details). We should
consider not making things worse for them. Please use an RFC 2606 address
instead.