Return-Path: 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 F0ACD130E0C; Thu, 29 Nov 2018 07:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.3 X-Spam-Level: X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=sinodun.com 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 xfWPuHo4n-rL; Thu, 29 Nov 2018 07:43:26 -0800 (PST) Received: from haggis.mythic-beasts.com (haggis.mythic-beasts.com [IPv6:2a00:1098:0:86:1000:0:2:1]) (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 1346612E036; Thu, 29 Nov 2018 07:43:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sinodun.com ; s=haggis-2018; h=To:Date:Subject:From; bh=H6cQR15OJop8eZVlPekzsTUn8vcjAqxXjDQjSfctyRY=; b=u/47QUhERk1aRG5wMt9lEe6IFO NntGZapPNB5liSrn6B5Ri3XXVqLb33fOg84UKYXbxkiusI9RszgxUK/da36gptyQmxY17AGgwKzD/ NxiGFUo8wOFgvcIwqppu9HPlWAwKwb4VVmjAl49CyrvC1TiSUsGc4otk/o+kFI652aHf9FNeV1E49 sIzI6IgNCh4GaoTxMr7dexl6TlyjebCGPVLbPcLrE0P/Lo6FZ/xMGZkImqg5zv2d4/yGnoCeWcIW2 qky4MgyS5Djueq3cyK/Yvc01/luCqh2p0+yj0AgfVG+m4u9PzhzTmGql9gNe6hpjp5Qx/jnDCGU4I ZALZndDQ==; Received: from [2001:b98:204:102:fffa::409] (port=52363) by haggis.mythic-beasts.com with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1gSOTK-0003M4-SR; Thu, 29 Nov 2018 15:43:23 +0000 From: Sara Dickinson Content-Type: multipart/alternative; boundary="Apple-Mail=_B2EF9648-4C43-42D1-900A-C0EFE14900ED" Mime-Version: 1.0 (Mac OS X Mail 12.0 \(3445.100.39\)) Message-Id: <123F5FE4-47E3-4DBE-A3D4-D54BB027169C@sinodun.com> Date: Thu, 29 Nov 2018 15:43:20 +0000 Cc: Tim Wicinski , dnsop , dnsop-chairs , The IESG , draft-ietf-dnsop-dns-capture-format@ietf.org To: Benjamin Kaduk X-Mailer: Apple Mail (2.3445.100.39) X-BlackCat-Spam-Score: 14 Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2018 15:43:29 -0000 --Apple-Mail=_B2EF9648-4C43-42D1-900A-C0EFE14900ED Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 24 Nov 2018, at 03:58, Benjamin Kaduk > wrote: >=20 > On Thu, Nov 22, 2018 at 12:01:00PM +0000, Sara Dickinson wrote: >>>=20 >>> Section 7.4.1.1.1 >>>=20 >>> 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.) >>=20 >> ekr picked up on the same point - as responded to him: >>=20 >> "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=E2=80=99t 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.=20 >>=20 >> We do discuss this problem in section 6.2.1 - perhaps a reference in = the table back to that discussion is what is needed?=E2=80=9D >>=20 >> Looking again I think a slight update to the text in 6.2.1 might help = too: >>=20 >> OLD: >> =E2=80=9CThe Storage Parameters therefore also contains a Storage = Hints item >> which specifies which items the encoder of the file omits from the >> stored data." >>=20 >> NEW: =E2=80=9CThe 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=20 >> because a flag that indicated which items were included for = collection would=20 >> not guarantee that the item was present, only that it might be.) " >=20 > 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): >=20 > 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! >=20 >>=20 >>>=20 >>> Section 7.4.2 >>>=20 >>> Do we need a reference for "promiscuous mode=E2=80=9D? >>=20 >> Promiscuous mode is discussed on the main PCAP manpage=E2=80=A6. = Hopefully a way >> will be found to address the question of a suitable reference format = for >> PCAP material. >>=20 >>>=20 >>> Just to check: in "server-addresses", I just infer the IP version = from the >>> length of the byte string? >>=20 >> As mentioned in the DISCUSS response, we probably need to make the = transport flags mandatory. >>=20 >>>=20 >>> Do we need to say more about where the vlan-ids identifiers are = taken from? >>=20 >> Suggest:=20 >>=20 >> OLD: =E2=80=9C | vlan-ids | O | A | Array of identifiers (of = type unsigned | >> | | | | integer) of VLANs selected for = | >> | | | | collection. =E2=80=9C >>=20 >> NEW: =E2=80=9C | vlan-ids | O | A | User specified array of = identifiers (of type unsigned | >> | | | | integer) of VLANs [IEEE 802.1Q] = selected for | >> | | | | collection. " >=20 > 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. >=20 >>>=20 >>> Is the "generator-id" string intended to only be human readable? = Only >>> within a specific (administrative) context? >>=20 >> 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? >>=20 >> OLD: "String identifying the collection method.=E2=80=9D >> NEW: =E2=80=9CUser specified human-readable string identifying the = collection method." >=20 > 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=E2=80=99s correct. Maybe 'implementation specific' is better? > 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=E2=80=99m not sure = how I see this is any different to any other (unicode) text string used = in CBOR? >=20 >>>=20 >>> Section 7.5.1 >>>=20 >>> Does "earliest-time" include leap seconds? >>=20 >> Thanks for noticing this=E2=80=A6after digging into it=E2=80=A6 >>=20 >> 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?!)=20 >>=20 >> However, libpcap (for example) can only provide POSIX timestamps for=20= >> packets as far as we can see=E2=80=A6=20 >>=20 >> Do you think we should just document this as a limitation or do you = have=20 >> another option in mind? >=20 > 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 =E2=80=98excluding leap seconds=E2=80=99= qualifier here if that work for you :-) >=20 >>>=20 >>> Section 7.7 >>>=20 >>> How is the value of the "ae-code" determined? >>=20 >> "ae-code" is intended to hold the ICMP or ICMPv6 code. We suggest = making >> this clearer: >>=20 >> 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." >=20 > 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=E2=80=99ll add that.=20 Thanks and regards Sara.=20 --Apple-Mail=_B2EF9648-4C43-42D1-900A-C0EFE14900ED Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On 24 Nov 2018, at 03:58, Benjamin Kaduk <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=E2=80=99t 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?=E2=80=9D

Looking again I think a slight update to the text in 6.2.1 = might help too:

OLD:
=E2=80=9CT= he Storage Parameters therefore also contains a Storage Hints item
 which specifies which items the encoder of the file = omits from the
 stored data."

NEW: =E2=80=9CThe 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=E2=80=9D?

Promiscuous mode is discussed on the main PCAP manpage=E2=80=A6= . 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: =E2=80=9C | = vlan-ids         | O | A | Array = of identifiers (of type unsigned |
 | =             &n= bsp;    |   |   | integer) of = VLANs selected for         |
 | =             &n= bsp;    |   |   | collection. = =E2=80=9C

NEW: =E2=80=9C | vlan-ids =         | O | A | User specified = array of identifiers (of type unsigned |
 | =             &n= bsp;    |   |   | integer) of = VLANs  [IEEE 802.1Q] selected for =         |
 | =             &n= bsp;    |   |   | 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.=E2=80=9D
NEW: =E2=80=9CUser 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=E2=80=99s correct. Maybe 'implementation specific' = is better?

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=E2=80=99m not sure how I = see this is any different to any other (unicode) text string used in = CBOR?



Section 7.5.1

Does "earliest-time" include leap seconds?

Thanks for noticing this=E2=80=A6af= ter digging into it=E2=80=A6

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=E2=80=A6 

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 =E2=80=98excluding leap seconds=E2=80=99 = qualifier here if that work for you :-)

<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=E2=80=99ll add = that. 

Thanks and regards

Sara. 




= --Apple-Mail=_B2EF9648-4C43-42D1-900A-C0EFE14900ED--