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

Warren Kumari <warren@kumari.net> Tue, 27 November 2018 02:05 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C1C30130E18 for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 18:05:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.359
X-Spam-Level:
X-Spam-Status: No, score=-3.359 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-1.459, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XvfvJe_0ipDO for <dnsop@ietfa.amsl.com>; Mon, 26 Nov 2018 18:05:53 -0800 (PST)
Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC87E130E16 for <dnsop@ietf.org>; Mon, 26 Nov 2018 18:05:51 -0800 (PST)
Received: by mail-wr1-x434.google.com with SMTP id t27so13021798wra.6 for <dnsop@ietf.org>; Mon, 26 Nov 2018 18:05:51 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=1ScqQFCJYtX9751tvpAmV0R7C1JXURgMbeUl6PkCCPs=; b=QY8PepToR0gGaxPtFHvsCAszHleAzGYY9yBYzPsYaAUH/CA51fy0l2mLZzI1iZL+pn zqDy+9d8PUAsOGv6KLZBs4tp1ZnRdN0M/rAY/LkrzGpJiVW/tmqIL6NAzqy3/b0elr4o qAmDGTLEu2WJ5OUkFcZI29Z3iU6fsu/wgmrEW+PGyxb6P+D6N4AAUZI2byib51ZthjhR QuMhvNeIBm2TcUGAvAgErL6SurrzcXSTTVbU6/zxbIuk1FqsJb984yy7K4wVct4+HJbr xffevRknlAcIHc6KskqQ55yu7VhXcehzO+qXqAFmLjtG+3GZosmJwotH6l8uFNQ//D4g 5ykw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=1ScqQFCJYtX9751tvpAmV0R7C1JXURgMbeUl6PkCCPs=; b=cMCWd8htD/l7gEs91+ZmDiyC0FqPXAQhrkE1kjHd8vLluWvH09cILBnA780LCb+NQn ZcCcttbAueYt+5po13yJ46t7dUClAS4hImyZNT7mAntYWPeR7uqF6RVrTfNFHryVMf3I XZcgo1GXoYrY0JPXyUYTx3eMDIz7vZwTKkVTprl7TPZq6N8Aff8nt84lPC9+25BXsyyA BfF53MbTJclUyamk8xWnQIEJto/Zu1HaTpd6chQ+jOXuYkO4fbSGqc+WGenA7nqhhTKN VgooPaDKlFPvbaNP9/ggZES6vs17u097gei7IzPXevRUE8k3C4NAcRgZjsXe+MZyzNcN gOgA==
X-Gm-Message-State: AA+aEWZY/1PNkJe580UBFbLmOGj3fET7FMr3OlyL8q4q9c6wcTlAcfwp BPEaDavnxIaF475e/VdkLR2k84Qh40obzVDItQr7gQ==
X-Google-Smtp-Source: AFSGD/UPRXJbRtlajo3d/9pp5XfOueIQZNtJZzvLKSW2k29U1b9TSt0dSZNkjJ7R3gJy/g8qxydCUn8eY66UYsI8gAw=
X-Received: by 2002:adf:f0c5:: with SMTP id x5mr380324wro.77.1543284349760; Mon, 26 Nov 2018 18:05:49 -0800 (PST)
MIME-Version: 1.0
References: <154265985064.16386.5550594646862412061.idtracker@ietfa.amsl.com> <BF3169F5-E68D-4C68-80D7-1772E7A9EDEA@sinodun.com> <1542811322.1310112.1584530512.0785569A@webmail.messagingengine.com> <4D2E72B7-1EEE-4BD2-8200-B688074AE5E3@sinodun.com> <CAHw9_iLuNYHHnMz_jgOA2JwTDNWUkRb9TVkT8zwKedNT9LUBmQ@mail.gmail.com> <ca821f6f-26de-f2f8-7e63-d9cb8dcfdf60@rfc-editor.org> <CAHw9_i+6MRiGOeDh5+5tVwajFhCCbgRgSnio04yqUGLbHKyHEw@mail.gmail.com> <CAHw9_iLxsEw4PQ4=Vu1ghhGGEPvS8pBuB9G7buiFMDjNB=m1cg@mail.gmail.com> <FA6BBBB2-D535-4597-8923-5307390D9462@icann.org>
In-Reply-To: <FA6BBBB2-D535-4597-8923-5307390D9462@icann.org>
From: Warren Kumari <warren@kumari.net>
Date: Mon, 26 Nov 2018 21:05:13 -0500
Message-ID: <CAHw9_iKEsfjpC2FzjKaaUz=oR_S9WNPNg+EuvBmi_n_CUpC8mQ@mail.gmail.com>
To: Paul Hoffman <paul.hoffman@icann.org>
Cc: Alexey Melnikov <aamelnikov@fastmail.fm>, dnsop <dnsop@ietf.org>, The IESG <iesg@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000748fcc057b9be3aa"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/m8p0DRdcbwzMhGe40b2rwAA9ED8>
Subject: Re: [DNSOP] [Ext] Alexey Melnikov's Discuss on draft-ietf-dnsop-dns-capture-format-08: (with DISCUSS and COMMENT)
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2018 02:05:55 -0000

On Mon, Nov 26, 2018 at 8:58 PM Paul Hoffman <paul.hoffman@icann.org> wrote:

> On Nov 26, 2018, at 5:44 PM, Warren Kumari <warren@kumari.net> 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