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

[Adam Roach <[e-mail]>]

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 <[e-mail] 
>> <mailto:[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/ 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.
>
>