Thanks! Your proposed resolutions look good to me.
/a
On 11/21/18 10:58 AM, Sara Dickinson wrote:
On 21 Nov 2018, at 02:09, Adam Roach <a...@nostrum.com
<mailto:a...@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/ 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/ 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 <http://example.com> and bar.com <http://bar.com> to
foo.example and bar.example.
Best regards
Sara.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
