On Nov 27, 2018, at 3:05 AM, Alexey Melnikov <aamelni...@fastmail.fm> 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 <war...@kumari.net> 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
