Re: [DNSOP] Adam Roach's No Objection on draft-ietf-dnsop-dns-capture-format-08: (with COMMENT)
Sara Dickinson <sara@sinodun.com> Wed, 21 November 2018 16:58 UTC
Return-Path: <sara@sinodun.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A58C812D4F2; Wed, 21 Nov 2018 08:58:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.4
X-Spam-Level:
X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N-CFZ6UEncoT; Wed, 21 Nov 2018 08:58:27 -0800 (PST)
Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A8869123FFD; Wed, 21 Nov 2018 08:58:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=haggis-2018; h=To:Date:Subject:From; bh=4EAPswP9bY9Jo+lzbs4+sMEiJxJkJZlnBJ3yYXOZe8E=; b=Uzry104CAwnwo9f/KtodnVj06U uT6S4B39/3zMtOh5pwkixvcJSTzJI6sZTg8rmXMuaen7jHoJe+AhXHIUP2ncINDQm5F4IWSgdrJMM h7gvV65HlTXvNs93dFu3j8rKAjY/DrzngJdG0W9Zh/+h2Id3/Wd/CtFGl6D3g/3DxR3dS8L6XQRhL 8ne2oc+FyKdmMhbTUCxb5eoJjlLL7bp7WDzQnvJJtaz+x/zKKbGiyO94ZaPm5gBJRLrkO9fgZ80K3 Ocr/nsXdMHB0y5X0C+q1eBztNXry8UPco3RXXDhGEnZzHCvwQlsUMYp9h0Fu4IFB879+h/RWGIfGu cE8H4+Qw==;
Received: from [2001:b98:204:102:fffa::409] (port=55398) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <sara@sinodun.com>) id 1gPVpZ-0002T3-Cg; Wed, 21 Nov 2018 16:58:25 +0000
From: Sara Dickinson <sara@sinodun.com>
Message-Id: <2E5347FB-9A97-4701-A85A-5A615AE96564@sinodun.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_477D1192-F0A6-4A81-B9CD-B4823384785C"
Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\))
Date: Wed, 21 Nov 2018 16:58:13 +0000
In-Reply-To: <154276614451.29753.3535998981795767703.idtracker@ietfa.amsl.com>
Cc: The IESG <iesg@ietf.org>, draft-ietf-dnsop-dns-capture-format@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs <dnsop-chairs@ietf.org>, dnsop@ietf.org
To: Adam Roach <adam@nostrum.com>
References: <154276614451.29753.3535998981795767703.idtracker@ietfa.amsl.com>
X-Mailer: Apple Mail (2.3445.100.39)
X-BlackCat-Spam-Score: 14
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/nNx0FVGvOu4IUcQN9OrWKvaA5Sk>
Subject: Re: [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
Precedence: list
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 16:58:31 -0000
> On 21 Nov 2018, at 02:09, Adam Roach <adam@nostrum.com> wrote: > > Adam Roach has entered the following ballot position for > draft-ietf-dnsop-dns-capture-format-08: No Objection Hi Adam. Many thanks for the review. > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > > I support Benjamin's DISCUSS regarding a treatment of the privacy issues related > to this capture format. Please see our reply to Benjamin. > --------------------------------------------------------------------------- > > id-nits reports: > > ** There are 11 instances of too long lines in the document, the longest > one being 9 characters in excess of 72. These all appear to be in the CDDL definition. We'll fix the formatting there. > -- 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/ <https://www.iab.org/2016/11/07/iab-statement-on-ipv6/> for more information > about the second issue) Agreed. We'll add an IPv6 example, and position it before the IPv4 example. > --------------------------------------------------------------------------- > > §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) > > --------------------------------------------------------------------------- Agreed, thanks for the wording. > §9.1: > >> DNS style name compression is used on the individual names within the > > Nit: "DNS-style" Perhaps a better clarification is to say: OLD: "DNS style name compression is used..." NEW: "[RFC1035] name compression is used..." > --------------------------------------------------------------------------- > > 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", Version 0.8.5 and previous of the 'cddl' generation/validation tool outputs the above as a numeric quantity, h'432D444E53'. The latest version 0.8.6 seems to get this right and outputs "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, 'cddl' does seem to output the correct values here. We've erred on the side of a more explicit definition in the hope that this is clearer for implementers. But perhaps this is a good question for the CBOR WG as to what is the preferred style - we can ask? > --------------------------------------------------------------------------- > > Appendix B: > >> The next name added is bar.com <http://bar.com/>. This is matched against example.com <http://example.com/>. > > bar.com <http://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/ <https://www.bar.com/> for details). We should > consider not making things worse for them. Please use an RFC 2606 address > instead. Good point. We will change the names in the next version of the draft from example.com and bar.com to foo.example and bar.example. Best regards Sara.
- [DNSOP] Adam Roach's No Objection on draft-ietf-d… Adam Roach
- Re: [DNSOP] [Ext] Adam Roach's No Objection on dr… Paul Hoffman
- Re: [DNSOP] [Ext] Adam Roach's No Objection on dr… Adam Roach
- Re: [DNSOP] Adam Roach's No Objection on draft-ie… Sara Dickinson
- Re: [DNSOP] Adam Roach's No Objection on draft-ie… Adam Roach