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

From: Adam Roach <[email-masked]>
Date: Tue, 20 Nov 2018 18:09:04 -0800

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.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 21 Nov 2018 02:42:39 +0000

> "...is an IETF specification..." (See BCP 9)

The CBOR WG is actively working on moving CBOR to Internet Standard, so "nowhere near" feels overstated. If you are trying to get the wording in this draft correct by BCP 9, the correction should be to "... is a Proposed Standard...".

--Paul Hoffman (who still finds it weird to be the co-author of CBOR)

---

From: Adam Roach <[email-masked]>
Date: Tue, 20 Nov 2018 21:13:40 -0600

On 11/20/18 8:42 PM, Paul Hoffman wrote:
> The CBOR WG is actively working on moving CBOR to Internet Standard, so "nowhere near" feels overstated.

This is, of course, somewhat subjective and not really worth arguing 
over, but I think it's defensible when talking about a document that 
isn't even an RFC yet.

> If you are trying to get the wording in this draft correct by BCP 9, the correction should be to "... is a Proposed Standard...".

That won't age well.

/a

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 21 Nov 2018 16:58:13 +0000

> On 21 Nov 2018, at 02:09, Adam Roach <[email-masked]> wrote:
> 

Hi Adam. 

Many thanks for the review.

Please see our reply to Benjamin.

These all appear to be in the CDDL definition. We'll fix the formatting there.

> (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.

Agreed, thanks for the wording.

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

Perhaps a better clarification is to say:

OLD: "DNS style name compression is used..."

NEW: "[RFC1035] name compression is used..."

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".

>>  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?

>> 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

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.

---

From: Adam Roach <[email-masked]>
Date: Wed, 21 Nov 2018 12:17:30 -0600

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 <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>> 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
> from example.com <http://example.com> and bar.com <http://bar.com> to 
> foo.example and bar.example.
>
> Best regards
>
> Sara.
>
>