Return-Path: 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 74BC512875B; Wed, 21 Nov 2018 10:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no 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 NsahKH4C513n; Wed, 21 Nov 2018 10:27:27 -0800 (PST) Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2F712426A; Wed, 21 Nov 2018 10:27:27 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id F27D31C3F0F; Wed, 21 Nov 2018 10:27:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q8E_Hc86LT2R; Wed, 21 Nov 2018 10:27:14 -0800 (PST) Received: from Heathers-MacBook-Pro-2.local (c-71-231-216-10.hsd1.wa.comcast.net [71.231.216.10]) by c8a.amsl.com (Postfix) with ESMTPSA id 771A91C3F0D; Wed, 21 Nov 2018 10:27:14 -0800 (PST) To: Warren Kumari , Sara Dickinson Cc: Alexey Melnikov , Tim Wicinski , dnsop , The IESG , draft-ietf-dnsop-dns-capture-format@ietf.org References: <154265985064.16386.5550594646862412061.idtracker@ietfa.amsl.com> <1542811322.1310112.1584530512.0785569A@webmail.messagingengine.com> <4D2E72B7-1EEE-4BD2-8200-B688074AE5E3@sinodun.com> From: Heather Flanagan Message-ID: Date: Wed, 21 Nov 2018 10:27:25 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8BEE64A9F7357EA76D9F6571" Content-Language: en-US Archived-At: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Nov 2018 18:27:30 -0000 This is a multi-part message in MIME format. --------------8BEE64A9F7357EA76D9F6571 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit 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 > wrote: > > > >> On 21 Nov 2018, at 14:42, Alexey Melnikov > > 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 --------------8BEE64A9F7357EA76D9F6571 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit


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:

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