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

[Jim Hague]

On 28/11/2018 14:45, Alexey Melnikov wrote:
> On Wed, Nov 28, 2018, at 1:38 PM, Sara Dickinson wrote:

>> 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.

OK, thanks. We will do that.

>> Given that, I’m hoping the short reference is
>> acceptable http://www.tcpdump.org/manpages/pcap-filter.7.html? 
> Yes.

Thanks.
-- 
Jim Hague - j...@sinodun.com  Never trust a computer you can't lift.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Alexey Melnikov]

On Wed, Nov 28, 2018, at 1:38 PM, Sara Dickinson wrote:
> 
>> *From: *Paul Hoffman 
>> *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 
>> *Cc: *dnsop , The IESG 
>> 
>> On Nov 27, 2018, at 3:05 AM, Alexey Melnikov
>>  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 
 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.

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Sara Dickinson]

> From: Paul Hoffman 
> 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 
> Cc: dnsop , The IESG 
> 
> On Nov 27, 2018, at 3:05 AM, Alexey Melnikov  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  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.”

Given that, I’m hoping the short reference is acceptable 
http://www.tcpdump.org/manpages/pcap-filter.7.html? 
 

Regards

Sara.___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Eric Rescorla]

On Tue, Nov 27, 2018 at 7:00 AM Paul Hoffman  wrote:

> On Nov 27, 2018, at 3:05 AM, Alexey Melnikov 
> 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  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?
>

Hmm... I don't really think so. It seems to me that the semantics here are
"this is the filter string that was applied" and because that's effectively
a program, in order to interpret it you need to know what language it was
in.

-Ekr


> --Paul Hoffman
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On Nov 27, 2018, at 3:05 AM, Alexey Melnikov  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  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 Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Alexey Melnikov]

Hi Paul,

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  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.

Best Regards,
Alexey

___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

   | filter   | O | T | "tcpdump" [pcap] style filter for  |
   |  |   |   | input. |


On Nov 26, 2018, at 6:05 PM, Warren Kumari  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. 

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Warren Kumari]

On Mon, Nov 26, 2018 at 8:58 PM Paul Hoffman  wrote:

> On Nov 26, 2018, at 5:44 PM, Warren Kumari  wrote:
> > Actually, there is - the tcpdump man pages (and actually all of their
> documentation!) lives in github - the version that this document references
> is:
> >
> https://raw.githubusercontent.com/the-tcpdump-group/tcpdump-htdocs/7785b0d834e1f77a1d2ec56c96f51f4bf3bf3de2/manpages/pcap-filter.7.txt
>
> Note that this URL is basically useless in an RFC that uses the current
> format: it is 135 characters long. It's cute that it points to the correct
> man page, but really not useful as a reference in an RFC as they are
> currently constituted.
>
> Going back to Warren's original concern:
>
> > We discussed this on the telechat, and I took the action to try look
> into this.
> > One of the concerns with a normative reference to the webpage is what
> happens if it is updated to add a new primitive - is it allowed? If someone
> implements this on Thursday, can they still claim conformance if a new
> primitive is added on Friday?
>
> For the CollectionParameters map, a "filters" item lists the filters that
> are used for this capture file. It truly doesn't matter if the reference is
> updated later: the capture still has the same filter string.
>
> Thus, it is quite sufficient for this reference to be:
>http://www.tcpdump.org/manpages/pcap-filter.7.html
> That is a useful reference for an implementer, and it fits in an RFC.
>

 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.

W




>
> --Paul Hoffman



-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop

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

[Paul Hoffman]

On Nov 26, 2018, at 5:44 PM, Warren Kumari  wrote:
> Actually, there is - the tcpdump man pages (and actually all of their 
> documentation!) lives in github - the version that this document references 
> is:
> https://raw.githubusercontent.com/the-tcpdump-group/tcpdump-htdocs/7785b0d834e1f77a1d2ec56c96f51f4bf3bf3de2/manpages/pcap-filter.7.txt

Note that this URL is basically useless in an RFC that uses the current format: 
it is 135 characters long. It's cute that it points to the correct man page, 
but really not useful as a reference in an RFC as they are currently 
constituted.

Going back to Warren's original concern:

> We discussed this on the telechat, and I took the action to try look into 
> this.
> One of the concerns with a normative reference to the webpage is what happens 
> if it is updated to add a new primitive - is it allowed? If someone 
> implements this on Thursday, can they still claim conformance if a new 
> primitive is added on Friday?

For the CollectionParameters map, a "filters" item lists the filters that are 
used for this capture file. It truly doesn't matter if the reference is updated 
later: the capture still has the same filter string.

Thus, it is quite sufficient for this reference to be:
   http://www.tcpdump.org/manpages/pcap-filter.7.html
That is a useful reference for an implementer, and it fits in an RFC.

--Paul Hoffman

smime.p7s
Description: S/MIME cryptographic signature
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop