On Tue, Nov 27, 2018 at 7:00 AM Paul Hoffman <paul.hoff...@icann.org> wrote:
> 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? > 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
