On Thu, Nov 29, 2018 at 03:43:20PM +0000, Sara Dickinson wrote:
>
> > 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?
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.
>
>
>
>
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
