[DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)

Alexey Melnikov <aamelnikov@fastmail.fm> Mon, 19 November 2018 20:37 UTC

Return-Path: <aamelnikov@fastmail.fm>
X-Original-To: dnsop@ietf.org
Delivered-To: dnsop@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E65128D0C; Mon, 19 Nov 2018 12:37:30 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Alexey Melnikov <aamelnikov@fastmail.fm>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-dnsop-dns-capture-format@ietf.org, Tim Wicinski <tjw.ietf@gmail.com>, dnsop-chairs@ietf.org, tjw.ietf@gmail.com, dnsop@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.88.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <154265985064.16386.5550594646862412061.idtracker@ietfa.amsl.com>
Date: Mon, 19 Nov 2018 12:37:30 -0800
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/RjXYa29zyrpJau7pfeI8-M-6-zU>
Subject: [DNSOP] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 19 Nov 2018 20:37:31 -0000

Alexey Melnikov has entered the following ballot position for
draft-ietf-dnsop-dns-capture-format-08: Discuss

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/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document, it is a useful contribution to RFC series. I
enjoyed reading it.

I have a small list of issues that is hopefully easy to fix:

1)

In 7.4.2:

   | filter           | O | T | "tcpdump" [pcap] style filter for      |
   |                  |   |   | input.                                 |

This makes the [pcap] reference Normative. If you don't want to do that, please
fully specify syntax in this document.

2) I believe [I-D.ietf-cbor-cddl] reference needs to be Normative due to use of
CDDL in Appendix A. If you don't think CDDL is normative, you need to state
that in Appendix A.


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Was CDDL in Appendix A validated with a tool? This information is missing from
the shepherding write-up.

6.2.3.  Storage flags

   The Storage Parameters also contains optional fields holding details
   of the sampling method used and the anonymisation method used.  It is
   RECOMMENDED these fields contain URIs pointing to resources
   describing the methods used.

Please add a Normative Reference for URI spec here (RFC 3986).

7.5.3.2.  "QueryResponseSignature"

   | qr-transport-flags | O | U | Bit flags describing the transport   |
   |                    |   |   | used to service the query.           |
   |                    |   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
   |                    |   |   | IPv6                                 |
   |                    |   |   | Bit 1-4. Transport. 4 bit unsigned   |
   |                    |   |   | value where 0 = UDP, 1 = TCP, 2 =    |
   |                    |   |   | TLS, 3 = DTLS. Values 4-15 are       |
   |                    |   |   | reserved for future use.             |
   |                    |   |   | Bit 5. 1 if trailing bytes in query  |
   |                    |   |   | packet. See Section 11.2.            |

Would something like DoH appear as a separate transport choice?

How can new values be added to the list if there are no IANA Considerations?

7.5.3.5.  "MalformedMessageData"

   |                    |   |   |                                      |
   | mm-transport-flags | O | U | Bit flags describing the transport   |
   |                    |   |   | used to service the query. Bit 0 is  |
   |                    |   |   | the least significant bit.           |
   |                    |   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
   |                    |   |   | IPv6                                 |
   |                    |   |   | Bit 1-4. Transport. 4 bit unsigned   |
   |                    |   |   | value where 0 = UDP, 1 = TCP, 2 =    |
   |                    |   |   | TLS, 3 = DTLS. Values 4-15 are       |
   |                    |   |   | reserved for future use.             |

If the above bits supposed to be the same as for qr-transport-flags,
maybe it is worth defining them once and referencing in all relevant places?

7.6.  "QueryResponse"
   | query-size           | O | U | DNS query message size (see        |
   |                      |   |   | below).                            |
   |                      |   |   |                                    |
   | response-size        | O | U | DNS query message size (see        |
   |                      |   |   | below).                            |

I think "DNS response message size" for response-size.

It is odd to have RFC 2119 language in B.2, which is itself informative.