On Mon, 20 Mar 2017, Warren Kumari wrote:
Authors (and DNSOP),
It appears that this may have been a process violation here - RFC5378
Section 3.3. Right to Produce Derivative Works seems to say that the
IETF needs change control before a WG can formally adopt a document. I
believe that we missed the fact that this included "non-standard"
copyright boilerplate.
I / we are still investigating, and would appreciate it if the WG
gives us some time to figure this out.
I'm not a process expert, but I would think that this document is best
resubmitted as individual RFC (with boilerplate updated to reflect this),
and then immediately placed into a "Final Review" as specified in Section
4.7 of RFC 4846. The RFC-Editor should be informed that this document
has passed the technical review already in dnsops and that dnsops is in
favour of publication as individual rfc documenting as it describes a
valuable current used practise, so the document should proceed without
modifications to the specified protocol.
This also would address my issue of the WG adopting something it cannot
really change that could be abused for nationstate-level censorship.
However, such a change of submission should not lead to any more
substantive delays in publication. If this is not possible, then I will
retract my objection to publishing this as a WG document, and would only
request the authors update the initial sentence of the abstract to say:
This document describes an existing and widely deployed practise
for expressing and distributing DNS reply filters. This is
implemented using a DNS response policy inside a specially constructed
DNS zone, and for processing the contents of such response policy
zones (RPZ) inside recursive name servers.
Paul
W
rather, the authors will attempt to modify the text to suit the
consensus position of the WG, and at publication time, rights to create
derivative works will be released to the IETF. so, the WG has domain over the
meaning of the final document and the content of future documents, but not
over the content of the final document. the authors want to work with the
community to ensure that a consensus document is published, but we do not want
to open the door to wrongheaded and unacceptable wordings typified by the
above.
second, your disclaimer won't be added, and if the consensus of the WG is that
it must be added, then the standardization activity of dns-rpz will fail. you
are free to pitch your ideas, and the authors are free to try to accommodate
those ideas, but the final arbiter of whether accommodation is necessary or
has been accomplished is WG consensus, not the authors, and not any WG member.
third, ignoring completely the words and the wording of your proposed
applicability statement, and focusing purely on the ideas it contains, let's
dispense with the nonsequiturs and canards as follows:
* queries are not intercepted; they are processed differently and deliberately
by an RDNS server which has voluntarily subscribed to explicit policy sources.
* response fabrication is in this case a service desired by the end-user and
by the RDNS operator, thus, "fabrication" has improper connotation.
* redirection is by no means the only capability offered.
* walled gardens or enclaves may, or may not, be part of the open internet.
* adoption and acceptance does not acknowledge anything like what's shown.
rather, it's an acknowledgement that the internet now does work this way, at
the deliberate and voluntary behest of its RDNS operators and users, and that
a specification document has two boons: in the short term, giving implementors
and publishers a single authoritative reference for how dns-rpz works now;
and, giving change control of the dns-rpz protocol itself over to the IETF
upon this document's publication, so that the community can drive changes in
the protocol henceforth.
i did not note any second or other voice in favour of this amendment, and due
to the vacuous pseudo-mumbo alt-jumbo of the proposal, i predict there will be
no other voice in favour of it.
so, the authors propose a replacement for the current abstract:
This document describes a method for expressing DNS response policy
inside a specially constructed DNS zone, and for recursive name
servers to use such policy to return modified results to DNS clients.
Such modified DNS results might prevent access to selected HTTP servers,
or redirect users to "walled gardens", or block objectionable email, or
otherwise defend against DNS content deemed malicious by the RDNS
operator or end-user. These so-called "DNS Firewalls" are widely used in
fighting Internet crime and abuse.
Like other mechanisms called "firewalls," response policy zones (RPZ)
can be used to block wanted SMTP, HTTP, and other data as well as
unwanted data. RPZ ought not be used to interfere with data desired by
recipients. In other words, RPZ should be deployed only with the
permission of any and all affected RDNS end-users.
This document does not recommend the use of RPZ in any particular
situation or instead of other mechanisms including those more
commonly called "firewalls." This document lacks an applicability
statement for that reason, and because it merely describes a currently
common practice, without recommending or criticising that practice.
please chime in if you're for or against this proposed text, or if for some
incomprehensible reason you are in favour of chinese.apri...@gmail.com's
proposal from march 12 and want it to be further considered or debated.
the authors will work toward consensus, but not arbitrarily so.
vixie
_______________________________________________
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
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
