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

Joe Abley <jabley@hopcount.ca> Thu, 22 November 2018 14:18 UTC

Return-Path: <jabley@hopcount.ca>
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 E646F130EFA for <dnsop@ietfa.amsl.com>; Thu, 22 Nov 2018 06:18:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
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 lEM4IRk9cR3U for <dnsop@ietfa.amsl.com>; Thu, 22 Nov 2018 06:18:12 -0800 (PST)
Received: from mail-it1-x136.google.com (mail-it1-x136.google.com [IPv6:2607:f8b0:4864:20::136]) (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 36FC3130EFE for <dnsop@ietf.org>; Thu, 22 Nov 2018 06:18:08 -0800 (PST)
Received: by mail-it1-x136.google.com with SMTP id x19so14328605itl.1 for <dnsop@ietf.org>; Thu, 22 Nov 2018 06:18:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z+tfQjcPbsdV/owWgNfLbpwiNmfWgTZTgiiaKRGf/eE=; b=P0VzL2/gU/uYDC5ZuEUbpgQkNvQu8quqfdlRa7goX2B3e13PDwcrnFgwm5J5KyMScc a2Dmw83YeVOONkNudJOy8IebqAb1QtwQY/7m+l+jNJsqvwyVMMOiTUtBwrFFe+ys31g3 CPW2YRaG9jUKbONHS5pF5ui9m2yCN45/dNgQQ=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=Z+tfQjcPbsdV/owWgNfLbpwiNmfWgTZTgiiaKRGf/eE=; b=rMgVv4T7kRsnhTkiHR7tTrutZCISOAzlpBlfreg21OpNRB55vambVtRWnaJ75RYL05 D4PzCdr1wF4rh63/PC3IRLjiNP9QHLHFDeSrDTopMh2me52GkqPJ5WbdSj1uUA/EpuYo euPbkZlPZmnQqtozQMJ9WofG7ZPboD+lNBSvHNs6EEodV0e9UVPFGwdyf1ICFyjLs/cO HQosuPETwdTDK2Kj3dMgBVU0ni8ffBjvmIiDuZvhNN4M1lUearngDxuZ4f+AfXxyw9Cm 3560kiei+kLO6OPQNyR5c3xAfX+wLZnyC62v5q3NUKskbOx52pLlSemDuCcaUdrSllKp 6mZw==
X-Gm-Message-State: AGRZ1gLlAmyxCTWPDsjC+bksVRxpF0theXvnP6dQIc0NHoz6xb9V+CKK B4YYDIQXkZFrTWoJh9+U83lqN+9DzeU=
X-Google-Smtp-Source: AJdET5fgPO5eQSMV9WUqeHIHr5kasix5UuU5ma4Ge84HiLjtL36iXUn43EJBulflKBWsdvr7nJabvg==
X-Received: by 2002:a24:d8c3:: with SMTP id b186-v6mr9802130itg.161.1542896287102; Thu, 22 Nov 2018 06:18:07 -0800 (PST)
Received: from [172.30.132.225] ([129.100.255.32]) by smtp.gmail.com with ESMTPSA id v74sm1858623ita.27.2018.11.22.06.18.05 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Nov 2018 06:18:06 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail-FF4AD75B-FBE7-4D89-8A97-6543195532A9"
Mime-Version: 1.0 (1.0)
From: Joe Abley <jabley@hopcount.ca>
X-Mailer: iPad Mail (16B92)
In-Reply-To: <ca821f6f-26de-f2f8-7e63-d9cb8dcfdf60@rfc-editor.org>
Date: Thu, 22 Nov 2018 09:18:05 -0500
Cc: Warren Kumari <warren@kumari.net>, Sara Dickinson <sara@sinodun.com>, Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>, The IESG <iesg@ietf.org>, draft-ietf-dnsop-dns-capture-format@ietf.org, Alexey Melnikov <aamelnikov@fastmail.fm>
Content-Transfer-Encoding: 7bit
Message-Id: <47A207C9-A17A-4086-98FD-4059639171A6@hopcount.ca>
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>
To: Heather Flanagan <rse@rfc-editor.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/sMCkh0UJU-9ih0YR7V95-qr6ucI>
Subject: Re: [DNSOP] 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: Thu, 22 Nov 2018 14:18:14 -0000

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 <rse@rfc-editor.org> wrote:
> 
>> On 11/21/18 9:33 AM, Warren Kumari wrote:
>> [ - DNSOP (for clutter), +Heather / RFC Editor for sanity :-P ] 
>> 
>>> On Wed, Nov 21, 2018 at 9:47 AM Sara Dickinson <sara@sinodun.com> wrote:
>>> 
>>> 
>>>> On 21 Nov 2018, at 14:42, Alexey Melnikov <aamelnikov@fastmail.fm> wrote:
>>> 
>>> Thanks for the quick response.
>>> 
>>>> 
>>>> Hi Sara,
>>>>>> 
>>>>>> 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.
>>>>> 
>>>>> Is that true if it is an optional field? 
>>>> 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
>>> 
>>> 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?
> 
> 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. 
>>> _______________________________________________
>>> DNSOP mailing list
>>> DNSOP@ietf.org
>>> 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
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop