On 3/20/17 8:15 AM, Warren Kumari wrote: > On Mon, Mar 20, 2017 at 12:55 AM, Paul Vixie <vi...@fsi.io> wrote: >> on sunday march 12, chinese.apri...@gmail.com wrote as follows: >> >>> I'd be happy to see the document proceed under two conditions: 1) it >>> becomes a WG document, subject to IETF change control, and 2) that the >>> disclaimer requested back on 20170103 be added to the document. To refresh >>> the collective mind, here is the missing text: >>> >>> applicability statement. >>> >>> This draft is documents a process and method for intercepting DNS queries >>> and fabricating responses to redirect the querier into a walled garden or >>> enclave that is NOT part of the open Internet. Adoption and acceptance of >>> this draft is an acknowledgement that the IETF, the IAB and ISOC reject the >>> principles espoused at https://open-stand.org/about-us/principles/, in >>> particular article 3. Collective Empowerment insofar as the evolution of >>> the DNS is concerned. >> i was not subscribed at the time, so i'm working from the archives. the above >> quoted text is wrongheaded and its proposals unacceptable in several ways. >> >> first, the document has been adopted, but is not subject to ietf change >> control. > > 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. Hi,
It appears to be the case that the author's statement above necessarily precludes adoption as a working group document. It is not uncommon for documents to have terms applied to them that are incompatible with working group adoption. Those are sometimes altered on adoption, processed as individual submissions, or through another stream (external standards require special handling for example, rfc 5830). Applying the tlp 5 section 6c limitations is obviously at the discretion of the contributors and may be changed at any time. thanks joel > 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 > >
signature.asc
Description: OpenPGP digital signature
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
