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

Benjamin Kaduk <kaduk@mit.edu> Fri, 30 November 2018 05:07 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0E49126CB6; Thu, 29 Nov 2018 21:07:20 -0800 (PST)
X-Quarantine-ID: <Ci5AylUW8WJ4>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci5AylUW8WJ4; Thu, 29 Nov 2018 21:07:19 -0800 (PST)
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu [18.9.25.13]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABF33126C7E; Thu, 29 Nov 2018 21:07:18 -0800 (PST)
X-AuditID: 1209190d-299ff70000001b05-c9-5c00c5859702
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-2.mit.edu (Symantec Messaging Gateway) with SMTP id D0.70.06917.585C00C5; Fri, 30 Nov 2018 00:07:17 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id wAU57FWd027094; Fri, 30 Nov 2018 00:07:15 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAU579Il017037 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 30 Nov 2018 00:07:13 -0500
Date: Thu, 29 Nov 2018 23:07:09 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Sara Dickinson <sara@sinodun.com>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>, dnsop-chairs <dnsop-chairs@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dnsop-dns-capture-format@ietf.org
Message-ID: <20181130050709.GA56551@kduck.kaduk.org>
References: <123F5FE4-47E3-4DBE-A3D4-D54BB027169C@sinodun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <123F5FE4-47E3-4DBE-A3D4-D54BB027169C@sinodun.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJKsWRmVeSWpSXmKPExsUixCmqrdt6lCHGYHGngsWb7ZNYLO6+ucxi seTBDmaLGX8mMlu0/frFbDGtbTOzA5vHzll32T2WLPnJ5HGv5zJjAHMUl01Kak5mWWqRvl0C V8aXY3fYCuZZV/xr7mJvYGzQ7WLk4JAQMJG4Otm7i5GLQ0hgDZPE5v0PWCCcjYwSL47sYYZw 7jJJ9E/aywzSwSKgKvFtkX0XIycHm4CKREP3ZWYQWwQofGLRfVaQemaBvYwST873MYEkhAVK JVa0X2EE6eUF2vasJQjEFBKwk2ieVwNSwSsgKHFy5hMWEJtZQF3iz7xLYJuYBaQllv/jgAjL SzRvnQ22iVPAXuL5yVvsILaogLLE3r5D7BMYBWchmTQLyaRZCJNmIZm0gJFlFaNsSm6Vbm5i Zk5xarJucXJiXl5qka6RXm5miV5qSukmRnAMSPLuYPx31+sQowAHoxIPr8Ov/9FCrIllxZW5 hxglOZiURHkXL2CIEeJLyk+pzEgszogvKs1JLT7EKMHBrCTCe64NKMebklhZlVqUD5OS5mBR Euf9LfI4WkggPbEkNTs1tSC1CCYrw8GhJME76whQo2BRanpqRVpmTglCmomDE2Q4D9DwWyA1 vMUFibnFmekQ+VOMilLivGUgCQGQREZpHlwvKEVJZO+vecUoDvSKMO8CkCoeYHqD634FNJgJ aHBMD9CTvMUliQgpqQbGe4fCzvKqqRon6m0q9pDKfGq+RkeHi611cb9D66nCN3EX26YwtT/s tNobbnt815NDH8N9Cj69tj0+96CZ0wtFhZXXu1Z457ms6XnlulDf6NOcLHYljoq+vXkZC5ov 69l1fGM78mLSmtWJP7nSzbpPX9Z9PPtu8orbjn93LP2zvT+8wSv1XOM/JZbijERDLeai4kQA wFiqfiwDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Uct_KRLygPqsIcVmrcoLSJcvUHE>
Subject: Re: [DNSOP] Benjamin Kaduk'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
Precedence: list
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: Fri, 30 Nov 2018 05:07:21 -0000

On Thu, Nov 29, 2018 at 03:43:20PM +0000, Sara Dickinson wrote:
> 
> > On 24 Nov 2018, at 03:58, Benjamin Kaduk <kaduk@mit.edu <mailto:kaduk@mit.edu>> wrote:
> > 
> > On Thu, Nov 22, 2018 at 12:01:00PM +0000, Sara Dickinson wrote:
> >>> 
> >>> Section 7.4.1.1.1
> >>> 
> >>> Am I parsing the "query-response-hints" text correctly to say that a bit is
> >>> set in the bitmap if the corresponding field is recorded (if present) by
> >>> the collecting implementation?  The causality of "if the field is omitted
> >>> the bit is unset" goes in a direction that is not what I expected.
> >>> (Similarly for the other fields in this table.)
> >> 
> >> ekr picked up on the same point - as responded to him:
> >> 
> >> "The issue is that if the bit is set the field might still be missing because although the configuration was set to collect it the data wasn’t available to the encoder from some other reason. However when the bit is not set it means that the data will definitely not be present because the collector is configured not to collect it. 
> >> 
> >> We do discuss this problem in section 6.2.1 - perhaps a reference in the table back to that discussion is what is needed?”
> >> 
> >> Looking again I think a slight update to the text in 6.2.1 might help too:
> >> 
> >> OLD:
> >> “The Storage Parameters therefore also contains a Storage Hints item
> >>  which specifies which items the encoder of the file omits from the
> >>  stored data."
> >> 
> >> NEW: “The Storage Parameters therefore also contains a Storage Hints item
> >>  which specifies which items the encoder of the file omits from the
> >>  stored data and will therefore never be present. (This approach is taken 
> >> because a flag that indicated which items were included for collection would 
> >> not guarantee that the item was present, only that it might be.) "
> > 
> > This text helps, but I think it is not quite what I was going after -- that
> > is, when I think of a "hint" that feels like something active and that
> > would be indicated by setting a bit to one.  In this design, the hints
> > about what are *omitted* are the bits that are *zero*, which is
> > counter-intuitive, at least to me.  So maybe we could say (in 7.4.1.1.1, in
> > addition to your suggested change in 6.2.1):
> > 
> > Hints indicating which "QueryResponse" fields are candidates for capture or
> > omitted, see section 7.6.  If a bit is unset, that field is omitted from
> > the capture.
> 
> Ah, ok I see the confusion now and yes - this text improves the draft - thank you!
> 
> > 
> >> 
> >>> 
> >>> Section 7.4.2
> >>> 
> >>> Do we need a reference for "promiscuous mode”?
> >> 
> >> Promiscuous mode is discussed on the main PCAP manpage…. Hopefully a way
> >> will be found to address the question of a suitable reference format for
> >> PCAP material.
> >> 
> >>> 
> >>> Just to check: in "server-addresses", I just infer the IP version from the
> >>> length of the byte string?
> >> 
> >> As mentioned in the DISCUSS response, we probably need to make the transport flags mandatory.
> >> 
> >>> 
> >>> Do we need to say more about where the vlan-ids identifiers are taken from?
> >> 
> >> Suggest: 
> >> 
> >> OLD: “ | vlan-ids         | O | A | Array of identifiers (of type unsigned |
> >>  |                  |   |   | integer) of VLANs selected for         |
> >>  |                  |   |   | collection. “
> >> 
> >> NEW: “ | vlan-ids         | O | A | User specified array of identifiers (of type unsigned |
> >>  |                  |   |   | integer) of VLANs  [IEEE 802.1Q] selected for         |
> >>  |                  |   |   | collection.  "
> > 
> > It seems likely to me that we want to say that the actual VLAN ID values
> > are only unique within an administrative domain.
> 
> OK - yes, makes sense.
> 
> > 
> >>> 
> >>> Is the "generator-id" string intended to only be human readable?  Only
> >>> within a specific (administrative) context?
> >> 
> >> The generator ID is intended only to identify the collecting
> >> application. Specifying that it is human-readable (if present) seems a
> >> good idea. Would this be sufficient?
> >> 
> >> OLD: "String identifying the collection method.”
> >> NEW: “User specified human-readable string identifying the collection method."
> > 
> > Does "user-specified" mean that only the user is responsible for reading it
> > later (or would we want it to make sense even when the data is conveyed to
> > some other party)?
> 
> Yes - that’s correct. Maybe 'implementation specific' is better?

I think that's more explicit about what scope we should expect.
(But of course this is all in the non-blocking comment section, so your
judgment takes precedence over mine.)

> > If so, this would be enough for to address my comment, but then Ben's
> > comment about internationalization concerns would come into play.
> 
> Sorry - I missed that comment - could you clarify? I’m not sure how I see this is any different to any other (unicode) text string used in CBOR?

It's my turn to apologize; I am probably thinking of a different document.
I'll try to double-check, but it should be safe to assume there's not an
issue here.

> > 
> >>> 
> >>> Section 7.5.1
> >>> 
> >>> Does "earliest-time" include leap seconds?
> >> 
> >> Thanks for noticing this…after digging into it…
> >> 
> >> The description specifies the number of seconds to be the
> >> number of seconds since the POSIX epoch ("time_t"). POSIX requires that
> >> leap seconds be omitted from reported time, and all days are defined as
> >> having 86,400 seconds. This means that a POSIX timestamp can be
> >> ambiguous and refer to either of the last 2 seconds of a day containing
> >> a leap second (who knew time could stand still in POSIX world - aargh?!) 
> >> 
> >> However, libpcap (for example) can only provide POSIX timestamps for 
> >> packets as far as we can see… 
> >> 
> >> Do you think we should just document this as a limitation or do you have 
> >> another option in mind?
> > 
> > To be honest, I was only expecting "number of seconds since the POSIX epoch
> > ("time_t", excluding leap seconds)" or "number of seconds since the POSIX
> > epoch ("time_t", including leap seconds)".  My concern is just that we
> > state how to interpret the number in this field; choosing whichever case
> > the common API provides is fine, and we don't need to document it as a
> > limitation at all.  If someone needs to convert between TAI and UTC, we
> > give them enough information so that they can do it, but otherwise it's not
> > our problem.
> 
> We are happy with just adding the ‘excluding leap seconds’ qualifier here if that work for you :-)

That works great for me :)

Many thanks for these updates,

Benjamin

> <snip>
> 
> > 
> >>> 
> >>> Section 7.7
> >>> 
> >>> How is the value of the "ae-code" determined?
> >> 
> >> "ae-code" is intended to hold the ICMP or ICMPv6 code. We suggest making
> >> this clearer:
> >> 
> >> OLD: "A code relating to the event."
> >> NEW: "A code relating to the event. For ICMP or ICMPv6 events, this
> >> should be the ICMP [RFC792] or ICMPv6 [ RFC4443] code."
> > 
> > I think we need to say that the contents are undefined (or only locally
> > defined) in other cases.  But this new text is a big step forward, thanks!
> 
> Right, I see the point now. We’ll add that. 
> 
> Thanks and regards
> 
> Sara. 
> 
> 
> 
>