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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 19 Nov 2018 12:37:30 -0800

Alexey Melnikov has entered the following ballot position for
draft-ietf-dnsop-dns-capture-format-08: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-dns-capture-format/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document, it is a useful contribution to RFC series. I
enjoyed reading it.

I have a small list of issues that is hopefully easy to fix:

1)

In 7.4.2:

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

This makes the [pcap] reference Normative. If you don't want to do that, please
fully specify syntax in this document.

2) I believe [I-D.ietf-cbor-cddl] reference needs to be Normative due to use of
CDDL in Appendix A. If you don't think CDDL is normative, you need to state
that in Appendix A.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Was CDDL in Appendix A validated with a tool? This information is missing from
the shepherding write-up.

6.2.3.  Storage flags

   The Storage Parameters also contains optional fields holding details
   of the sampling method used and the anonymisation method used.  It is
   RECOMMENDED these fields contain URIs pointing to resources
   describing the methods used.

Please add a Normative Reference for URI spec here (RFC 3986).

7.5.3.2.  "QueryResponseSignature"

   | qr-transport-flags | O | U | Bit flags describing the transport   |
   |                    |   |   | used to service the query.           |
   |                    |   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
   |                    |   |   | IPv6                                 |
   |                    |   |   | Bit 1-4. Transport. 4 bit unsigned   |
   |                    |   |   | value where 0 = UDP, 1 = TCP, 2 =    |
   |                    |   |   | TLS, 3 = DTLS. Values 4-15 are       |
   |                    |   |   | reserved for future use.             |
   |                    |   |   | Bit 5. 1 if trailing bytes in query  |
   |                    |   |   | packet. See Section 11.2.            |

Would something like DoH appear as a separate transport choice?

How can new values be added to the list if there are no IANA Considerations?

7.5.3.5.  "MalformedMessageData"

   |                    |   |   |                                      |
   | mm-transport-flags | O | U | Bit flags describing the transport   |
   |                    |   |   | used to service the query. Bit 0 is  |
   |                    |   |   | the least significant bit.           |
   |                    |   |   | Bit 0. IP version. 0 if IPv4, 1 if   |
   |                    |   |   | IPv6                                 |
   |                    |   |   | Bit 1-4. Transport. 4 bit unsigned   |
   |                    |   |   | value where 0 = UDP, 1 = TCP, 2 =    |
   |                    |   |   | TLS, 3 = DTLS. Values 4-15 are       |
   |                    |   |   | reserved for future use.             |

If the above bits supposed to be the same as for qr-transport-flags,
maybe it is worth defining them once and referencing in all relevant places?

7.6.  "QueryResponse"
   | query-size           | O | U | DNS query message size (see        |
   |                      |   |   | below).                            |
   |                      |   |   |                                    |
   | response-size        | O | U | DNS query message size (see        |
   |                      |   |   | below).                            |

I think "DNS response message size" for response-size.

It is odd to have RFC 2119 language in B.2, which is itself informative.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 21 Nov 2018 14:36:09 +0000

> On 19 Nov 2018, at 20:37, Alexey Melnikov <[email-masked]> wrote:

Hi Alexey, 

Thanks for the review.

> draft-ietf-dnsop-dns-capture-format-08: Discuss

Is that true if it is an optional field? 

> CDDL in Appendix A. If you don't think CDDL is normative, you need to state

Yes indeed - it should be normative, will fix. 

We (the authors) have used the CDDL tool described on http://cbor.io/tools.html <http://cbor.io/tools.html> to read the CDDL in Appendix A and ensured an example instance can be created. 

Did you have some other validation tool in mind?

> Please add a Normative Reference for URI spec here (RFC 3986).

Yes, will do. 

> Would something like DoH appear as a separate transport choice?

No, we need to add DoH to this list (it didn’t exist when we started the draft!). 

> How can new values be added to the list if there are no IANA Considerations?

As described in response to the DISCUSS on this issue we propose IANA create a C-DNS registry with
subregistries with keys for each of the different maps used in C-DNS.
New entries in these subregistries would follow Expert Review 

> maybe it is worth defining them once and referencing in all relevant places?

The qr-transport-flags and mm-transport-flags are different in that the qr-transport-flags include Bit 5, the trailing bytes indicator.

In the CDDL a base ’TransportFlags’ type is defined and then

mm-transport-flags     => TransportFlags,

qr-transport-flags    => QueryResponseTransportFlags,

 QueryResponseTransportFlagValues = &(
      query-trailingdata : 5,
  ) / TransportFlagValues
  QueryResponseTransportFlags = uint .bits QueryResponseTransportFlagValues

We can add some text to the table descriptions in sections 7.5.3.2 and 7.5.3.5 to clarify the relationship. 

> It is odd to have RFC 2119 language in B.2, which is itself informative.

Good catch :-)

Many thanks

Sara.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 21 Nov 2018 14:42:02 +0000

Hi Sara,

On Wed, Nov 21, 2018, at 2:36 PM, Sara Dickinson wrote:
>> On 19 Nov 2018, at 20:37, Alexey Melnikov
>> <[email-masked]> wrote:> 
> Hi Alexey, 
> 
> Thanks for the review.
> 
>> 
>> ---------------------------------------------------------------
>> ------->> DISCUSS:
>> ---------------------------------------------------------------
>> ------->> 
>> Thank you for this document, it is a useful contribution to RFC
>> series. I>> enjoyed reading it.
>> 
>>    | filter           | O | T | "tcpdump" [pcap] style filter
>>    | for      |>>    |                  |   |   | input.
>>    |                  |   |   | |>> 
>> This makes the [pcap] reference Normative. If you don't want to do
>> that, please>> fully specify syntax in this document.
> 
Yes, optionallity of a field doesn't make its full specification
optional.
> 
>> 
>> 2) I believe [I-D.ietf-cbor-cddl] reference needs to be Normative due
>>    to use of>> CDDL in Appendix A. If you don't think CDDL is normative, you need
>> to state>> that in Appendix A.
> 
>> ---------------------------------------------------------------
>> ------->> COMMENT:
>> ---------------------------------------------------------------
>> ------->> 
>> Was CDDL in Appendix A validated with a tool? This information is
>> missing from>> the shepherding write-up.
> 
> We (the authors) have used the CDDL tool described on
> http://cbor.io/tools.html to read the CDDL in Appendix A and ensured
> an example instance can be created.> 
No, this is fine. I just wanted to know.

> 
>> 
>> 6.2.3.  Storage flags
>> 
>>    The Storage Parameters also contains optional fields holding
>>    details>>    of the sampling method used and the anonymisation method used.
>>    It is>>    RECOMMENDED these fields contain URIs pointing to resources
>>    | qr-transport-flags | O | U | Bit flags describing the
>>    | transport   |>>    |                    |   |   | used to service the query.
>>    |                    |   |   | |>>    |                    |   |   | Bit 0. IP version. 0 if IPv4, 1 if
>>    |                    |   |   | |>>    |                    |   |   | IPv6
>>    |                    |   |   | |>>    |                    |   |   | Bit 1-4. Transport. 4 bit unsigned
>>    |                    |   |   | |>>    |                    |   |   | value where 0 = UDP, 1 = TCP, 2 =
>>    |                    |   |   | |>>    |                    |   |   | TLS, 3 = DTLS. Values 4-15 are
>>    |                    |   |   | |>>    |                    |   |   | reserved for future use.
>>    |                    |   |   | |>>    |                    |   |   | Bit 5. 1 if trailing bytes in query
>>    |                    |   |   | |>>    |                    |   |   | packet. See Section 11.2.
>>    |                    |   |   | |>> 
> No, we need to add DoH to this list (it didn’t exist when we started
> the draft!).> 
>> 
>> How can new values be added to the list if there are no IANA
>> Considerations?> 
> As described in response to the DISCUSS on this issue we propose IANA
> create a C-DNS registry with> subregistries with keys for each of the different maps used in C-DNS.> New entries in these subregistries would follow Expert Review 
Ok, great.

>>    | mm-transport-flags | O | U | Bit flags describing the
>>    | transport   |>>    |                    |   |   | used to service the query. Bit 0 is
>>    |                    |   |   | |>>    |                    |   |   | the least significant bit.
>>    |                    |   |   | |>>    |                    |   |   | Bit 0. IP version. 0 if IPv4, 1 if
>>    |                    |   |   | |>>    |                    |   |   | IPv6
>>    |                    |   |   | |>>    |                    |   |   | Bit 1-4. Transport. 4 bit unsigned
>>    |                    |   |   | |>>    |                    |   |   | value where 0 = UDP, 1 = TCP, 2 =
>>    |                    |   |   | |>>    |                    |   |   | TLS, 3 = DTLS. Values 4-15 are
>>    |                    |   |   | |>>    |                    |   |   | reserved for future use.
>>    |                    |   |   | |>> 
>> If the above bits supposed to be the same as for qr-transport-flags,>> maybe it is worth defining them once and referencing in all relevant
>> places?> 
> The qr-transport-flags and mm-transport-flags are different in that
> the qr-transport-flags include Bit 5, the trailing bytes indicator.> 
>   QueryResponseTransportFlags = uint .bits
>   QueryResponseTransportFlagValues> 
> We can add some text to the table descriptions in sections 7.5.3.2 and
> 7.5.3.5 to clarify the relationship.Thank you for your clarification. Your explanation is sufficient.

> 
>> 
>> 7.6.  "QueryResponse"
>>    | query-size           | O | U | DNS query message size
>>    | (see        |>>    |                      |   |   | below).
>>    |                      |   |   | |>>    |                      |   |   |                                    |
>>    | response-size        | O | U | DNS query message size
>>    | (see        |>>    |                      |   |   | below).
>>    |                      |   |   | |>> 
>> It is odd to have RFC 2119 language in B.2, which is itself
>> informative.> 
> Good catch :-)
> 
> Many thanks
> 
> Sara.

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 21 Nov 2018 14:47:22 +0000

> On 21 Nov 2018, at 14:42, Alexey Melnikov <[email-masked]> wrote:

Thanks for the quick response.

> Yes, optionallity of a field doesn't make its full specification optional.

In which case it seems we can either include a more specific normative reference here to this page:
http://www.tcpdump.org/manpages/pcap-filter.7.html <http://www.tcpdump.org/manpages/pcap-filter.7.html>

or reproduce this page in an appendix. I’d prefer the former unless a reference to such a web page would prove problematic as a normative reference? 

Sara.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 21 Nov 2018 12:33:40 -0500

[ - DNSOP (for clutter), +Heather / RFC Editor for sanity :-P ]

On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson <[email-masked]> wrote:

> http://www.tcpdump.org/manpages/pcap-filter.7.html
>
> or reproduce this page in an appendix. I’d prefer the former unless a
> reference to such a web page would prove problematic as a normative
> reference?
>

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?

What we made up on the call was to simply grab a copy of
http://www.tcpdump.org/manpages/pcap-filter.7.html (it seems to be under
the BSD license) and put it somewhere on ietf.org, so we have a stable
snapshot to reference, and ask you to point to that.
But, this was simply us making stuff up on the fly - I'm hoping that the
RFC Editor can tell us if this is sane or the worst idea ever, or what....

W

>
> Sara.
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

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

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 21 Nov 2018 17:57:58 +0000

> On 21 Nov 2018, at 17:33, Warren Kumari <[email-masked]> wrote:
> 
> On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
>> On 21 Nov 2018, at 14:42, Alexey Melnikov <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 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?
> 
> What we made up on the call was to simply grab a copy of http://www.tcpdump.org/manpages/pcap-filter.7.html <http://www.tcpdump.org/manpages/pcap-filter.7.html> (it seems to be under the BSD license) and put it somewhere on ietf.org <http://ietf.org/>, so we have a stable snapshot to reference, and ask you to point to that.
> But, this was simply us making stuff up on the fly - I'm hoping that the RFC Editor can tell us if this is sane or the worst idea ever, or what….

Thanks for the update, we’ll hold off till we hear more on this. 

Sara.

---

From: Heather Flanagan <[email-masked]>
Date: Wed, 21 Nov 2018 10:27:25 -0800

On 11/21/18 9:33 AM, Warren Kumari wrote:
>>>>     for      |
>>>>       |                  |   |   | input.
>>>>                                     |
>     or reproduce this page in an appendix. I’d prefer the former
>     unless a reference to such a web page would prove problematic as a
>     normative reference?
>
>
> 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?

If there was a way to point to a particular snapshot of the page (e.g., 
a particular hash on a GitHub page, a particular timestamped version) 
that would get around this.

> http://www.tcpdump.org/manpages/pcap-filter.7.html (it seems to be 
> under the BSD license) and put it somewhere on ietf.org 
> <http://ietf.org>, so we have a stable snapshot to reference, and ask 
> you to point to that.
> But, this was simply us making stuff up on the fly - I'm hoping that 
> the RFC Editor can tell us if this is sane or the worst idea ever, or 
> what....'''

This also works, though I'd want to you all to think about the precedent 
this sets. Are you willing to do this on a regular basis? Managing a one 
off, dealing any any particular copyright issues (not a problem in this 
case, I believe, but it could be interesting in other cases), those are 
more challenging.

-Heather

>     [email-masked] <mailto:[email-masked]>
> I don't think the execution is relevant when it was obviously a bad 
> idea in the first place.
> regret at having chosen those particular rabid weasels and that pair 
> of pants.
>    ---maf

---

From: Joe Abley <[email-masked]>
Date: Thu, 22 Nov 2018 09:18:05 -0500

Hi Heather,

Since I was cc'd: I ran into this the other week in an academic paper, and I was surprised that I couldn't find a normative description of the pcap format. I'm glad it wasn't just me :-)

I wound up citing the format with reference to a particular version of tcpdump; the name of the tool plus a URL citation ("retrieved on") plus a version number seemed to me to be sufficient kindness to future archaeologists.

It might be nice in the future if some kind soul took the time to work with the tcpdump community to write up a stable description of the pcap format, edited for style in the series in which it is published. I don't suggest that being a sensible approach for this document, though.

Joe

> On Nov 21, 2018, at 13:27, Heather Flanagan <[email-masked]> wrote:
> 
> If there was a way to point to a particular snapshot of the page (e.g., a particular hash on a GitHub page, a particular timestamped version) that would get around this.
> 
> 
> 
>> 
>> What we made up on the call was to simply grab a copy of http://www.tcpdump.org/manpages/pcap-filter.7.html (it seems to be under the BSD license) and put it somewhere on ietf.org, so we have a stable snapshot to reference, and ask you to point to that.
>> But, this was simply us making stuff up on the fly - I'm hoping that the RFC Editor can tell us if this is sane or the worst idea ever, or what....'''
> 
> This also works, though I'd want to you all to think about the precedent this sets. Are you willing to do this on a regular basis? Managing a one off, dealing any any particular copyright issues (not a problem in this case, I believe, but it could be interesting in other cases), those are more challenging.
> 
> 
> 
> -Heather
> 
> 
> 
>> 
>> W
>> 
>> 
>>  
>>> 
>>> Sara. 
>> 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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Nov 2018 20:43:54 -0500

On Wed, Nov 21, 2018 at 1:27 PM Heather Flanagan <[email-masked]> wrote:

> If there was a way to point to a particular snapshot of the page (e.g., a
> particular hash on a GitHub page, a particular timestamped version) that
> would get around this.
>

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

> RFC Editor can tell us if this is sane or the worst idea ever, or
> what....'''
>
>
Paul Hoffman (CCed) noted that we've discussed this before, and has
(kindly!) offered to write an ID discussing the issue, and proposing the
above - this would give us some process to follow.

So, I'm proposing that, in this case, the authors update the reference to
point at the GitHub link, and we discuss the larger issue when Paul
provides a draft.
Does that work for:
a: the RFC Ed
b: the authors
and,
c: Alexey, who is holding a DISCUSS.
?

W

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Nov 2018 20:44:44 -0500

[ + Paul Hoffman for real this time! ]

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 Nov 2018 01:58:08 +0000

On Nov 26, 2018, at 5:44 PM, Warren Kumari <[email-masked]> wrote:
> Actually, there is - the tcpdump man pages (and actually all of their documentation!) lives in github - the version that this document references is:

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.

> 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 c…

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

---

From: Warren Kumari <[email-masked]>
Date: Mon, 26 Nov 2018 21:05:13 -0500

On Mon, Nov 26, 2018 at 8:58 PM Paul Hoffman <[email-masked]> wrote:

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

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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 Nov 2018 02:10:46 +0000

On Nov 26, 2018, at 6:05 PM, Warren Kumari <[email-masked]> wrote:
> 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

---

From: Alexey Melnikov <[email-masked]>
Date: Tue, 27 Nov 2018 11:05:53 +0000

Hi Paul,

On Tue, Nov 27, 2018, at 2:10 AM, Paul Hoffman wrote:
> 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

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 27 Nov 2018 14:59:51 +0000

> 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

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 27 Nov 2018 07:02:01 -0800

On Tue, Nov 27, 2018 at 7:00 AM Paul Hoffman <[email-masked]> wrote:

> 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

---

From: Sara Dickinson <[email-masked]>
Date: Wed, 28 Nov 2018 13:38:52 +0000

> From: Paul Hoffman <[email-masked]>
> 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 <[email-masked]>
> Cc: dnsop <[email-masked]>, The IESG <[email-masked]>
> 

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? <http://www.tcpdump.org/manpages/pcap-filter.7.html?> 

Regards

Sara.

---

From: Alexey Melnikov <[email-masked]>
Date: Wed, 28 Nov 2018 14:45:20 +0000

On Wed, Nov 28, 2018, at 1:38 PM, Sara Dickinson wrote:
> 
>> *From: *Paul Hoffman <[email-masked]>
>> *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 <[email-masked]>
>> *Cc: *dnsop <[email-masked]>, The IESG <[email-masked]>
>> 
>> On Nov 27, 2018, at 3:05 AM, Alexey Melnikov
>> <[email-masked]> wrote:>>> 
>>>>  | for      |>>>>  |                  |   |   | input.
>>>>  |                  |   |   | |>>>> 
>>>> 
>>>> On Nov 26, 2018, at 6:05 PM, Warren Kumari <[email-masked]>
>>>> wrote:>>>>> ... that is where we started.
>>>>> 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. 
>>> 
>>> 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.

---

From: Jim Hague <[email-masked]>
Date: Wed, 28 Nov 2018 14:52:25 +0000

>> would suggest we change the first sentence of the section to be:
>>
>> captured.”
> I can live with that, but I would like you to in particular add a note

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 - [email-masked]          Never trust a computer you can't lift.

---

From: Warren Kumari <[email-masked]>
Date: Wed, 28 Nov 2018 14:07:53 -0500

> OK, thanks. We will do that.

Excellent! Please let me know (LOUDLY) once you've had a chance to do so
(and the other comments too).

> >> acceptable http://www.tcpdump.org/manpages/pcap-filter.7.html?
WFM!
W