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

[Alexey Melnikov <[e-mail]>]

On Wed, Nov 28, 2018, at 1:38 PM, Sara Dickinson wrote:
> 
>> *From: *Paul Hoffman <[e-mail]>
>> *Subject: **Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-
>> 08: (with DISCUSS and COMMENT)*>> *Date: *27 November 2018 at 14:59:51 GMT
>> *To: *Alexey Melnikov <[e-mail]>
>> *Cc: *dnsop <[e-mail]>, The IESG <[e-mail]>
>> 
>> On Nov 27, 2018, at 3:05 AM, Alexey Melnikov
>> <[e-mail]> wrote:>>> 
>>> On Tue, Nov 27, 2018, at 2:10 AM, Paul Hoffman wrote:
>>>>  | filter           | O | T | "tcpdump" [pcap] style filter
>>>>  | for      |>>>>  |                  |   |   | input.
>>>>  |                  |   |   | |>>>> 
>>>> 
>>>> On Nov 26, 2018, at 6:05 PM, Warren Kumari <[e-mail]>
>>>> wrote:>>>>> ... that is where we started.
>>>>> The concern was what happens if there are new filters added, and
>>>>> implementations written don't know how to deal with them.>>>> 
>>>> New filters being added to tcpdump (or even removed) doesn't
>>>> affect a C->>>> DNS application from reading or writing that field. It's just
>>>> a text>>>> string. 
>>> 
>>> I think this depends on how the field is used.
>>> 
>>> If you want to write an application that validates or does something
>>> with this field, that wouldn't be true.>>> If you think that writing such an application is a dumb idea, then
>>> the draft should clearly state that.>> 
>> My interpretation of the spec has been all along that this field, as
>> well as the other fields in CollectionParameters, were informational
>> for whomever is looking at the particular capture. "Parameters
>> relating to how data in the file was collected" seemed sufficient for
>> that. If the authors added "These parameters are informational are
>> only informational and cannot necessarily be validated by looking in
>> the data captured", would that satisfy your concern?> 
> Paul is correct in that the _intention_ of including these fields is
> just to provide informational meta data about the capturing process. I
> would suggest we change the first sentence of the section to be:> 
> “Parameters providing information to how data in the file was
> collected (applicable for some, but not all collection environments).
> The values are informational only and serve as hints to downstream
> analysers as to the configuration of a collecting implementation. They
> can provide context when interpreting what data is present/absent from
> the capture but cannot necessarily be validated against the data
> captured.”I can live with that, but I would like you to in particular add a note
that pcap filter value should not be trusted, as it effectively can
contain arbitrary text string.
> Given that, I’m hoping the short reference is acceptable
> http://www.tcpdump.org/manpages/pcap-filter.7.html?Yes.