Hello dnsop, draft-ietf-dnsop-dns-rpz expired on 2017-09-10, i.e. did not receive any update from 2017-03-09.
Is there a real apetite for work on this document? We are considering RPZ implementation for Knot Resolver next year but if the document is not going to move forward I would rather close the ticket and be done with it. I certainly do commit to implementing ever-changing protocol without readily available description ... Is there anyone interested in the document except me and the appointed editor? Thank you for replies. Petr Špaček @ CZ.NIC On 18.7.2017 14:13, Suzanne Woolf wrote: > Dear colleagues, > > > As you might recall, we had a call for adoption for draft-vixie-dns-rpz > just before IETF 98 in March. We had a lively discussion and decided to > adopt the document for further work in the WG as an Informational RFC. > > However, the chairs then discovered we’d made a mistake in adopting the > draft with the copyright that reserved rights in derivative works to the > original authors. This isn’t allowed for a Working Group document (see > RFC5378, Section 3.3). > > We’ve talked since then with the authors about how we might move forward > with the draft. They had concerns, which had already been discussed on > the list, about some of the views of the WG on the applicability of RPZ. > > We believe we’ve found a way forward that meets their concerns and the > needs of the WG. We propose that: > > 1. The draft adopts the following language in the Introduction: > > This document describes an existing and widely deployed method by > which a security policy can be applied to DNS responses, possibly > causing an end system to receive responses that do not correspond to > actual DNS zone content. Such policy-based responses 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 and the end-user. > > This method describes its policy using a specially formatted DNS > Zone called a Response Policy Zone (RPZ), and is an instance of a > more general mechanism called a "DNS Firewall." Like other > mechanisms called "firewalls," response policy zones (RPZ) can be > used to block both wanted 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 every > 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. By design and expectation, response policy zones (RPZ) > must be seen as a defensive and virtuous tool, or it will either not > be used, or will be bypassed by end-users. > > > 2. We had already limited the the scope of the document to describing > the current protocol, with any discussion of proposed changes left to a > later document if people want to do that work. That limitation stands. > The intended document status is Informational. > > 3. The copyright is changed to the standard boilerplate required for a > WG draft. > > > If this is acceptable to the WG, we’ll keep the new draft with these > changes as a WG draft. > > If not, the draft will be dropped as a WG item. The authors can seek > publication of the document as an independent submission or outside of > the RFC series. > > If you have a comment on this, please make it succinctly and soon. > > > thanks, > Suzanne & TIm _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
