> On 21 Nov 2018, at 02:09, Adam Roach <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/ > <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 mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
