On Wed, Nov 21, 2018 at 1:27 PM Heather Flanagan <r...@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 <s...@sinodun.com> wrote: > >> >> >> On 21 Nov 2018, at 14:42, Alexey Melnikov <aamelni...@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. > 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 > > > 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. > > > Paul Hoffman (CCed) noted that we've discussed this before, and has (kindly!) offered to write an ID discussing the issue, and proposing the above - this would give us some process to follow. So, I'm proposing that, in this case, the authors update the reference to point at the GitHub link, and we discuss the larger issue when Paul provides a draft. Does that work for: a: the RFC Ed b: the authors and, c: Alexey, who is holding a DISCUSS. ? W > -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 > > -- 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
