> On 24 Nov 2018, at 03:58, Benjamin Kaduk <ka...@mit.edu
> <mailto:ka...@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?
> 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?
>
>>>
>>> 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 :-)
<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.
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
