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

[Sara Dickinson <[e-mail]>]

> On 21 Nov 2018, at 02:09, Adam Roach <[e-mail]> 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.